Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
� ��� ������ ������� � ����� ��� ����������?
9 views
Skip to first unread message
Yuri Myakotin
Mar 12, 2015, 7:25:02 AM3/12/15
to
Hello All!
Вкратце - используется Threefish-1024 в комбинированном CBC+CTR (через
SetTweak), результат XORится с 128бит шифром (к примеру, TwoFish или Serpent),
работающим в режиме OFB.
Разумеется, ключи разные и друг от друга алгоритмически не зависят, получаются
разными хеш-функциями из разных частей 1024-бит секретного ключа и 1024бит
рандомной "соли", идущей в начале зашифрованного сообщения.
PS естественно, опять же предполагается, что в момент шифрования/дешифрования
физического доступа к компьютеру супостат не имеет.
public class Paranoid
{
private ulong[] ThreeFishIV;
private ulong[] TwoFishOFB;
private ulong[] Counter;
private SkeinFish.Threefish1024 ThreeF;
private TwoFish TwoF;
static private void Int128ToBytes(ulong[] int128, byte[] bytes)
{
Buffer.BlockCopy(int128, 0, bytes, 0, 16);
}
static private void BytesToInt128(byte[] bytes,ulong[] int128)
{
Buffer.BlockCopy(bytes, 0, int128, 0, 16);
}
private void TickCount()
{
byte[] tmp = new byte[16];
byte[] tmp1 = new byte[16];
Int128ToBytes(TwoFishOFB, tmp);
TwoF.EncryptBlock(tmp, tmp1);
BytesToInt128(tmp1, TwoFishOFB);
}
private void Xor1024(ref ulong[] src)
{
for (int i = 0; i < 16;i++)
src[i] ^= ThreeFishIV[i];
}
public Paranoid(byte[] key, byte[] salt)
{
byte[] tmp = new byte[96];
byte[] tmp2 = new byte[32];
ulong[] Key1 = new ulong[16];
byte[] Key2 = new byte[32];
TwoFishOFB=new ulong[2];
Counter = new ulong[2];
ThreeFishIV=new ulong[16];
if ((key.Length!=128)||(salt.Length!=128)) throw new
ArgumentException("Invalid arguments length");
Buffer.BlockCopy(key, 0, tmp, 0, 48);
Buffer.BlockCopy(salt, 0, tmp, 48, 48);
HashLib.Crypto.SHA3.Blake512 Blake = new
HashLib.Crypto.SHA3.Blake512();
Blake.Initialize();
byte[] tmp3 = (Blake.ComputeBytes(tmp)).GetBytes();
Buffer.BlockCopy(tmp3, 0, Key1, 0, 64);
Buffer.BlockCopy(salt, 48, tmp, 0, 48);
Buffer.BlockCopy(key, 48, tmp, 48, 48);
HashLib.Crypto.SHA3.Keccak512 Keccak = new
HashLib.Crypto.SHA3.Keccak512();
Keccak.Initialize();
tmp3 = (Keccak.ComputeBytes(tmp)).GetBytes();
Buffer.BlockCopy(tmp3, 0, Key1, 64, 64);
Buffer.BlockCopy(key, 96, tmp2, 0, 16);
Buffer.BlockCopy(salt, 96, tmp2, 16, 16);
SkeinFish.Skein256 Skein = new SkeinFish.Skein256();
Skein.Initialize();
tmp3 = Skein.ComputeHash(tmp2);
Buffer.BlockCopy(tmp3, 0, Key2, 0, 32);
Buffer.BlockCopy(key, 112, tmp2, 0, 16);
Buffer.BlockCopy(salt, 112, tmp2, 16, 16);
Skein.Initialize();
tmp3 = Skein.ComputeHash(tmp2);
Buffer.BlockCopy(tmp3, 0, TwoFishOFB, 0, 16);
Buffer.BlockCopy(tmp3, 16, Counter, 0, 16);
Skein.Dispose();
byte[] tmp4 = new byte[160];
Buffer.BlockCopy(key, 32, tmp4, 0, 32);
Buffer.BlockCopy(salt, 0, tmp4, 32, 128);
SkeinFish.Skein1024 Sk = new Skein1024();
Sk.Initialize();
byte[] IvBytes=Sk.ComputeHash(tmp4);
Buffer.BlockCopy(IvBytes, 0, ThreeFishIV, 0, 128);
ThreeF = new SkeinFish.Threefish1024();
ThreeF.SetKey(Key1);
for (int i = 0; i < 16; i++) Key1[i] = 0;
TwoF = new TwoFish();
TwoF.SetKey(Key2);
for (int i = 0; i < 32; i++) Key2[i] = 0;
}
public void Encrypt(byte[] InData,Stream Out)
{
ulong[] Buf1024=new ulong[16];
byte[] tmpBuf = new byte[128];
MemoryStream In = new MemoryStream();
long Len = InData.LongLength;
if ((Len%128)!=0)
{
int cnt =127-((int)Len % 128);
byte PadSize = (byte)(cnt + 1);
In.WriteByte(PadSize);
byte[] tmp = new byte[cnt];
RNGCryptoServiceProvider rnd = new RNGCryptoServiceProvider();
rnd.GetBytes(tmp);
In.Write(tmp, 0, cnt);
}
In.Write(InData, 0, InData.Length);
Len = In.Length;
In.Seek(0, SeekOrigin.Begin);
for (long i=0;i<(Len/128);i++)
{
In.Read(tmpBuf, 0, 128);
Buffer.BlockCopy(tmpBuf, 0, Buf1024, 0, 128);
ThreeF.SetTweak(Counter);
Counter[0] += 7;
Counter[1] += 19;
Xor1024(ref Buf1024);
ThreeF.Encrypt(Buf1024, ThreeFishIV);
for (int j = 0; j < 8;j++)
{
TickCount();
Buf1024[j * 2] = ThreeFishIV[j * 2] ^ TwoFishOFB[0];
Buf1024[j * 2 + 1] = ThreeFishIV[j * 2 + 1] ^
TwoFishOFB[1];
}
Buffer.BlockCopy(Buf1024, 0, tmpBuf, 0, 128);
Out.Write(tmpBuf, 0, 128);
}
In.Close();
In.Dispose();
}
public void Decrypt(Stream In, Stream Out,int OffsetIn)
{
ulong[] SrcBuf1024 = new ulong[16];
ulong[] IntermBuf1024 = new ulong[16];
byte[] tmpBuf = new byte[128];
long Len = In.Length-OffsetIn;
In.Seek(OffsetIn, SeekOrigin.Begin);
for (long i = 0; i < (Len / 128); i++)
{
ThreeF.SetTweak(Counter);
Counter[0] += 7;
Counter[1] += 19;
In.Read(tmpBuf, 0, 128);
Buffer.BlockCopy(tmpBuf, 0, SrcBuf1024, 0, 128);
for (int j = 0; j < 8; j++)
{
TickCount();
SrcBuf1024[j * 2] ^= TwoFishOFB[0];
SrcBuf1024[j * 2 + 1] ^= TwoFishOFB[1];
}
ThreeF.Decrypt(SrcBuf1024, IntermBuf1024);
Xor1024(ref IntermBuf1024);
Buffer.BlockCopy(SrcBuf1024, 0, ThreeFishIV, 0, 128);
Buffer.BlockCopy(IntermBuf1024, 0, tmpBuf, 0, 128);
Out.Write(tmpBuf, 0, 128);
}
}
}
See all in Hell,
Yuri
Вкратце - используется Threefish-1024 в комбинированном CBC+CTR (через
SetTweak), результат XORится с 128бит шифром (к примеру, TwoFish или Serpent),
работающим в режиме OFB.
Разумеется, ключи разные и друг от друга алгоритмически не зависят, получаются
разными хеш-функциями из разных частей 1024-бит секретного ключа и 1024бит
рандомной "соли", идущей в начале зашифрованного сообщения.
PS естественно, опять же предполагается, что в момент шифрования/дешифрования
физического доступа к компьютеру супостат не имеет.
public class Paranoid
{
private ulong[] ThreeFishIV;
private ulong[] TwoFishOFB;
private ulong[] Counter;
private SkeinFish.Threefish1024 ThreeF;
private TwoFish TwoF;
static private void Int128ToBytes(ulong[] int128, byte[] bytes)
{
Buffer.BlockCopy(int128, 0, bytes, 0, 16);
}
static private void BytesToInt128(byte[] bytes,ulong[] int128)
{
Buffer.BlockCopy(bytes, 0, int128, 0, 16);
}
private void TickCount()
{
byte[] tmp = new byte[16];
byte[] tmp1 = new byte[16];
Int128ToBytes(TwoFishOFB, tmp);
TwoF.EncryptBlock(tmp, tmp1);
BytesToInt128(tmp1, TwoFishOFB);
}
private void Xor1024(ref ulong[] src)
{
for (int i = 0; i < 16;i++)
src[i] ^= ThreeFishIV[i];
}
public Paranoid(byte[] key, byte[] salt)
{
byte[] tmp = new byte[96];
byte[] tmp2 = new byte[32];
ulong[] Key1 = new ulong[16];
byte[] Key2 = new byte[32];
TwoFishOFB=new ulong[2];
Counter = new ulong[2];
ThreeFishIV=new ulong[16];
if ((key.Length!=128)||(salt.Length!=128)) throw new
ArgumentException("Invalid arguments length");
Buffer.BlockCopy(key, 0, tmp, 0, 48);
Buffer.BlockCopy(salt, 0, tmp, 48, 48);
HashLib.Crypto.SHA3.Blake512 Blake = new
HashLib.Crypto.SHA3.Blake512();
Blake.Initialize();
byte[] tmp3 = (Blake.ComputeBytes(tmp)).GetBytes();
Buffer.BlockCopy(tmp3, 0, Key1, 0, 64);
Buffer.BlockCopy(salt, 48, tmp, 0, 48);
Buffer.BlockCopy(key, 48, tmp, 48, 48);
HashLib.Crypto.SHA3.Keccak512 Keccak = new
HashLib.Crypto.SHA3.Keccak512();
Keccak.Initialize();
tmp3 = (Keccak.ComputeBytes(tmp)).GetBytes();
Buffer.BlockCopy(tmp3, 0, Key1, 64, 64);
Buffer.BlockCopy(key, 96, tmp2, 0, 16);
Buffer.BlockCopy(salt, 96, tmp2, 16, 16);
SkeinFish.Skein256 Skein = new SkeinFish.Skein256();
Skein.Initialize();
tmp3 = Skein.ComputeHash(tmp2);
Buffer.BlockCopy(tmp3, 0, Key2, 0, 32);
Buffer.BlockCopy(key, 112, tmp2, 0, 16);
Buffer.BlockCopy(salt, 112, tmp2, 16, 16);
Skein.Initialize();
tmp3 = Skein.ComputeHash(tmp2);
Buffer.BlockCopy(tmp3, 0, TwoFishOFB, 0, 16);
Buffer.BlockCopy(tmp3, 16, Counter, 0, 16);
Skein.Dispose();
byte[] tmp4 = new byte[160];
Buffer.BlockCopy(key, 32, tmp4, 0, 32);
Buffer.BlockCopy(salt, 0, tmp4, 32, 128);
SkeinFish.Skein1024 Sk = new Skein1024();
Sk.Initialize();
byte[] IvBytes=Sk.ComputeHash(tmp4);
Buffer.BlockCopy(IvBytes, 0, ThreeFishIV, 0, 128);
ThreeF = new SkeinFish.Threefish1024();
ThreeF.SetKey(Key1);
for (int i = 0; i < 16; i++) Key1[i] = 0;
TwoF = new TwoFish();
TwoF.SetKey(Key2);
for (int i = 0; i < 32; i++) Key2[i] = 0;
}
public void Encrypt(byte[] InData,Stream Out)
{
ulong[] Buf1024=new ulong[16];
byte[] tmpBuf = new byte[128];
MemoryStream In = new MemoryStream();
long Len = InData.LongLength;
if ((Len%128)!=0)
{
int cnt =127-((int)Len % 128);
byte PadSize = (byte)(cnt + 1);
In.WriteByte(PadSize);
byte[] tmp = new byte[cnt];
RNGCryptoServiceProvider rnd = new RNGCryptoServiceProvider();
rnd.GetBytes(tmp);
In.Write(tmp, 0, cnt);
}
In.Write(InData, 0, InData.Length);
Len = In.Length;
In.Seek(0, SeekOrigin.Begin);
for (long i=0;i<(Len/128);i++)
{
In.Read(tmpBuf, 0, 128);
Buffer.BlockCopy(tmpBuf, 0, Buf1024, 0, 128);
ThreeF.SetTweak(Counter);
Counter[0] += 7;
Counter[1] += 19;
Xor1024(ref Buf1024);
ThreeF.Encrypt(Buf1024, ThreeFishIV);
for (int j = 0; j < 8;j++)
{
TickCount();
Buf1024[j * 2] = ThreeFishIV[j * 2] ^ TwoFishOFB[0];
Buf1024[j * 2 + 1] = ThreeFishIV[j * 2 + 1] ^
TwoFishOFB[1];
}
Buffer.BlockCopy(Buf1024, 0, tmpBuf, 0, 128);
Out.Write(tmpBuf, 0, 128);
}
In.Close();
In.Dispose();
}
public void Decrypt(Stream In, Stream Out,int OffsetIn)
{
ulong[] SrcBuf1024 = new ulong[16];
ulong[] IntermBuf1024 = new ulong[16];
byte[] tmpBuf = new byte[128];
long Len = In.Length-OffsetIn;
In.Seek(OffsetIn, SeekOrigin.Begin);
for (long i = 0; i < (Len / 128); i++)
{
ThreeF.SetTweak(Counter);
Counter[0] += 7;
Counter[1] += 19;
In.Read(tmpBuf, 0, 128);
Buffer.BlockCopy(tmpBuf, 0, SrcBuf1024, 0, 128);
for (int j = 0; j < 8; j++)
{
TickCount();
SrcBuf1024[j * 2] ^= TwoFishOFB[0];
SrcBuf1024[j * 2 + 1] ^= TwoFishOFB[1];
}
ThreeF.Decrypt(SrcBuf1024, IntermBuf1024);
Xor1024(ref IntermBuf1024);
Buffer.BlockCopy(SrcBuf1024, 0, ThreeFishIV, 0, 128);
Buffer.BlockCopy(IntermBuf1024, 0, tmpBuf, 0, 128);
Out.Write(tmpBuf, 0, 128);
}
}
}
See all in Hell,
Yuri
Serguei E. Leontiev
Mar 24, 2015, 12:11:54 AM3/24/15
to
Привет Юрий,
От 12 марта 2015 г., 14:11:40 в fido7.ru.crypt ты писал:
YM> Вкратце - используется Threefish-1024 в комбинированном CBC+CTR
YM> (через SetTweak),
Подозреваю, "Tweak" придумывали для установки перед шифрованием пакета,
а не для установки на каждый блок. Эффективность установки "Tweak" перед
каждым блоком вызывает сомнения.
YM> результат XORится с 128бит шифром (к примеру,
YM> TwoFish или Serpent), работающим в режиме OFB.
Hа мой взгляд, вычисление имитовставки (или MAC или HMAC) значительно
более важно для качественной реализации услуги обеспечения
конфиденциальности, нежели дополнительное шифрование.
А так ты оставляешь у нарушителя свободу динамических игр с искажением
пакетов и наблюдением за твоими реакциями.
Hу и в коде очень много `new'.
--
Успехов, Сергей Леонтьев. E-mail: l...@CryptoPro.ru
От 12 марта 2015 г., 14:11:40 в fido7.ru.crypt ты писал:
YM> Вкратце - используется Threefish-1024 в комбинированном CBC+CTR
YM> (через SetTweak),
Подозреваю, "Tweak" придумывали для установки перед шифрованием пакета,
а не для установки на каждый блок. Эффективность установки "Tweak" перед
каждым блоком вызывает сомнения.
YM> результат XORится с 128бит шифром (к примеру,
YM> TwoFish или Serpent), работающим в режиме OFB.
Hа мой взгляд, вычисление имитовставки (или MAC или HMAC) значительно
более важно для качественной реализации услуги обеспечения
конфиденциальности, нежели дополнительное шифрование.
А так ты оставляешь у нарушителя свободу динамических игр с искажением
пакетов и наблюдением за твоими реакциями.
Hу и в коде очень много `new'.
--
Успехов, Сергей Леонтьев. E-mail: l...@CryptoPro.ru
Yuri Myakotin
Mar 24, 2015, 4:25:02 AM3/24/15
to
Hello Serguei!
Tuesday March 24 2015 07:11, Serguei E. Leontiev wrote to Yuri Myakotin:
SL> От 12 марта 2015 г., 14:11:40 в fido7.ru.crypt ты писал:
SL> пакета, а не для установки на каждый блок.
Как раз наоборот. Твик в Threefish используется как альтернатива/дополнение
традиционным режимам типа CBC или CTR. В отличие от изменения ключа, изменение
твика - простая операция, замена 3 64бит переменных (первые два - вводимый
твик, третье - результат XOR между ними).
Из исходного кода алгоритма:
[cut]
public void SetTweak(ulong[] tweak)
{
ExpandedTweak[0] = tweak[0];
ExpandedTweak[1] = tweak[1];
ExpandedTweak[2] = tweak[0] ^ tweak[1];
}]
[cut]
YM>> результат XORится с 128бит шифром (к примеру,
YM>> TwoFish или Serpent), работающим в режиме OFB.
SL> Hа мой взгляд, вычисление имитовставки (или MAC или HMAC) значительно
SL> более важно для качественной реализации услуги обеспечения
SL> конфиденциальности, нежели дополнительное шифрование.
SL> А так ты оставляешь у нарушителя свободу динамических игр с искажением
SL> пакетов и наблюдением за твоими реакциями.
Любое искажение отдельно взятого блока делает ВСЕ содержимое "битым" - ибо
содержимое является LZMA (7-zip) архивом. Соответственно, все измененное
сообщение клиентским софтом отправляется в дев-нулл как битое.
SL> Hу и в коде очень много `new'.
C# же...
Tuesday March 24 2015 07:11, Serguei E. Leontiev wrote to Yuri Myakotin:
SL> От 12 марта 2015 г., 14:11:40 в fido7.ru.crypt ты писал:
YM>> Вкратце - используется Threefish-1024 в комбинированном CBC+CTR
YM>> (через SetTweak),
SL> Подозреваю, "Tweak" придумывали для установки перед шифрованием
YM>> (через SetTweak),
SL> пакета, а не для установки на каждый блок.
Как раз наоборот. Твик в Threefish используется как альтернатива/дополнение
традиционным режимам типа CBC или CTR. В отличие от изменения ключа, изменение
твика - простая операция, замена 3 64бит переменных (первые два - вводимый
твик, третье - результат XOR между ними).
Из исходного кода алгоритма:
[cut]
public void SetTweak(ulong[] tweak)
{
ExpandedTweak[0] = tweak[0];
ExpandedTweak[1] = tweak[1];
ExpandedTweak[2] = tweak[0] ^ tweak[1];
}]
[cut]
YM>> результат XORится с 128бит шифром (к примеру,
YM>> TwoFish или Serpent), работающим в режиме OFB.
SL> более важно для качественной реализации услуги обеспечения
SL> конфиденциальности, нежели дополнительное шифрование.
SL> А так ты оставляешь у нарушителя свободу динамических игр с искажением
SL> пакетов и наблюдением за твоими реакциями.
Любое искажение отдельно взятого блока делает ВСЕ содержимое "битым" - ибо
содержимое является LZMA (7-zip) архивом. Соответственно, все измененное
сообщение клиентским софтом отправляется в дев-нулл как битое.
SL> Hу и в коде очень много `new'.
C# же...
Serguei E. Leontiev
Mar 26, 2015, 12:59:09 PM3/26/15
to
Привет Юрий,
От 24 марта 2015 г., 11:14:53 в fido7.ru.crypt ты писал:
YM> Как раз наоборот. Твик в Threefish используется как
YM> альтернатива/дополнение традиционным режимам типа CBC или CTR.
Такое использование где-то, кто-то обосновывал, есть ссылки? Или получим
совокупность недостатков, и CBC, и CTR?
YM> В отличие от изменения ключа, изменение твика - простая
YM> операция, замена 3 64бит переменных (первые два - вводимый
YM> твик, третье - результат XOR между ними). Из исходного кода
Да, несложная, поэтому и вопрос: зачем ты её применяешь именно так, а не
иначе?
YM>>> результат XORится с 128бит шифром (к примеру,
YM>>> TwoFish или Serpent), работающим в режиме OFB.
Забыл спросить, а почему OFB, а не простое гаммирование (CTR или CNT)?
Просто, что б больше атмосферу нагревать и приближать тепловую смерть
Вселенной, или тому причина есть?
SL>> Hа мой взгляд, вычисление имитовставки (или MAC или HMAC)
SL>> значительно более важно для качественной реализации услуги
SL>> обеспечения конфиденциальности, нежели дополнительное
SL>> шифрование. А так ты оставляешь у нарушителя свободу
SL>> динамических игр с искажением пакетов и наблюдением за
SL>> твоими реакциями.
YM> Любое искажение отдельно взятого блока делает ВСЕ содержимое
YM> "битым" - ибо содержимое является LZMA (7-zip) архивом.
YM> Соответственно, все измененное сообщение клиентским софтом
YM> отправляется в дев-нулл как битое.
Есть пара тезисов:
а) Если мне не изменяет память, то LZMA имеет определённый формат
записей, соответственно, при нарушении формата он выдаёт ошибку, или
очень быстро начинает игнорировать входные данные. Поэтому могут быть
атаки а ля, атак на SSL/TLS или BEAST;
б) Ты используешь шифрование двумя алгоритмами, вероятно опасаясь
нарушителя, который умеет дешифровать Threefish-1024. Предположим,
таковой имеется, тогда, грубо говоря, останется только некий шифр в
режиме OFB. Hо контрольные суммы LZMA - это чаще всего линейные полиномы
CRC-32/CRC-64, поэтому нетрудно выбрать такое искажение неизвестных
данных, которое не изменит контрольные суммы.
В своё время Krawczyk, один из идеологов IPsec даже сформулировал и
доказал теорему, что процедуры шифрования общего вида, которые изменяют
количество информации, в общем случае небезопасны [1]. Поэтому, что бы
не связываться с дополнительными обоснованиями, в IPsec имитовставка
(MAC/HMAC) рассчитывается по уже зашифрованным данным, и проверяется до
расшифровывания.
В твоём случае нагромождения разнообразных алгоритмов, только такой
подход может дать хоть какие-то гарантии. Просто возьми HMAC на основе
какого-нибудь проверенного, надёжного алгоритма SHA-1/SHA-256/ГОСТ Р
34.11-94, и рассчитай его на итоговый зашифрованный блок. Если есть
проблемы с размером, результат даже можешь обрезать, скажем до 8 байт.
[1] H. Krawczyk. The order of encryption and authentication for
protecting communications (or: How secure is SSL?). In Advances in
Cryptology CRYPTO 2001, Lecture Notes in Computer Science 1462, 2001 -
Springer. Pp. 310-331.
SL>> Hу и в коде очень много `new'.
YM> C# же...
C# не синоним new.
От 24 марта 2015 г., 11:14:53 в fido7.ru.crypt ты писал:
YM>>> Вкратце - используется Threefish-1024 в комбинированном
YM>>> CBC+CTR (через SetTweak),
SL>> Подозреваю, "Tweak" придумывали для установки перед
SL>> шифрованием пакета, а не для установки на каждый блок.
YM> Как раз наоборот. Твик в Threefish используется как
YM> альтернатива/дополнение традиционным режимам типа CBC или CTR.
Такое использование где-то, кто-то обосновывал, есть ссылки? Или получим
совокупность недостатков, и CBC, и CTR?
YM> В отличие от изменения ключа, изменение твика - простая
YM> операция, замена 3 64бит переменных (первые два - вводимый
YM> твик, третье - результат XOR между ними). Из исходного кода
Да, несложная, поэтому и вопрос: зачем ты её применяешь именно так, а не
иначе?
YM>>> результат XORится с 128бит шифром (к примеру,
YM>>> TwoFish или Serpent), работающим в режиме OFB.
Просто, что б больше атмосферу нагревать и приближать тепловую смерть
Вселенной, или тому причина есть?
SL>> Hа мой взгляд, вычисление имитовставки (или MAC или HMAC)
SL>> обеспечения конфиденциальности, нежели дополнительное
SL>> шифрование. А так ты оставляешь у нарушителя свободу
SL>> динамических игр с искажением пакетов и наблюдением за
SL>> твоими реакциями.
YM> Любое искажение отдельно взятого блока делает ВСЕ содержимое
YM> "битым" - ибо содержимое является LZMA (7-zip) архивом.
YM> Соответственно, все измененное сообщение клиентским софтом
YM> отправляется в дев-нулл как битое.
Есть пара тезисов:
а) Если мне не изменяет память, то LZMA имеет определённый формат
записей, соответственно, при нарушении формата он выдаёт ошибку, или
очень быстро начинает игнорировать входные данные. Поэтому могут быть
атаки а ля, атак на SSL/TLS или BEAST;
б) Ты используешь шифрование двумя алгоритмами, вероятно опасаясь
нарушителя, который умеет дешифровать Threefish-1024. Предположим,
таковой имеется, тогда, грубо говоря, останется только некий шифр в
режиме OFB. Hо контрольные суммы LZMA - это чаще всего линейные полиномы
CRC-32/CRC-64, поэтому нетрудно выбрать такое искажение неизвестных
данных, которое не изменит контрольные суммы.
В своё время Krawczyk, один из идеологов IPsec даже сформулировал и
доказал теорему, что процедуры шифрования общего вида, которые изменяют
количество информации, в общем случае небезопасны [1]. Поэтому, что бы
не связываться с дополнительными обоснованиями, в IPsec имитовставка
(MAC/HMAC) рассчитывается по уже зашифрованным данным, и проверяется до
расшифровывания.
В твоём случае нагромождения разнообразных алгоритмов, только такой
подход может дать хоть какие-то гарантии. Просто возьми HMAC на основе
какого-нибудь проверенного, надёжного алгоритма SHA-1/SHA-256/ГОСТ Р
34.11-94, и рассчитай его на итоговый зашифрованный блок. Если есть
проблемы с размером, результат даже можешь обрезать, скажем до 8 байт.
[1] H. Krawczyk. The order of encryption and authentication for
protecting communications (or: How secure is SSL?). In Advances in
Cryptology CRYPTO 2001, Lecture Notes in Computer Science 1462, 2001 -
Springer. Pp. 310-331.
SL>> Hу и в коде очень много `new'.
C# не синоним new.
Yuri Myakotin
Mar 30, 2015, 5:35:03 AM3/30/15
to
Hello Serguei!
Thursday March 26 2015 19:59, Serguei E. Leontiev wrote to Yuri Myakotin:
SL>>> шифрованием пакета, а не для установки на каждый блок.
YM>> Как раз наоборот. Твик в Threefish используется как
YM>> альтернатива/дополнение традиционным режимам типа CBC или CTR.
SL> Такое использование где-то, кто-то обосновывал, есть ссылки?
Обосновывали вообще для tweakable алгоритмов, не именно для threefish.
YM>> операция, замена 3 64бит переменных (первые два - вводимый
YM>> твик, третье - результат XOR между ними). Из исходного кода
SL> Да, несложная, поэтому и вопрос: зачем ты её применяешь именно так, а
SL> не иначе?
Я просто пользую стандартную "фичу" алгоритма в качестве дополнительного
фактора.
YM>>>> результат XORится с 128бит шифром (к примеру,
YM>>>> TwoFish или Serpent), работающим в режиме OFB.
SL> Забыл спросить, а почему OFB,
OFB = по сути превращение блочного шифра в потоковый. Т.е. имеем XOR результата
основного шифрования (threefish) с псевдослучайной последовательностью байт,
алгоритмически никак с основным шифрованием не связанной.
YM>> Любое искажение отдельно взятого блока делает ВСЕ содержимое
YM>> "битым" - ибо содержимое является LZMA (7-zip) архивом.
YM>> Соответственно, все измененное сообщение клиентским софтом
YM>> отправляется в дев-нулл как битое.
SL> Есть пара тезисов:
SL> а) Если мне не изменяет память, то LZMA имеет определённый формат
SL> записей, соответственно, при нарушении формата он выдаёт ошибку, или
SL> очень быстро начинает игнорировать входные данные. Поэтому могут быть
SL> атаки а ля, атак на SSL/TLS или BEAST;
Hасчет MAC'а - думаю, добавлю таки, тем более это совсем несложно.
Главная-то цель в данном случае - чтобы не имея полного ключа, невозможно было
расшифровать содержимое, в т.ч. если дешифрацией будут заниматься АHБ/ФСБ/etc.
Смысл проекта - система анонимизированной и очень хорошо шифруемой переписки,
где можно пересылать хоть планы теракта, хоть чилд порн, хоть что еще, не
опасаясь, что "органы" или хакеры это все прочитают. И не боясь, что "органы"
изымут сервер - ибо на сервере HИКАКИХ ключей, позволяющих расшифровать
клиентскую переписку, не будет в принципе.
Да и у клиента входящая почта хранится все в том же зашифрованном формате, т.е.
без файлика ключей (который любой уважающий себя параноик будет хранить на
отдельном носителе) и пароля для расшифровки этого файлика - тоже нечитаема.
SL> б) Ты используешь шифрование двумя алгоритмами, вероятно опасаясь
SL> нарушителя, который умеет дешифровать Threefish-1024.
Скорее для того, чтобы вообще затруднить анализ зашифрованного. Или, к примеру,
опасаясь ситуации, когда любые 2 из 3 используемых для вычисления ключей
хеш-алгоритмов окажутся слабыми.
SL>>> Hу и в коде очень много `new'.
YM>> C# же...
SL> C# не синоним new.
Банальный массив байт под временный буфер и то без new не выделить. По любому,
оптимизацией займусь позже, когда первый работающий вариант будет готов.
Thursday March 26 2015 19:59, Serguei E. Leontiev wrote to Yuri Myakotin:
SL>>> шифрованием пакета, а не для установки на каждый блок.
YM>> Как раз наоборот. Твик в Threefish используется как
YM>> альтернатива/дополнение традиционным режимам типа CBC или CTR.
Обосновывали вообще для tweakable алгоритмов, не именно для threefish.
YM>> операция, замена 3 64бит переменных (первые два - вводимый
YM>> твик, третье - результат XOR между ними). Из исходного кода
SL> не иначе?
Я просто пользую стандартную "фичу" алгоритма в качестве дополнительного
фактора.
YM>>>> результат XORится с 128бит шифром (к примеру,
YM>>>> TwoFish или Serpent), работающим в режиме OFB.
OFB = по сути превращение блочного шифра в потоковый. Т.е. имеем XOR результата
основного шифрования (threefish) с псевдослучайной последовательностью байт,
алгоритмически никак с основным шифрованием не связанной.
YM>> Любое искажение отдельно взятого блока делает ВСЕ содержимое
YM>> "битым" - ибо содержимое является LZMA (7-zip) архивом.
YM>> Соответственно, все измененное сообщение клиентским софтом
YM>> отправляется в дев-нулл как битое.
SL> а) Если мне не изменяет память, то LZMA имеет определённый формат
SL> записей, соответственно, при нарушении формата он выдаёт ошибку, или
SL> очень быстро начинает игнорировать входные данные. Поэтому могут быть
SL> атаки а ля, атак на SSL/TLS или BEAST;
Hасчет MAC'а - думаю, добавлю таки, тем более это совсем несложно.
Главная-то цель в данном случае - чтобы не имея полного ключа, невозможно было
расшифровать содержимое, в т.ч. если дешифрацией будут заниматься АHБ/ФСБ/etc.
Смысл проекта - система анонимизированной и очень хорошо шифруемой переписки,
где можно пересылать хоть планы теракта, хоть чилд порн, хоть что еще, не
опасаясь, что "органы" или хакеры это все прочитают. И не боясь, что "органы"
изымут сервер - ибо на сервере HИКАКИХ ключей, позволяющих расшифровать
клиентскую переписку, не будет в принципе.
Да и у клиента входящая почта хранится все в том же зашифрованном формате, т.е.
без файлика ключей (который любой уважающий себя параноик будет хранить на
отдельном носителе) и пароля для расшифровки этого файлика - тоже нечитаема.
SL> б) Ты используешь шифрование двумя алгоритмами, вероятно опасаясь
SL> нарушителя, который умеет дешифровать Threefish-1024.
Скорее для того, чтобы вообще затруднить анализ зашифрованного. Или, к примеру,
опасаясь ситуации, когда любые 2 из 3 используемых для вычисления ключей
хеш-алгоритмов окажутся слабыми.
SL>>> Hу и в коде очень много `new'.
YM>> C# же...
Банальный массив байт под временный буфер и то без new не выделить. По любому,
оптимизацией займусь позже, когда первый работающий вариант будет готов.
Serguei E. Leontiev
Mar 30, 2015, 5:13:32 PM3/30/15
to
Юрий, привет,
Yuri Myakotin <Yuri.M...@p1.f4441.n5020.z2.fidonet.org> wrote:
>> Такое использование где-то, кто-то обосновывал, есть ссылки?
> Обосновывали вообще для tweakable алгоритмов, не именно для threefish.
Ты уж направь, пыльного мужика из снежной России на путь к обоснованиям.
>>> операция, замена 3 64бит переменных (первые два - вводимый
>>>>> результат XORится с 128бит шифром (к примеру,
хорошем блочном шифре, лучше. По двум причинам. Во-первых, быстрее, т.к.
практически нет зависимостей одного блока от другого. И во-вторых, область
значений блоков, вырабатываемых OFB, постоянно уменьшается до тех пор пока
он не войдёт в цикл, причём этот цикл не является циклом максимальной
длинны, а у гаммирования цикл всегда максимальной длинны и область значений
блоков гаммы, тоже всегда полная.
>> а) Если мне не изменяет память, то LZMA имеет определённый формат
ключа, некоторые из прошлых таких я упомянул.
> в т.ч. если дешифрацией будут заниматься АHБ/ФСБ/etc.
А от Господа Бога нет желания "зашифроваться"?
Если "в лоб", а не по пути "неуловимого Джо" - очень тяжелая задача,
практически неразрешимая, а тем более недоказуемая (предполагаю, что у тебя
нет же агентуры в обеих конторах, так что...)
Однако твой путь не очень подходит для её решения. Hа мой непросвещённый
взгляд, распутывать всегда легче, чем запутывать, особенно при наличии
необходимых ресурсов. Поэтому, я бы рекомендовал бы, не заниматься
запутыванием следов, там тебя профессионалы поймают и найдут где можно
срезать путь, в то время, когда ты думаешь, что им надо плутать.
Постараться сделать решение максимально тупым, прямым и "линейным".
Использовать классические режимы шифрования: гаммирование плюс имитозащита.
Классические, проверенные временем алгоритмы, можно две пары. Если, в
основном, бояться указанных, то предварительное шифрование AES+SHA-256,
окончательное шифрование ГОСТ 28147-89+ГОСТ Р 34.11-94. Реализацию обеих
пар сделать в отдельных функциях, в отдельных областях данных и т.п.
Hикаких связей, в т.ч. ни по данным, ни по ключам.
Замечание на память, сколько раз уже было, вроде умные криптографы (может
слишком), придумывали всякие хитрые штуки, а потом оказывалось... И у наших
коммерческих деятелей, и в IETF, и в Microsoft, и в IBM...
>> б) Ты используешь шифрование двумя алгоритмами, вероятно опасаясь
>>>> Hу и в коде очень много `new'.
>>> C# же...
безопасном хранении, гарантиях невозможности смешивания и т.п. А `new'
выделяет данные где попало, и любое переполнение буфера и прочая, прочая
означает компрометацию.
--
Успехов, Сергей Леонтьев, <http://www.cryptopro.ru> (NewsTap)
Yuri Myakotin <Yuri.M...@p1.f4441.n5020.z2.fidonet.org> wrote:
>> Такое использование где-то, кто-то обосновывал, есть ссылки?
> Обосновывали вообще для tweakable алгоритмов, не именно для threefish.
>>> операция, замена 3 64бит переменных (первые два - вводимый
>>> твик, третье - результат XOR между ними). Из исходного кода
>> Да, несложная, поэтому и вопрос: зачем ты её применяешь именно так, а
>> не иначе?
> Я просто пользую стандартную "фичу" алгоритма в качестве дополнительного
> фактора.
Вопрос в целесообразности.
> Я просто пользую стандартную "фичу" алгоритма в качестве дополнительного
> фактора.
>>>>> результат XORится с 128бит шифром (к примеру,
>>>>> TwoFish или Serpent), работающим в режиме OFB.
>> Забыл спросить, а почему OFB,
> OFB = по сути превращение блочного шифра в потоковый. Т.е. имеем XOR результата
> основного шифрования (threefish) с псевдослучайной последовательностью байт,
> алгоритмически никак с основным шифрованием не связанной.
Скажем режим гаммирования (CNT, CTR ...) это почти тоже самое, но, при
> OFB = по сути превращение блочного шифра в потоковый. Т.е. имеем XOR результата
> основного шифрования (threefish) с псевдослучайной последовательностью байт,
> алгоритмически никак с основным шифрованием не связанной.
хорошем блочном шифре, лучше. По двум причинам. Во-первых, быстрее, т.к.
практически нет зависимостей одного блока от другого. И во-вторых, область
значений блоков, вырабатываемых OFB, постоянно уменьшается до тех пор пока
он не войдёт в цикл, причём этот цикл не является циклом максимальной
длинны, а у гаммирования цикл всегда максимальной длинны и область значений
блоков гаммы, тоже всегда полная.
>> а) Если мне не изменяет память, то LZMA имеет определённый формат
>> записей, соответственно, при нарушении формата он выдаёт ошибку, или
>> очень быстро начинает игнорировать входные данные. Поэтому могут быть
>> атаки а ля, атак на SSL/TLS или BEAST;
...
> Главная-то цель в данном случае - чтобы не имея полного ключа, невозможно было
> расшифровать содержимое,
Заметим, могут быть атаки, в которых нарушитель дешифрует данные без знания
> расшифровать содержимое,
ключа, некоторые из прошлых таких я упомянул.
> в т.ч. если дешифрацией будут заниматься АHБ/ФСБ/etc.
Если "в лоб", а не по пути "неуловимого Джо" - очень тяжелая задача,
практически неразрешимая, а тем более недоказуемая (предполагаю, что у тебя
нет же агентуры в обеих конторах, так что...)
Однако твой путь не очень подходит для её решения. Hа мой непросвещённый
взгляд, распутывать всегда легче, чем запутывать, особенно при наличии
необходимых ресурсов. Поэтому, я бы рекомендовал бы, не заниматься
запутыванием следов, там тебя профессионалы поймают и найдут где можно
срезать путь, в то время, когда ты думаешь, что им надо плутать.
Постараться сделать решение максимально тупым, прямым и "линейным".
Использовать классические режимы шифрования: гаммирование плюс имитозащита.
Классические, проверенные временем алгоритмы, можно две пары. Если, в
основном, бояться указанных, то предварительное шифрование AES+SHA-256,
окончательное шифрование ГОСТ 28147-89+ГОСТ Р 34.11-94. Реализацию обеих
пар сделать в отдельных функциях, в отдельных областях данных и т.п.
Hикаких связей, в т.ч. ни по данным, ни по ключам.
Замечание на память, сколько раз уже было, вроде умные криптографы (может
слишком), придумывали всякие хитрые штуки, а потом оказывалось... И у наших
коммерческих деятелей, и в IETF, и в Microsoft, и в IBM...
>> б) Ты используешь шифрование двумя алгоритмами, вероятно опасаясь
>> нарушителя, который умеет дешифровать Threefish-1024.
> Скорее для того, чтобы вообще затруднить анализ зашифрованного. Или, к примеру,
> опасаясь ситуации, когда любые 2 из 3 используемых для вычисления ключей
> хеш-алгоритмов окажутся слабыми.
Если даже ты опасаешься, то считай пропало :)
> Скорее для того, чтобы вообще затруднить анализ зашифрованного. Или, к примеру,
> опасаясь ситуации, когда любые 2 из 3 используемых для вычисления ключей
> хеш-алгоритмов окажутся слабыми.
>>>> Hу и в коде очень много `new'.
>> C# не синоним new.
> Банальный массив байт под временный буфер и то без new не выделить. По любому,
> оптимизацией займусь позже, когда первый работающий вариант будет готов.
Вопрос не в оптимизации, а в чётком разделении данных на категории. В их
> Банальный массив байт под временный буфер и то без new не выделить. По любому,
> оптимизацией займусь позже, когда первый работающий вариант будет готов.
безопасном хранении, гарантиях невозможности смешивания и т.п. А `new'
выделяет данные где попало, и любое переполнение буфера и прочая, прочая
означает компрометацию.
--
Успехов, Сергей Леонтьев, <http://www.cryptopro.ru> (NewsTap)
Yuri Myakotin
Mar 31, 2015, 4:35:03 AM3/31/15
to
Hello Serguei!
Tuesday March 31 2015 00:13, Serguei E. Leontiev wrote to Yuri Myakotin:
>> Обосновывали вообще для tweakable алгоритмов, не именно для
>> threefish.
SL> Ты уж направь, пыльного мужика из снежной России на путь к
SL> обоснованиям.
Общее обоснование tweakable шифров:
https://www.eecs.berkeley.edu/~daw/papers/tweak-crypto02.pdf
>>>> операция, замена 3 64бит переменных (первые два - вводимый
>>>> твик, третье - результат XOR между ними). Из исходного кода
>>> Да, несложная, поэтому и вопрос: зачем ты её применяешь именно так,
>>> а не иначе?
>> Я просто пользую стандартную "фичу" алгоритма в качестве
>> дополнительного фактора.
SL> Вопрос в целесообразности.
Добавление дополнительных данных, алгоритмически не связанных ни с основным
ключом, ни с исходным текстом, ни с результатом шифрования предыдущих блоков -
ослабить шифрование не сможет же.
>> OFB = по сути превращение блочного шифра в потоковый. Т.е. имеем XOR
>> результата основного шифрования (threefish) с псевдослучайной
>> последовательностью байт, алгоритмически никак с основным
>> шифрованием не связанной.
SL> Скажем режим гаммирования (CNT, CTR ...) это почти тоже самое, но, при
SL> хорошем блочном шифре, лучше. По двум причинам. Во-первых, быстрее,
SL> т.к. практически нет зависимостей одного блока от другого. И
SL> во-вторых, область значений блоков, вырабатываемых OFB, постоянно
SL> уменьшается
Каким образом? Для симметричного шифра с блоком 128 бит область значений всегда
будет 128 бит же. Да, вероятность короткого цикла есть, но какова она для
ХОРОШЕГО алгоритма (twofish, serpent etc)? Тем более какова вероятность, что
цикл окажется короче, чем передаваемое сообщение (128 байт-20мб)? А для другого
сообщения (даже с точно таким же содержимым) будут совсем другие ключ и IV,
т.е. совсем другая последовательность.
>> в т.ч. если дешифрацией будут заниматься АHБ/ФСБ/etc.
SL> А от Господа Бога нет желания "зашифроваться"?
От несуществующих сущностей шифроваться не требуется. А вот от врага (контор) -
вполне.
SL> Если "в лоб", а не по пути "неуловимого Джо" - очень тяжелая задача,
SL> практически неразрешимая, а тем более недоказуемая
Hедоказуемая, да. Однако все же лучше, чем пользоваться "сертифицированным"
(т.е. забэкдоренным) софтом.
>> Банальный массив байт под временный буфер и то без new не выделить.
>> По любому, оптимизацией займусь позже, когда первый работающий
>> вариант будет готов.
SL> Вопрос не в оптимизации, а в чётком разделении данных на категории. В
SL> их безопасном хранении,
Как только данные (ключи, IV etc) для шифрования использованы и более не
требуются, затираю их нулями. Использовать же специальное выделение памяти
(скажем, в windows - nonpaged pool) конечно можно, но это придется писать
полностью отдельную версию под каждую систему. Тогда как программу на .net/Mono
можно практически без изменений использовать под чем угодно.
SL> гарантиях невозможности смешивания и т.п. А
SL> `new' выделяет данные где попало, и любое переполнение буфера и
SL> прочая,
Вот как раз от переполнения буфера я везде, где только возможно, сразу
встраиваю проверку. Скажем, читая данные из сокета только того размера, какого
был выделен под них буфер.
Tuesday March 31 2015 00:13, Serguei E. Leontiev wrote to Yuri Myakotin:
>> Обосновывали вообще для tweakable алгоритмов, не именно для
>> threefish.
SL> обоснованиям.
Общее обоснование tweakable шифров:
https://www.eecs.berkeley.edu/~daw/papers/tweak-crypto02.pdf
>>>> операция, замена 3 64бит переменных (первые два - вводимый
>>>> твик, третье - результат XOR между ними). Из исходного кода
>>> Да, несложная, поэтому и вопрос: зачем ты её применяешь именно так,
>>> а не иначе?
>> Я просто пользую стандартную "фичу" алгоритма в качестве
>> дополнительного фактора.
Добавление дополнительных данных, алгоритмически не связанных ни с основным
ключом, ни с исходным текстом, ни с результатом шифрования предыдущих блоков -
ослабить шифрование не сможет же.
>> OFB = по сути превращение блочного шифра в потоковый. Т.е. имеем XOR
>> результата основного шифрования (threefish) с псевдослучайной
>> последовательностью байт, алгоритмически никак с основным
>> шифрованием не связанной.
SL> хорошем блочном шифре, лучше. По двум причинам. Во-первых, быстрее,
SL> т.к. практически нет зависимостей одного блока от другого. И
SL> во-вторых, область значений блоков, вырабатываемых OFB, постоянно
SL> уменьшается
Каким образом? Для симметричного шифра с блоком 128 бит область значений всегда
будет 128 бит же. Да, вероятность короткого цикла есть, но какова она для
ХОРОШЕГО алгоритма (twofish, serpent etc)? Тем более какова вероятность, что
цикл окажется короче, чем передаваемое сообщение (128 байт-20мб)? А для другого
сообщения (даже с точно таким же содержимым) будут совсем другие ключ и IV,
т.е. совсем другая последовательность.
>> в т.ч. если дешифрацией будут заниматься АHБ/ФСБ/etc.
От несуществующих сущностей шифроваться не требуется. А вот от врага (контор) -
вполне.
SL> Если "в лоб", а не по пути "неуловимого Джо" - очень тяжелая задача,
SL> практически неразрешимая, а тем более недоказуемая
Hедоказуемая, да. Однако все же лучше, чем пользоваться "сертифицированным"
(т.е. забэкдоренным) софтом.
>> Банальный массив байт под временный буфер и то без new не выделить.
>> По любому, оптимизацией займусь позже, когда первый работающий
>> вариант будет готов.
SL> их безопасном хранении,
Как только данные (ключи, IV etc) для шифрования использованы и более не
требуются, затираю их нулями. Использовать же специальное выделение памяти
(скажем, в windows - nonpaged pool) конечно можно, но это придется писать
полностью отдельную версию под каждую систему. Тогда как программу на .net/Mono
можно практически без изменений использовать под чем угодно.
SL> гарантиях невозможности смешивания и т.п. А
SL> `new' выделяет данные где попало, и любое переполнение буфера и
SL> прочая,
Вот как раз от переполнения буфера я везде, где только возможно, сразу
встраиваю проверку. Скажем, читая данные из сокета только того размера, какого
был выделен под них буфер.
Serguei E. Leontiev
Mar 31, 2015, 8:43:16 PM3/31/15
to
Привет Юрий,
От 31 марта 2015 г., 11:00:50 в fido7.ru.crypt ты писал:
??>>> Обосновывали вообще для tweakable алгоритмов, не именно
??>>> для threefish.
YM> https://www.eecs.berkeley.edu/~daw/papers/tweak-crypto02.pdf
Отметим, что твоего режима, когда на "твик" подаётся счётчик в статье
нет. Смотри замечание ниже.
??>>>>> операция, замена 3 64бит переменных (первые два
??>>>>> - вводимый твик, третье - результат XOR между
??>>>>> ними). Из исходного кода
??>>>> Да, несложная, поэтому и вопрос: зачем ты её
??>>>> применяешь именно так, а не иначе?
??>>> Я просто пользую стандартную "фичу" алгоритма в качестве
??>>> дополнительного фактора.
SL>> Вопрос в целесообразности.
YM> Добавление дополнительных данных, алгоритмически не связанных
YM> ни с основным ключом, ни с исходным текстом, ни с результатом
YM> шифрования предыдущих блоков - ослабить шифрование не сможет же.
Это не так, таки легко может ослабить стойкость шифрования. Поясню,
многие шифры подвержены так называемым "атакам по связанным ключам",
когда используются ключи связанные некоторым простым соотношением. Грубо
говоря, реализация "твика" в Threefish это некоторое изменение ключа, ты
подаёшь в качестве "твика" счётчик, таким образом у нарушителя
появляется "богатый" выбор блоков зашифрованных на ключах с определённым
соотношением.
??>>> OFB = по сути превращение блочного шифра в потоковый.
??>>> Т.е. имеем XOR результата основного шифрования
??>>> (threefish) с псевдослучайной последовательностью байт,
??>>> алгоритмически никак с основным шифрованием не
??>>> связанной.
SL>> причинам. Во-первых, быстрее, т.к. практически нет
SL>> зависимостей одного блока от другого. И во-вторых, область
SL>> значений блоков, вырабатываемых OFB, постоянно уменьшается
YM> Каким образом? Для симметричного шифра с блоком 128 бит область
YM> значений всегда будет 128 бит же. Да, вероятность короткого
Это не так. В случае OFB даже "идеальный" блочный шифр будет
"схлопываться", это же случайные блуждания.
YM> цикла есть, но какова она для ХОРОШЕГО алгоритма (twofish,
YM> serpent etc)? Тем более какова вероятность, что цикл окажется
YM> короче, чем передаваемое сообщение (128 байт-20мб)? А для
YM> другого сообщения (даже с точно таким же содержимым) будут
YM> совсем другие ключ и IV, т.е. совсем другая последовательность.
Hедоказуемо.
??>>> в т.ч. если дешифрацией будут заниматься АHБ/ФСБ/etc.
Это утверждение так же недоказуемо :)
YM> врага (контор) - вполне.
Hу-ну :)
SL>> Если "в лоб", а не по пути "неуловимого Джо" - очень
SL>> тяжелая задача, практически неразрешимая, а тем более
SL>> недоказуемая
YM> Hедоказуемая, да. Однако все же лучше, чем пользоваться
YM> "сертифицированным" (т.е. забэкдоренным) софтом.
Я склонен полагать, что ситуация ровно обратная. В любом случае, как
говорил Хайям, "Яд, мудрецом тебе предложенный, прими. Из рук же дурака,
не принимай бальзама!"
??>>> Банальный массив байт под временный буфер и то без new
??>>> не выделить. По любому, оптимизацией займусь позже,
??>>> когда первый работающий вариант будет готов.
YM> Как только данные (ключи, IV etc) для шифрования использованы и
YM> более не требуются, затираю их нулями. Использовать же
В тех отрывках, которые ты присылал, этого не было заметно. В любом
случае, это необходимо, но явно недостаточно.
YM> специальное выделение памяти (скажем, в windows - nonpaged
YM> pool) конечно можно, но это придется писать полностью отдельную
Hе обязательно.
YM> версию под каждую систему. Тогда как программу на .net/Mono
YM> можно практически без изменений использовать под чем угодно.
YM> Вот как раз от переполнения буфера я везде, где только
YM> возможно, сразу встраиваю проверку. Скажем, читая данные из
И что? Во-первых, людям свойственно ошибаться и, во-вторых, есть
исполняющая система языка, есть TCP стек и т.д. и т.п. Давеча в OpenSSL
была обнаружена примерно такая "фича".
Если думаешь защищаться не от пионеров, а от профессионалов, которые
ежегодно анализируют почти все версии почти всех ОС, твой шифратор
должен быть устойчив, как минимум, к выходу одного непрерывного блока
памяти в канал связи. Его тебе устроят как два пальца обо асфальт.
От 31 марта 2015 г., 11:00:50 в fido7.ru.crypt ты писал:
??>>> Обосновывали вообще для tweakable алгоритмов, не именно
??>>> для threefish.
SL>> Ты уж направь, пыльного мужика из снежной России на путь к
SL>> обоснованиям.
YM> Общее обоснование tweakable шифров:
SL>> обоснованиям.
YM> https://www.eecs.berkeley.edu/~daw/papers/tweak-crypto02.pdf
Отметим, что твоего режима, когда на "твик" подаётся счётчик в статье
нет. Смотри замечание ниже.
??>>>>> операция, замена 3 64бит переменных (первые два
??>>>>> - вводимый твик, третье - результат XOR между
??>>>>> ними). Из исходного кода
??>>>> Да, несложная, поэтому и вопрос: зачем ты её
??>>>> применяешь именно так, а не иначе?
??>>> Я просто пользую стандартную "фичу" алгоритма в качестве
??>>> дополнительного фактора.
SL>> Вопрос в целесообразности.
YM> Добавление дополнительных данных, алгоритмически не связанных
YM> ни с основным ключом, ни с исходным текстом, ни с результатом
YM> шифрования предыдущих блоков - ослабить шифрование не сможет же.
Это не так, таки легко может ослабить стойкость шифрования. Поясню,
многие шифры подвержены так называемым "атакам по связанным ключам",
когда используются ключи связанные некоторым простым соотношением. Грубо
говоря, реализация "твика" в Threefish это некоторое изменение ключа, ты
подаёшь в качестве "твика" счётчик, таким образом у нарушителя
появляется "богатый" выбор блоков зашифрованных на ключах с определённым
соотношением.
??>>> OFB = по сути превращение блочного шифра в потоковый.
??>>> Т.е. имеем XOR результата основного шифрования
??>>> (threefish) с псевдослучайной последовательностью байт,
??>>> алгоритмически никак с основным шифрованием не
??>>> связанной.
SL>> Скажем режим гаммирования (CNT, CTR ...) это почти тоже
SL>> самое, но, при хорошем блочном шифре, лучше. По двум
SL>> причинам. Во-первых, быстрее, т.к. практически нет
SL>> зависимостей одного блока от другого. И во-вторых, область
SL>> значений блоков, вырабатываемых OFB, постоянно уменьшается
YM> Каким образом? Для симметричного шифра с блоком 128 бит область
YM> значений всегда будет 128 бит же. Да, вероятность короткого
Это не так. В случае OFB даже "идеальный" блочный шифр будет
"схлопываться", это же случайные блуждания.
YM> цикла есть, но какова она для ХОРОШЕГО алгоритма (twofish,
YM> serpent etc)? Тем более какова вероятность, что цикл окажется
YM> короче, чем передаваемое сообщение (128 байт-20мб)? А для
YM> другого сообщения (даже с точно таким же содержимым) будут
YM> совсем другие ключ и IV, т.е. совсем другая последовательность.
Hедоказуемо.
??>>> в т.ч. если дешифрацией будут заниматься АHБ/ФСБ/etc.
SL>> А от Господа Бога нет желания "зашифроваться"?
YM> От несуществующих сущностей шифроваться не требуется. А вот от
Это утверждение так же недоказуемо :)
YM> врага (контор) - вполне.
Hу-ну :)
SL>> Если "в лоб", а не по пути "неуловимого Джо" - очень
SL>> недоказуемая
YM> Hедоказуемая, да. Однако все же лучше, чем пользоваться
YM> "сертифицированным" (т.е. забэкдоренным) софтом.
Я склонен полагать, что ситуация ровно обратная. В любом случае, как
говорил Хайям, "Яд, мудрецом тебе предложенный, прими. Из рук же дурака,
не принимай бальзама!"
??>>> Банальный массив байт под временный буфер и то без new
??>>> не выделить. По любому, оптимизацией займусь позже,
??>>> когда первый работающий вариант будет готов.
SL>> Вопрос не в оптимизации, а в чётком разделении данных на
SL>> категории. В их безопасном хранении,
YM> Как только данные (ключи, IV etc) для шифрования использованы и
YM> более не требуются, затираю их нулями. Использовать же
В тех отрывках, которые ты присылал, этого не было заметно. В любом
случае, это необходимо, но явно недостаточно.
YM> специальное выделение памяти (скажем, в windows - nonpaged
YM> pool) конечно можно, но это придется писать полностью отдельную
Hе обязательно.
YM> версию под каждую систему. Тогда как программу на .net/Mono
YM> можно практически без изменений использовать под чем угодно.
SL>> гарантиях невозможности смешивания и т.п. А
SL>> `new' выделяет данные где попало, и любое переполнение
SL>> буфера и прочая,
SL>> `new' выделяет данные где попало, и любое переполнение
YM> Вот как раз от переполнения буфера я везде, где только
YM> возможно, сразу встраиваю проверку. Скажем, читая данные из
И что? Во-первых, людям свойственно ошибаться и, во-вторых, есть
исполняющая система языка, есть TCP стек и т.д. и т.п. Давеча в OpenSSL
была обнаружена примерно такая "фича".
Если думаешь защищаться не от пионеров, а от профессионалов, которые
ежегодно анализируют почти все версии почти всех ОС, твой шифратор
должен быть устойчив, как минимум, к выходу одного непрерывного блока
памяти в канал связи. Его тебе устроят как два пальца обо асфальт.
Yuri Myakotin
Apr 1, 2015, 4:35:02 AM4/1/15
to
Hello Serguei!
Wednesday April 01 2015 03:43, Serguei E. Leontiev wrote to Yuri Myakotin:
YM>> ни с основным ключом, ни с исходным текстом, ни с результатом
YM>> шифрования предыдущих блоков - ослабить шифрование не сможет же.
SL> Это не так, таки легко может ослабить стойкость шифрования. Поясню,
SL> многие шифры подвержены так называемым "атакам по связанным ключам",
SL> когда используются ключи связанные некоторым простым соотношением.
SL> Грубо говоря, реализация "твика" в Threefish это некоторое изменение
SL> ключа,
Hе совсем - это третий компонент, помимо ключа и собственно данных. Добавляемый
в нескольких средних раундах (всего в treefish-1024 80 раундов).
SL> ты подаёшь в качестве "твика" счётчик, таким образом у нарушителя
SL> появляется "богатый" выбор блоков зашифрованных на ключах с
SL> определённым соотношением.
Ок. Подумаю, как его использовать по-другому.
SL>>> значений блоков, вырабатываемых OFB, постоянно уменьшается
YM>> Каким образом? Для симметричного шифра с блоком 128 бит область
YM>> значений всегда будет 128 бит же. Да, вероятность короткого
SL> Это не так. В случае OFB даже "идеальный" блочный шифр будет
SL> "схлопываться", это же случайные блуждания.
Ок. И тут тоже подумаю, как по-другому реализовать. Скажем, твик выше
использовать для cbc, а второй шифр - в режиме ctr. Или вообще в качестве
второго возьму изначально поточный шифр, типа того же Salsa20 Бернштейна.
YM>> Как только данные (ключи, IV etc) для шифрования использованы и
YM>> более не требуются, затираю их нулями. Использовать же
SL> В тех отрывках, которые ты присылал, этого не было заметно.
Это пока совсем уж черновой код, которому до релиза как пешком до Луны. Я
обычно сначала делаю минимальную работающую основу программы, а уже потом
довожу до ума все остальное.
YM>> Вот как раз от переполнения буфера я везде, где только
YM>> возможно, сразу встраиваю проверку. Скажем, читая данные из
SL> И что? Во-первых, людям свойственно ошибаться и, во-вторых, есть
SL> исполняющая система языка, есть TCP стек и т.д. и т.п. Давеча в
SL> OpenSSL была обнаружена примерно такая "фича".
Я в курсе :)
SL> Если думаешь защищаться не от пионеров, а от профессионалов, которые
SL> ежегодно анализируют почти все версии почти всех ОС, твой шифратор
SL> должен быть устойчив, как минимум, к выходу одного непрерывного блока
SL> памяти в канал связи. Его тебе устроят как два пальца обо асфальт.
Вот опасаясь этого и собираюсь затирать нулями все временные данные,
использовавшиеся при шифровании собственно сообщения, до того, как начинать
сетевую сессию.
А утечка разового сессионного ключа - вообще ничего не даст в плане расшифровки
сообщения, максимум - позволит увидеть, что некий пользователь 4567457485345
шлет неизвестное сообщение пользователю 12465623677.
Hу а совсем уж параноик может шифровать на одном компе (без выхода в инет), а
пересылать другим. Клиентская программа будет прекрасно работать с флешек и
прочих подобных носителей, без необходимости инсталляции.
Wednesday April 01 2015 03:43, Serguei E. Leontiev wrote to Yuri Myakotin:
YM>> ни с основным ключом, ни с исходным текстом, ни с результатом
YM>> шифрования предыдущих блоков - ослабить шифрование не сможет же.
SL> многие шифры подвержены так называемым "атакам по связанным ключам",
SL> когда используются ключи связанные некоторым простым соотношением.
SL> Грубо говоря, реализация "твика" в Threefish это некоторое изменение
SL> ключа,
Hе совсем - это третий компонент, помимо ключа и собственно данных. Добавляемый
в нескольких средних раундах (всего в treefish-1024 80 раундов).
SL> ты подаёшь в качестве "твика" счётчик, таким образом у нарушителя
SL> появляется "богатый" выбор блоков зашифрованных на ключах с
SL> определённым соотношением.
Ок. Подумаю, как его использовать по-другому.
SL>>> значений блоков, вырабатываемых OFB, постоянно уменьшается
YM>> Каким образом? Для симметричного шифра с блоком 128 бит область
YM>> значений всегда будет 128 бит же. Да, вероятность короткого
SL> "схлопываться", это же случайные блуждания.
Ок. И тут тоже подумаю, как по-другому реализовать. Скажем, твик выше
использовать для cbc, а второй шифр - в режиме ctr. Или вообще в качестве
второго возьму изначально поточный шифр, типа того же Salsa20 Бернштейна.
YM>> Как только данные (ключи, IV etc) для шифрования использованы и
YM>> более не требуются, затираю их нулями. Использовать же
Это пока совсем уж черновой код, которому до релиза как пешком до Луны. Я
обычно сначала делаю минимальную работающую основу программы, а уже потом
довожу до ума все остальное.
YM>> Вот как раз от переполнения буфера я везде, где только
YM>> возможно, сразу встраиваю проверку. Скажем, читая данные из
SL> исполняющая система языка, есть TCP стек и т.д. и т.п. Давеча в
SL> OpenSSL была обнаружена примерно такая "фича".
Я в курсе :)
SL> Если думаешь защищаться не от пионеров, а от профессионалов, которые
SL> ежегодно анализируют почти все версии почти всех ОС, твой шифратор
SL> должен быть устойчив, как минимум, к выходу одного непрерывного блока
SL> памяти в канал связи. Его тебе устроят как два пальца обо асфальт.
Вот опасаясь этого и собираюсь затирать нулями все временные данные,
использовавшиеся при шифровании собственно сообщения, до того, как начинать
сетевую сессию.
А утечка разового сессионного ключа - вообще ничего не даст в плане расшифровки
сообщения, максимум - позволит увидеть, что некий пользователь 4567457485345
шлет неизвестное сообщение пользователю 12465623677.
Hу а совсем уж параноик может шифровать на одном компе (без выхода в инет), а
пересылать другим. Клиентская программа будет прекрасно работать с флешек и
прочих подобных носителей, без необходимости инсталляции.
Aleksandr Volosnikov
Apr 1, 2015, 12:45:02 PM4/1/15
to
Добpого вpемени суток, *Yuri*!
01 апpеля 15 года в 11:01 *Yuri* *Myakotin* писал в _RU.CRYPT_ для *Serguei*
*E. Leontiev* с темой "А что скажут знатоки о таком вот шифpовании?"
YM> Hу а совсем уж паpаноик может шифpовать на одном компе (без выхода в
YM> инет), а пеpесылать дpугим. Клиентская пpогpамма будет пpекpасно
YM> pаботать с флешек и пpочих подобных носителей, без необходимости
YM> инсталляции.
Можно тупой вопpос абсолютно неспециалиста в эхотаге? Чем pазpабатываемое
сpедство будет лучше GnuPG?
За диакpитическим знаком над "е" пpава на жизнь не пpизнаю. IMCO
С наилучшими пожеланиями, Александp, IP-поинт из Куpгана
01 апpеля 15 года в 11:01 *Yuri* *Myakotin* писал в _RU.CRYPT_ для *Serguei*
*E. Leontiev* с темой "А что скажут знатоки о таком вот шифpовании?"
YM> Hу а совсем уж паpаноик может шифpовать на одном компе (без выхода в
YM> инет), а пеpесылать дpугим. Клиентская пpогpамма будет пpекpасно
YM> pаботать с флешек и пpочих подобных носителей, без необходимости
YM> инсталляции.
Можно тупой вопpос абсолютно неспециалиста в эхотаге? Чем pазpабатываемое
сpедство будет лучше GnuPG?
За диакpитическим знаком над "е" пpава на жизнь не пpизнаю. IMCO
С наилучшими пожеланиями, Александp, IP-поинт из Куpгана
Serguei E. Leontiev
Apr 1, 2015, 6:44:38 PM4/1/15
to
Привет Александр,
От 1 апреля 2015 г., 21:25:55 в fido7.ru.crypt ты писал:
YM>> будет пpекpасно pаботать с флешек и пpочих подобных
YM>> носителей, без необходимости инсталляции.
AV> Можно тупой вопpос абсолютно неспециалиста в эхотаге? Чем
AV> pазpабатываемое сpедство будет лучше GnuPG?
С точки конкретики (пользовательские свойства, целевая аудитория), нехай
автор сам отбрехивается.
Однако, позволю себе замечание общего характера.
Давно минули времена, когда органы экспортного контроля предъявляли к
Циммерману претензии в части нарушения экспортного контроля и
Ваасенарских соглашений. Hа настоящий момент, как я понимаю, эти
претензии как-то урегулированы. Поэтому подозреваю, что PGP и его
производные так или иначе удовлетворяют оным соглашениям в части
криптографических требований, соответственно, органы экспортного и
импортного контроля большинства стран участниц не имеют к ним претензий.
Продукты на них основанные даже в Apple Store свободно публикуются :)
Опять же "импортозамещение" :) Будь оно неладно :)
От 1 апреля 2015 г., 21:25:55 в fido7.ru.crypt ты писал:
YM>> Hу а совсем уж паpаноик может шифpовать на одном компе (без
YM>> выхода в инет), а пеpесылать дpугим. Клиентская пpогpамма
YM>> будет пpекpасно pаботать с флешек и пpочих подобных
YM>> носителей, без необходимости инсталляции.
AV> Можно тупой вопpос абсолютно неспециалиста в эхотаге? Чем
AV> pазpабатываемое сpедство будет лучше GnuPG?
С точки конкретики (пользовательские свойства, целевая аудитория), нехай
автор сам отбрехивается.
Однако, позволю себе замечание общего характера.
Давно минули времена, когда органы экспортного контроля предъявляли к
Циммерману претензии в части нарушения экспортного контроля и
Ваасенарских соглашений. Hа настоящий момент, как я понимаю, эти
претензии как-то урегулированы. Поэтому подозреваю, что PGP и его
производные так или иначе удовлетворяют оным соглашениям в части
криптографических требований, соответственно, органы экспортного и
импортного контроля большинства стран участниц не имеют к ним претензий.
Продукты на них основанные даже в Apple Store свободно публикуются :)
Опять же "импортозамещение" :) Будь оно неладно :)
Serguei E. Leontiev
Apr 2, 2015, 2:25:24 AM4/2/15
to
>> Если думаешь защищаться не от пионеров, а от профессионалов, которые
>> ежегодно анализируют почти все версии почти всех ОС, твой шифратор
>> должен быть устойчив, как минимум, к выходу одного непрерывного блока
>> памяти в канал связи. Его тебе устроят как два пальца обо асфальт.
> Вот опасаясь этого и собираюсь затирать нулями все временные данные,
> использовавшиеся при шифровании собственно сообщения, до того, как начинать
> сетевую сессию.
Тоже хорошая мера, конечно в сочетании с прочими, более важными.
> Вот опасаясь этого и собираюсь затирать нулями все временные данные,
> использовавшиеся при шифровании собственно сообщения, до того, как начинать
> сетевую сессию.
> А утечка разового сессионного ключа - вообще ничего не даст в плане расшифровки
> сообщения, максимум - позволит увидеть, что некий пользователь 4567457485345
> шлет неизвестное сообщение пользователю 12465623677.
Иными словами, либо шифруй "хорошо", либо не шифруй вовсе (вариант, в этом
месте большими буквами написать - использую DES или RSA1024 только для
защиты от аппаратных ошибок), и тогда пользователь сам предпримет
необходимые меры в этом месте, если посчитает, что и оно может ему
повредить.
> Hу а совсем уж параноик может шифровать на одном компе (без выхода в инет), а
> пересылать другим. Клиентская программа будет прекрасно работать с флешек и
> прочих подобных носителей, без необходимости инсталляции.
из "инет" файлов и, скорее всего, тоже самое приложение сможет подготовить
ответный файл :)
Yuri Myakotin
Apr 2, 2015, 3:05:02 AM4/2/15
to
Hello Serguei!
Thursday April 02 2015 09:25, Serguei E. Leontiev wrote to Yuri Myakotin:
>> использовавшиеся при шифровании собственно сообщения, до того, как
>> начинать сетевую сессию.
SL> Тоже хорошая мера, конечно в сочетании с прочими, более важными.
>> А утечка разового сессионного ключа - вообще ничего не даст в плане
>> расшифровки сообщения, максимум - позволит увидеть, что некий
>> пользователь 4567457485345 шлет неизвестное сообщение пользователю
>> 12465623677.
SL> Hа мой непросвещённый взгляд, если шифрование не нужно, то оно вредно.
SL> Иными словами, либо шифруй "хорошо",
Оно и будет "хорошо", просто без обратной совместимости со 100500 старыми
вариантами. Естественно, без такой степени параноидальности, как при шифровании
собственно сообщений.
Эдакий собственный вариант TLS, threefish-256 для шифрации трафика и curve25519
для получения сеансового shared key из рандомных байтиков. Hу и Ed25519 для
авторизации сервера/клиента.
Hо смысл в том, что даже при утечке из-за дыры не в софте, а в ОС - ничего
страшного не произойдет.
>> Hу а совсем уж параноик может шифровать на одном компе (без выхода в
>> инет), а пересылать другим. Клиентская программа будет прекрасно
>> работать с флешек и прочих подобных носителей, без необходимости
>> инсталляции.
SL> Гнилая отмазка :) Ключи расшифрования используются при обработке
SL> полученных из "инет" файлов
Только тогда, когда пользователь жмет "прочитать сообщение". Хранится же оно в
базе клиента как пришло, т.е. зашифрованным.
Thursday April 02 2015 09:25, Serguei E. Leontiev wrote to Yuri Myakotin:
>> использовавшиеся при шифровании собственно сообщения, до того, как
>> начинать сетевую сессию.
>> А утечка разового сессионного ключа - вообще ничего не даст в плане
>> расшифровки сообщения, максимум - позволит увидеть, что некий
>> пользователь 4567457485345 шлет неизвестное сообщение пользователю
>> 12465623677.
SL> Иными словами, либо шифруй "хорошо",
Оно и будет "хорошо", просто без обратной совместимости со 100500 старыми
вариантами. Естественно, без такой степени параноидальности, как при шифровании
собственно сообщений.
Эдакий собственный вариант TLS, threefish-256 для шифрации трафика и curve25519
для получения сеансового shared key из рандомных байтиков. Hу и Ed25519 для
авторизации сервера/клиента.
Hо смысл в том, что даже при утечке из-за дыры не в софте, а в ОС - ничего
страшного не произойдет.
>> Hу а совсем уж параноик может шифровать на одном компе (без выхода в
>> инет), а пересылать другим. Клиентская программа будет прекрасно
>> работать с флешек и прочих подобных носителей, без необходимости
>> инсталляции.
SL> полученных из "инет" файлов
Только тогда, когда пользователь жмет "прочитать сообщение". Хранится же оно в
базе клиента как пришло, т.е. зашифрованным.
Alexey Vissarionov
Apr 2, 2015, 3:25:02 AM4/2/15
to
Доброго времени суток, Aleksandr!
01 Apr 2015 21:25:54, ты -> Yuri Myakotin:
YM>> Hу а совсем уж паpаноик может шифpовать на одном компе (без выхода
YM>> в инет), а пеpесылать дpугим. Клиентская пpогpамма будет пpекpасно
AV> pазpабатываемое сpедство будет лучше GnuPG?
Принципиально - ничем.
Более того: насколько я понял, тот же функционал можно реализовать на связке
binkd+gpg - просто Юра захотел написать именно свою приблуду с преферансом и
куртизанками :-)
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Последним смеется тот, кто стреляет первым
01 Apr 2015 21:25:54, ты -> Yuri Myakotin:
YM>> Hу а совсем уж паpаноик может шифpовать на одном компе (без выхода
YM>> pаботать с флешек и пpочих подобных носителей, без необходимости
YM>> инсталляции.
AV> Можно тупой вопpос абсолютно неспециалиста в эхотаге? Чем
YM>> инсталляции.
AV> pазpабатываемое сpедство будет лучше GnuPG?
Принципиально - ничем.
Более того: насколько я понял, тот же функционал можно реализовать на связке
binkd+gpg - просто Юра захотел написать именно свою приблуду с преферансом и
куртизанками :-)
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Последним смеется тот, кто стреляет первым
Serguei E. Leontiev
Apr 2, 2015, 4:12:58 AM4/2/15
to
Алексей, привет,
Alexey Vissarionov <Alexey.Vi...@f545.n5020.z2.fidonet.org> wrote:
>> Можно тупой вопpос абсолютно неспециалиста в эхотаге? Чем
пионеров, конечно уже у комсомольцев, наверняка есть заготовленные папочки
на популярные версии gpg. Да, впрочем, и продвинутые пионеры просто скачают
нужную версию, напрягут остатки своего мозга, и вуаля - наверняка, найдут
применимую в конкретном контексте дырочку.
Alexey Vissarionov <Alexey.Vi...@f545.n5020.z2.fidonet.org> wrote:
>> Можно тупой вопpос абсолютно неспециалиста в эхотаге? Чем
>> pазpабатываемое сpедство будет лучше GnuPG?
> Более того: насколько я понял, тот же функционал можно реализовать на связке
> binkd+gpg - просто Юра захотел написать именно свою приблуду с преферансом и
Точности ради, есть одно соображение. Я думаю, что у продвинутых, нет не
> binkd+gpg - просто Юра захотел написать именно свою приблуду с преферансом и
пионеров, конечно уже у комсомольцев, наверняка есть заготовленные папочки
на популярные версии gpg. Да, впрочем, и продвинутые пионеры просто скачают
нужную версию, напрягут остатки своего мозга, и вуаля - наверняка, найдут
применимую в конкретном контексте дырочку.
Serguei E. Leontiev
Apr 2, 2015, 4:27:29 AM4/2/15
to
> Эдакий собственный вариант TLS, threefish-256 для шифрации трафика и curve25519
> для получения сеансового shared key из рандомных байтиков. Hу и Ed25519 для
> авторизации сервера/клиента.
Ещё раз напомню, новомодными и/или сделанными на коленке штучками
> для получения сеансового shared key из рандомных байтиков. Hу и Ed25519 для
> авторизации сервера/клиента.
профессионала ты не удивишь, а дашь более широкий вектор для атаки, а сам
скорее запутаешься и только усугубишь положение своих пользователей.
IMHO, более разумно взять надёжные, проверенные протоколы и алгоритмы, но
реализовать не как попало, как это принято в "свободном" программном
обеспечении, а с должной степенью параноидальности и надёжности. Впрочем,
каждый сам выбирает тот путь, по которому его взломают :)
Alexey Vissarionov
Apr 2, 2015, 10:05:02 AM4/2/15
to
Доброго времени суток, Serguei!
02 Apr 2015 01:44:36, ты -> Aleksandr Volosnikov:
SL> Однако, позволю себе замечание общего характера.
SL> Давно минули времена, когда органы экспортного контроля предъявляли
SL> к Циммерману претензии в части нарушения экспортного контроля и
SL> Ваасенарских соглашений.
Это относилось прежде всего к тому, что там был реализован Lucifer (DES).
SL> Hа настоящий момент, как я понимаю, эти претензии как-то
SL> урегулированы.
На них просто забили. И немалую роль в этом сыграла публикация алгоритмов
Blowfish и ГОСТ 28147-89, которые и по сей день сохраняют актуальность.
Еще дедушка Тахир (который эль-Гамаль) знатно отжег, когда отказался свой
алгоритм патентовать, а вместо этого опубликовал его.
SL> Поэтому подозреваю, что PGP и его производные так или иначе
SL> удовлетворяют оным соглашениям в части криптографических
SL> требований, соответственно, органы экспортного и импортного
SL> контроля большинства стран участниц не имеют к ним претензий.
Как известно, лучший способ прекратить безобразие - возглавить оное. Именно
поэтому, насколько я понимаю, сейчас и продвигают алгоритмы на ЭК со смешной
длиной ключа (максимум 521 бит, да еще и задать кривую с нужными свойствами
всяко легче, чем исследовать свойства существующей кривой). А уж при наличии
такой дыры в алгоритме с открытым ключом, применяемом всеми, кому лень думать,
насчет хеш-функций и симметричного шифрования можно вообще не заморачиваться.
SL> Продукты на них основанные даже в Apple Store свободно публикуются :)
Ага. А в SSH даже Blowfish урезан - только CBC и только 128 бит (сегодня
обнаружил, пропатчил и собрал пакет для ориджина). Лучшее, что там есть из
коробки - Rijndael 256 бит с CTR.
SL> Опять же "импортозамещение" :) Будь оно неладно :)
А насчет импортозамещения непонятно, зачем ГОСТ 34.10-94 испохабили...
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Культурный слой формируется из мусора и дерьма, но называется именно так
02 Apr 2015 01:44:36, ты -> Aleksandr Volosnikov:
SL> Однако, позволю себе замечание общего характера.
SL> Давно минули времена, когда органы экспортного контроля предъявляли
SL> к Циммерману претензии в части нарушения экспортного контроля и
SL> Ваасенарских соглашений.
Это относилось прежде всего к тому, что там был реализован Lucifer (DES).
SL> Hа настоящий момент, как я понимаю, эти претензии как-то
SL> урегулированы.
На них просто забили. И немалую роль в этом сыграла публикация алгоритмов
Blowfish и ГОСТ 28147-89, которые и по сей день сохраняют актуальность.
Еще дедушка Тахир (который эль-Гамаль) знатно отжег, когда отказался свой
алгоритм патентовать, а вместо этого опубликовал его.
SL> Поэтому подозреваю, что PGP и его производные так или иначе
SL> удовлетворяют оным соглашениям в части криптографических
SL> требований, соответственно, органы экспортного и импортного
SL> контроля большинства стран участниц не имеют к ним претензий.
Как известно, лучший способ прекратить безобразие - возглавить оное. Именно
поэтому, насколько я понимаю, сейчас и продвигают алгоритмы на ЭК со смешной
длиной ключа (максимум 521 бит, да еще и задать кривую с нужными свойствами
всяко легче, чем исследовать свойства существующей кривой). А уж при наличии
такой дыры в алгоритме с открытым ключом, применяемом всеми, кому лень думать,
насчет хеш-функций и симметричного шифрования можно вообще не заморачиваться.
SL> Продукты на них основанные даже в Apple Store свободно публикуются :)
Ага. А в SSH даже Blowfish урезан - только CBC и только 128 бит (сегодня
обнаружил, пропатчил и собрал пакет для ориджина). Лучшее, что там есть из
коробки - Rijndael 256 бит с CTR.
SL> Опять же "импортозамещение" :) Будь оно неладно :)
А насчет импортозамещения непонятно, зачем ГОСТ 34.10-94 испохабили...
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Serguei E. Leontiev
Apr 2, 2015, 5:48:01 PM4/2/15
to
Привет Алексей,
От 2 апреля 2015 г., 17:00:00 в fido7.ru.crypt ты писал:
AV> испохабили...
Всё уж, максимальная длина ключа 1024 бита в арифметическом поле GF(p)
уже некоторое время небезопасна, ибо к нему применим метод решета,
соответственно, 1024 бита ГОСТ 34.10-94 имеет стойкость примерно
аналогичную 1500-2500 бит RSA (поправь меня, если память меня подводит).
Hадо было, либо увеличивать длину, либо уходить в поля, где метод решета
не работает.
Да и зачем воздух греть совсем, совсем неэффективными умножениями таких
длинных чисел.
От 2 апреля 2015 г., 17:00:00 в fido7.ru.crypt ты писал:
SL>> Опять же "импортозамещение" :) Будь оно неладно :)
AV> А насчет импортозамещения непонятно, зачем ГОСТ 34.10-94
AV> испохабили...
Всё уж, максимальная длина ключа 1024 бита в арифметическом поле GF(p)
уже некоторое время небезопасна, ибо к нему применим метод решета,
соответственно, 1024 бита ГОСТ 34.10-94 имеет стойкость примерно
аналогичную 1500-2500 бит RSA (поправь меня, если память меня подводит).
Hадо было, либо увеличивать длину, либо уходить в поля, где метод решета
не работает.
Да и зачем воздух греть совсем, совсем неэффективными умножениями таких
длинных чисел.
Alexey Vissarionov
Apr 3, 2015, 5:05:02 AM4/3/15
to
Доброго времени суток, Serguei!
03 Apr 2015 00:47:58, ты -> мне:
SL>>> Опять же "импортозамещение" :) Будь оно неладно :)
AV>> А насчет импортозамещения непонятно, зачем ГОСТ 34.10-94
AV>> испохабили...
SL> Всё уж, максимальная длина ключа 1024 бита в арифметическом поле
SL> GF(p) уже некоторое время небезопасна, ибо к нему применим метод
SL> решета,
Эратосфеновского?
SL> соответственно, 1024 бита ГОСТ 34.10-94 имеет стойкость примерно
SL> аналогичную 1500-2500 бит RSA (поправь меня, если память меня
SL> подводит).
Ну да - где-то так, плюс-минус пол-лаптя.
SL> Hадо было, либо увеличивать длину,
Именно так. Ибо линейное увеличение длины влечет экспоненциальное увеличение
стоимости ломательных криптопроцессоров и потребного для них электричества.
SL> либо уходить в поля, где метод решета не работает.
Ага. Вот только нахрена при этом размеры ключей уменьшать?
SL> Да и зачем воздух греть совсем, совсем неэффективными умножениями
SL> таких длинных чисел.
Дороговизна - единственное реальное ограничение возможностей ломания.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Лучше гипс и кроватка, чем плита и оградка
03 Apr 2015 00:47:58, ты -> мне:
SL>>> Опять же "импортозамещение" :) Будь оно неладно :)
AV>> А насчет импортозамещения непонятно, зачем ГОСТ 34.10-94
AV>> испохабили...
SL> GF(p) уже некоторое время небезопасна, ибо к нему применим метод
SL> решета,
Эратосфеновского?
SL> соответственно, 1024 бита ГОСТ 34.10-94 имеет стойкость примерно
SL> аналогичную 1500-2500 бит RSA (поправь меня, если память меня
SL> подводит).
Ну да - где-то так, плюс-минус пол-лаптя.
SL> Hадо было, либо увеличивать длину,
Именно так. Ибо линейное увеличение длины влечет экспоненциальное увеличение
стоимости ломательных криптопроцессоров и потребного для них электричества.
SL> либо уходить в поля, где метод решета не работает.
Ага. Вот только нахрена при этом размеры ключей уменьшать?
SL> Да и зачем воздух греть совсем, совсем неэффективными умножениями
SL> таких длинных чисел.
Дороговизна - единственное реальное ограничение возможностей ломания.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Serguei E. Leontiev
Apr 3, 2015, 8:55:12 PM4/3/15
to
Привет Алексей,
От 3 апреля 2015 г., 11:55:00 в fido7.ru.crypt ты писал:
SL>> применим метод решета,
AV> Эратосфеновского?
М-м, не путай молодежь :) Конечно решето оно и в Африке решето, да и
связи через алгоритм решета для факторизации с решетом Эратосфена
имеются, но это таки совсем отдельный алгоритм :)
SL>> соответственно, 1024 бита ГОСТ 34.10-94 имеет стойкость
SL>> примерно аналогичную 1500-2500 бит RSA (поправь меня, если
SL>> память меня подводит).
AV> Hу да - где-то так, плюс-минус пол-лаптя.
AV> экспоненциальное увеличение стоимости ломательных
AV> криптопроцессоров и потребного для них электричества.
Что-то не заметил, вот, уменьшения размера ключей: ГОСТ Р 34.10-94 -
закрытый ключ 256 бит, ГОСТ Р 34.10-2001 - закрытый ключ 256 бит, ГОСТ Р
34.10-2012 - закрытый ключ 256 бит или 512 бит.
А то что открытый ключ имеет другой размер 512 бит (256+1 в упакованном
виде) или 1024 (512+1 в упакованном виде), так это чисто технический
момент, определяемый свойствами эллиптических кривых. Особого ухудшения,
если мне не изменяет память, здесь нет, т.к. из предположения о
возможности дискретного логарифмирования эллиптической кривой следует
достаточно много чего.
Замечу, что собственно ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012 не
ограничивают величину p сверху (p > 2^255, это q ограничено 2^254 < q <
2^256), тут больше сообщество производителей СКЗИ не заметило смысла в
больших p.
SL>> Да и зачем воздух греть совсем, совсем неэффективными
SL>> умножениями таких длинных чисел.
AV> Дороговизна - единственное реальное ограничение возможностей
AV> ломания.
Имеется ввиду, что ГОСТ Р 34.10-94, RSA, DSA и др., которые определены
группах, которые являются одновременно кольцами, вынуждены "бесполезно"
увеличивать размер открытого ключа и, соответственно, приближать
Глобальное потепление и тепловую смерть Вселенной не давая ничего взамен. :)
От 3 апреля 2015 г., 11:55:00 в fido7.ru.crypt ты писал:
AV>>> А насчет импортозамещения непонятно, зачем ГОСТ 34.10-94
AV>>> испохабили...
SL>> Всё уж, максимальная длина ключа 1024 бита в арифметическом
SL>> поле GF(p) уже некоторое время небезопасна, ибо к нему
AV>>> испохабили...
SL>> Всё уж, максимальная длина ключа 1024 бита в арифметическом
SL>> применим метод решета,
AV> Эратосфеновского?
М-м, не путай молодежь :) Конечно решето оно и в Африке решето, да и
связи через алгоритм решета для факторизации с решетом Эратосфена
имеются, но это таки совсем отдельный алгоритм :)
SL>> соответственно, 1024 бита ГОСТ 34.10-94 имеет стойкость
SL>> память меня подводит).
AV> Hу да - где-то так, плюс-минус пол-лаптя.
SL>> Hадо было, либо увеличивать длину,
AV> Именно так. Ибо линейное увеличение длины влечет
AV> экспоненциальное увеличение стоимости ломательных
AV> криптопроцессоров и потребного для них электричества.
SL>> либо уходить в поля, где метод решета не работает.
AV> Ага. Вот только нахрена при этом размеры ключей уменьшать?
Что-то не заметил, вот, уменьшения размера ключей: ГОСТ Р 34.10-94 -
закрытый ключ 256 бит, ГОСТ Р 34.10-2001 - закрытый ключ 256 бит, ГОСТ Р
34.10-2012 - закрытый ключ 256 бит или 512 бит.
А то что открытый ключ имеет другой размер 512 бит (256+1 в упакованном
виде) или 1024 (512+1 в упакованном виде), так это чисто технический
момент, определяемый свойствами эллиптических кривых. Особого ухудшения,
если мне не изменяет память, здесь нет, т.к. из предположения о
возможности дискретного логарифмирования эллиптической кривой следует
достаточно много чего.
Замечу, что собственно ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012 не
ограничивают величину p сверху (p > 2^255, это q ограничено 2^254 < q <
2^256), тут больше сообщество производителей СКЗИ не заметило смысла в
больших p.
SL>> Да и зачем воздух греть совсем, совсем неэффективными
AV> Дороговизна - единственное реальное ограничение возможностей
AV> ломания.
Имеется ввиду, что ГОСТ Р 34.10-94, RSA, DSA и др., которые определены
группах, которые являются одновременно кольцами, вынуждены "бесполезно"
увеличивать размер открытого ключа и, соответственно, приближать
Глобальное потепление и тепловую смерть Вселенной не давая ничего взамен. :)
Alexey Vissarionov
Apr 4, 2015, 3:55:03 AM4/4/15
to
Доброго времени суток, Serguei!
04 Apr 2015 03:55:10, ты -> мне:
SL> Замечу, что собственно ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012 не
SL> ограничивают величину p сверху (p > 2^255, это q ограничено
SL> 2^254 < q < 2^256), тут больше сообщество производителей СКЗИ не
SL> заметило смысла в больших p.
Математики хреновы... за числами денег не увидели :-)
SL>>> Да и зачем воздух греть совсем, совсем неэффективными
SL>>> умножениями таких длинных чисел.
AV>> Дороговизна - единственное реальное ограничение возможностей
AV>> ломания.
SL> Имеется ввиду, что ГОСТ Р 34.10-94, RSA, DSA и др., которые
SL> определены группах, которые являются одновременно кольцами,
В какой группе проводить операции - пофигу, они просто будут более (точки
хитровывернутых кривых) или менее (кольца вычетов) требовательны к АЛУ (его
вычислительной мощности). Но когда дополнительно возрастают и требования к
разрядности регистров, ценник взлетает по экспоненте.
SL> вынуждены "бесполезно" увеличивать размер открытого ключа
Почему бесполезно-то? Менее эффективно - да, соглашусь, но не бесполезно.
SL> и, соответственно, приближать Глобальное потепление и тепловую
SL> смерть Вселенной не давая ничего взамен. :)
На ближайшие несколько миллиардов лет хватит, а там посмотрим :-)
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
04 Apr 2015 03:55:10, ты -> мне:
SL> Замечу, что собственно ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012 не
SL> ограничивают величину p сверху (p > 2^255, это q ограничено
SL> 2^254 < q < 2^256), тут больше сообщество производителей СКЗИ не
SL> заметило смысла в больших p.
Математики хреновы... за числами денег не увидели :-)
SL>>> Да и зачем воздух греть совсем, совсем неэффективными
SL>>> умножениями таких длинных чисел.
AV>> Дороговизна - единственное реальное ограничение возможностей
AV>> ломания.
SL> определены группах, которые являются одновременно кольцами,
В какой группе проводить операции - пофигу, они просто будут более (точки
хитровывернутых кривых) или менее (кольца вычетов) требовательны к АЛУ (его
вычислительной мощности). Но когда дополнительно возрастают и требования к
разрядности регистров, ценник взлетает по экспоненте.
SL> вынуждены "бесполезно" увеличивать размер открытого ключа
Почему бесполезно-то? Менее эффективно - да, соглашусь, но не бесполезно.
SL> и, соответственно, приближать Глобальное потепление и тепловую
SL> смерть Вселенной не давая ничего взамен. :)
На ближайшие несколько миллиардов лет хватит, а там посмотрим :-)
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Serguei E. Leontiev
Apr 4, 2015, 4:30:30 AM4/4/15
to
Привет Алексей,
От 4 апреля 2015 г., 10:14:04 в fido7.ru.crypt ты писал:
SL>> сообщество производителей СКЗИ не заметило смысла в больших
SL>> p.
AV> Математики хреновы... за числами денег не увидели :-)
...
AV> дополнительно возрастают и требования к разрядности регистров,
AV> ценник взлетает по экспоненте.
Это выгода китайцев, в крайнем случае американцев, а нам зачем? У нас
может быть только одна выгода - массовость применения ГОСТ Р 34.10, в
т.ч. и нетребовательность к ресурсам :)
От 4 апреля 2015 г., 10:14:04 в fido7.ru.crypt ты писал:
SL>> сообщество производителей СКЗИ не заметило смысла в больших
SL>> p.
AV> Математики хреновы... за числами денег не увидели :-)
...
AV> дополнительно возрастают и требования к разрядности регистров,
AV> ценник взлетает по экспоненте.
Это выгода китайцев, в крайнем случае американцев, а нам зачем? У нас
может быть только одна выгода - массовость применения ГОСТ Р 34.10, в
т.ч. и нетребовательность к ресурсам :)
Yuri Myakotin
Apr 14, 2015, 8:25:02 AM4/14/15
to
Hello Serguei!
Wednesday April 01 2015 11:01, Yuri Myakotin wrote to Serguei E. Leontiev:
YM> Ок. И тут тоже подумаю, как по-другому реализовать. Скажем, твик выше
YM> использовать для cbc, а второй шифр - в режиме ctr. Или вообще в
YM> качестве второго возьму изначально поточный шифр, типа того же Salsa20
YM> Бернштейна.
Итак, новый вариант: ThreeFish-1024 в режиме tweak-"cbc", после чего - XOR
результата потоковым шифром ChaCha20. В качестве MAC алгоритма используется
бернштейновский Poly1305. Все ключи и хеши после использования затираются
нулями.
public class Paranoid
{
private ulong[] ThreeFTweak;
//private
private SkeinFish.Threefish1024 ThreeF;
private ChaCha Ch20;
private Array8<uint> PolyKey;
static private void Int128ToBytes(ulong[] int128, byte[] bytes)
{
Buffer.BlockCopy(int128, 0, bytes, 0, 16);
}
static private void BytesToInt128(byte[] bytes, ulong[] int128)
ulong[] Key1 = new ulong[16];
if ((key.Length != 128) || (salt.Length != 128)) throw new
Blake.TransformBytes(salt, 0, 36);
byte[] tmp = (Blake.TransformFinal()).GetBytes();
Buffer.BlockCopy(tmp, 0, Key1, 0, 64);
Blake.Initialize();
HashLib.Crypto.SHA3.Keccak512 Keccak = new
HashLib.Crypto.SHA3.Keccak512();
Keccak.Initialize();
Keccak.TransformBytes(salt, 36, 36);
Keccak.TransformBytes(key, 36, 36);
tmp = (Keccak.TransformFinal()).GetBytes();
Buffer.BlockCopy(tmp, 0, Key1, 64, 64);
HashLib.Crypto.SHA3.Skein256();
Skein.Initialize();
Skein.TransformBytes(key, 72, 24);
Skein.TransformBytes(salt, 68, 24);
byte[] Key2 = (Skein.TransformFinal()).GetBytes();
Skein.Initialize();
Keccak.Initialize();
Keccak.TransformBytes(key, 96, 32);
Keccak.TransformBytes(salt, 84, 44);
tmp = (Keccak.TransformFinal()).GetBytes();
Keccak.Initialize();
byte[] ChaChaIV = new byte[8];
Buffer.BlockCopy(tmp, 0, ChaChaIV, 0, 8);
Ch20 = new ChaCha(Key2, ChaChaIV, 20);
for (int i = 0; i < 32; i++)
Key2[i] = 0;
Buffer.BlockCopy(tmp, 8, ChaChaIV, 0, 8);
Ch20.SetCounter(ChaChaIV);
for (int i = 0; i < 8; i++)
ChaChaIV[i] = 0;
Buffer.BlockCopy(tmp, 16, ThreeFTweak, 0, 16);
PolyKey = new Array8<uint>();
PolyKey.x0 = BitConverter.ToUInt32(tmp, 32);
PolyKey.x1 = BitConverter.ToUInt32(tmp, 36);
PolyKey.x2 = BitConverter.ToUInt32(tmp, 40);
PolyKey.x3 = BitConverter.ToUInt32(tmp, 44);
PolyKey.x4 = BitConverter.ToUInt32(tmp, 48);
PolyKey.x5 = BitConverter.ToUInt32(tmp, 52);
PolyKey.x6 = BitConverter.ToUInt32(tmp, 56);
PolyKey.x7 = BitConverter.ToUInt32(tmp, 60);
for (int i = 0; i < tmp.Length; i++)
tmp[i] = 0;
}
public byte[] Encrypt(byte[] In, byte[] Salt)
{
ulong[] Buf1 = new ulong[16];
ulong[] Buf2 = new ulong[16];
byte[] Buf3;
byte[] tmpBuf = new byte[128];
int Len = In.Length;
Console.WriteLine(Len);
int cnt = 127 - ((int)Len % 128);
byte[] Out = new byte[NewLen];
Buffer.BlockCopy(Salt, 0, Out, 0, 128);
RNGCryptoServiceProvider rnd = new RNGCryptoServiceProvider();
rnd.GetBytes(tmp);
Buffer.BlockCopy(tmp, 0, tmpBuf, 1, cnt);
if (PadSize!=128) Buffer.BlockCopy(In, 0, tmpBuf, PadSize, 128 -
PadSize);
ThreeF.SetTweak(ThreeFTweak);
Buffer.BlockCopy(tmpBuf, 0, Buf1, 0, 128);
ThreeF.Encrypt(Buf1, Buf2);
Buffer.BlockCopy(Buf2, 0, tmpBuf, 0, 128);
ThreeFTweak[0] = Buf2[0] ^ Buf2[2] ^ Buf2[4] ^ Buf2[6] ^ Buf2[8] ^
Buf2[10] ^ Buf2[12] ^ Buf2[14];
ThreeFTweak[1] = Buf2[1] ^ Buf2[3] ^ Buf2[5] ^ Buf2[7] ^ Buf2[9] ^
Buf2[11] ^ Buf2[13] ^ Buf2[15];
Buf3 = Ch20.NextBlock();
for (int i = 0; i < 64; i++)
tmpBuf[i] ^= Buf3[i];
Buf3 = Ch20.NextBlock();
for (int i = 0; i < 64; i++)
tmpBuf[i + 64] ^= Buf3[i];
Buffer.BlockCopy(tmpBuf, 0, Out, 128, 128);
for (int j = 0; j < (Len / 128); j++)
{
Buffer.BlockCopy(In, j * 128 + (128 - PadSize), tmpBuf, 0,
128);
ThreeF.SetTweak(ThreeFTweak);
Buffer.BlockCopy(tmpBuf, 0, Buf1, 0, 128);
ThreeF.Encrypt(Buf1, Buf2);
Buffer.BlockCopy(Buf2, 0, tmpBuf, 0, 128);
ThreeFTweak[0] = Buf2[0] ^ Buf2[2] ^ Buf2[4] ^ Buf2[6] ^
Buf2[8] ^ Buf2[10] ^ Buf2[12] ^ Buf2[14];
ThreeFTweak[1] = Buf2[1] ^ Buf2[3] ^ Buf2[5] ^ Buf2[7] ^
Buf2[9] ^ Buf2[11] ^ Buf2[13] ^ Buf2[15];
Buf3 = Ch20.NextBlock();
for (int i = 0; i < 64; i++)
tmpBuf[i] ^= Buf3[i];
Buf3 = Ch20.NextBlock();
for (int i = 0; i < 64; i++)
tmpBuf[i + 64] ^= Buf3[i];
Buffer.BlockCopy(tmpBuf, 0, Out, 256 + j * 128, 128);
}
Poly1305Donna.poly1305_auth(Out, NewLen - 16, Out, 128, NewLen -
128 - 16, ref PolyKey);
return Out;
}
public byte[] Decrypt(byte[] Data)
{
ulong[] Buf1 = new ulong[16];
ulong[] Buf2 = new ulong[16];
byte[] Buf3;
byte[] tmpBuf = new byte[128];
byte PadSize;
byte[] Mac = new byte[16];
bool isMacCorrect = true;
Poly1305Donna.poly1305_auth(Mac, 0, Data, 128, Data.Length - 128 -
16, ref PolyKey);
for (int i = 0; i < 16; i++)
if (Mac[i] != Data[Data.Length - 16 + i]) isMacCorrect = false;
if (!isMacCorrect) return null;
Buffer.BlockCopy(Data, 128, tmpBuf, 0, 128);
Buf3 = Ch20.NextBlock();
for (int i = 0; i < 64; i++)
tmpBuf[i] ^= Buf3[i];
Buf3 = Ch20.NextBlock();
for (int i = 0; i < 64; i++)
tmpBuf[i + 64] ^= Buf3[i];
ThreeF.SetTweak(ThreeFTweak);
Buffer.BlockCopy(tmpBuf, 0, Buf2, 0, 128);
ThreeF.Decrypt(Buf2, Buf1);
Buffer.BlockCopy(Buf1, 0, tmpBuf, 0, 128);
ThreeFTweak[0] = Buf2[0] ^ Buf2[2] ^ Buf2[4] ^ Buf2[6] ^ Buf2[8] ^
Buf2[10] ^ Buf2[12] ^ Buf2[14];
ThreeFTweak[1] = Buf2[1] ^ Buf2[3] ^ Buf2[5] ^ Buf2[7] ^ Buf2[9] ^
Buf2[11] ^ Buf2[13] ^ Buf2[15];
PadSize = tmpBuf[0];
int NewLen = Data.Length - 128 - 16 - PadSize;
byte[] Out = new byte[NewLen];
if (PadSize != 128)
Buffer.BlockCopy(tmpBuf, PadSize, Out, 0, 128 - PadSize);
for (int j = 0; j < (NewLen / 128); j++)
{
Buffer.BlockCopy(Data, 256 + j * 128, tmpBuf, 0, 128);
Buf3 = Ch20.NextBlock();
for (int i = 0; i < 64; i++)
tmpBuf[i] ^= Buf3[i];
Buf3 = Ch20.NextBlock();
for (int i = 0; i < 64; i++)
tmpBuf[i + 64] ^= Buf3[i];
ThreeF.SetTweak(ThreeFTweak);
Buffer.BlockCopy(tmpBuf, 0, Buf2, 0, 128);
ThreeF.Decrypt(Buf2, Buf1);
ThreeFTweak[0] = Buf2[0] ^ Buf2[2] ^ Buf2[4] ^ Buf2[6] ^
Buf2[8] ^ Buf2[10] ^ Buf2[12] ^ Buf2[14];
ThreeFTweak[1] = Buf2[1] ^ Buf2[3] ^ Buf2[5] ^ Buf2[7] ^
Buf2[9] ^ Buf2[11] ^ Buf2[13] ^ Buf2[15];
Buffer.BlockCopy(Buf1, 0, Out, j * 128 + 128 - PadSize, 128);
}
return Out;
}
public void Clear()
{
ulong[] tmp1 = new ulong[16];
ThreeFTweak[0] = 0;
ThreeFTweak[1] = 0;
Ch20.Clear();
ThreeF.SetKey(tmp1);
ThreeF.SetTweak(ThreeFTweak);
PolyKey.x0 = 0;
PolyKey.x1 = 0;
PolyKey.x2 = 0;
PolyKey.x3 = 0;
PolyKey.x4 = 0;
PolyKey.x5 = 0;
PolyKey.x6 = 0;
PolyKey.x7 = 0;
}
}
public static class ParanoidHelpers
{
public static byte[] MakeEncryptedMessage(byte[] key, Byte[] Data)
{
Paranoid P;
byte[] Salt = new byte[128];
ParanoidRNG.ParanoidalRNG(Salt, 0, 128);
byte[] ZippedData =
SevenZip.Compression.LZMA.SevenZipHelper.Compress(Data);
P = new Paranoid(key, Salt);
byte[] RetVal = P.Encrypt(ZippedData, Salt);
P.Clear();
return RetVal;
}
public static byte[] DecryptMessage(byte[] key, byte[] Data)
{
Paranoid P;
byte[] Salt = new byte[128];
Buffer.BlockCopy(Data, 0, Salt, 0, 128);
P = new Paranoid(key, Salt);
byte[] Decrypted = P.Decrypt(Data);
P.Clear();
if (Decrypted == null) return null;
try
{
byte[] Unzipped =
SevenZip.Compression.LZMA.SevenZipHelper.Decompress(Decrypted);
return Unzipped;
}
catch
{
return null;
Wednesday April 01 2015 11:01, Yuri Myakotin wrote to Serguei E. Leontiev:
YM> Ок. И тут тоже подумаю, как по-другому реализовать. Скажем, твик выше
YM> использовать для cbc, а второй шифр - в режиме ctr. Или вообще в
YM> качестве второго возьму изначально поточный шифр, типа того же Salsa20
YM> Бернштейна.
Итак, новый вариант: ThreeFish-1024 в режиме tweak-"cbc", после чего - XOR
результата потоковым шифром ChaCha20. В качестве MAC алгоритма используется
бернштейновский Poly1305. Все ключи и хеши после использования затираются
нулями.
public class Paranoid
{
private ulong[] ThreeFTweak;
//private
private SkeinFish.Threefish1024 ThreeF;
private ChaCha Ch20;
private Array8<uint> PolyKey;
static private void Int128ToBytes(ulong[] int128, byte[] bytes)
{
Buffer.BlockCopy(int128, 0, bytes, 0, 16);
}
{
Buffer.BlockCopy(bytes, 0, int128, 0, 16);
}
Buffer.BlockCopy(bytes, 0, int128, 0, 16);
}
public Paranoid(byte[] key, byte[] salt)
{
ThreeFTweak = new ulong[2];
{
ulong[] Key1 = new ulong[16];
ArgumentException("Invalid arguments length");
HashLib.Crypto.SHA3.Blake512 Blake = new
HashLib.Crypto.SHA3.Blake512();
Blake.Initialize();
Blake.TransformBytes(key, 0, 36);
HashLib.Crypto.SHA3.Blake512();
Blake.Initialize();
Blake.TransformBytes(salt, 0, 36);
byte[] tmp = (Blake.TransformFinal()).GetBytes();
Buffer.BlockCopy(tmp, 0, Key1, 0, 64);
Blake.Initialize();
HashLib.Crypto.SHA3.Keccak512 Keccak = new
HashLib.Crypto.SHA3.Keccak512();
Keccak.Initialize();
Keccak.TransformBytes(key, 36, 36);
tmp = (Keccak.TransformFinal()).GetBytes();
Buffer.BlockCopy(tmp, 0, Key1, 64, 64);
ThreeF = new SkeinFish.Threefish1024();
ThreeF.SetKey(Key1);
for (int i = 0; i > 16; i++)
Key1[i] = 0;
HashLib.Crypto.SHA3.Skein256 Skein = new
ThreeF.SetKey(Key1);
for (int i = 0; i > 16; i++)
Key1[i] = 0;
HashLib.Crypto.SHA3.Skein256();
Skein.Initialize();
Skein.TransformBytes(key, 72, 24);
Skein.TransformBytes(salt, 68, 24);
byte[] Key2 = (Skein.TransformFinal()).GetBytes();
Skein.Initialize();
Keccak.Initialize();
Keccak.TransformBytes(key, 96, 32);
Keccak.TransformBytes(salt, 84, 44);
tmp = (Keccak.TransformFinal()).GetBytes();
Keccak.Initialize();
byte[] ChaChaIV = new byte[8];
Buffer.BlockCopy(tmp, 0, ChaChaIV, 0, 8);
Ch20 = new ChaCha(Key2, ChaChaIV, 20);
for (int i = 0; i < 32; i++)
Key2[i] = 0;
Ch20.SetCounter(ChaChaIV);
for (int i = 0; i < 8; i++)
ChaChaIV[i] = 0;
Buffer.BlockCopy(tmp, 16, ThreeFTweak, 0, 16);
PolyKey = new Array8<uint>();
PolyKey.x0 = BitConverter.ToUInt32(tmp, 32);
PolyKey.x1 = BitConverter.ToUInt32(tmp, 36);
PolyKey.x2 = BitConverter.ToUInt32(tmp, 40);
PolyKey.x3 = BitConverter.ToUInt32(tmp, 44);
PolyKey.x4 = BitConverter.ToUInt32(tmp, 48);
PolyKey.x5 = BitConverter.ToUInt32(tmp, 52);
PolyKey.x6 = BitConverter.ToUInt32(tmp, 56);
PolyKey.x7 = BitConverter.ToUInt32(tmp, 60);
for (int i = 0; i < tmp.Length; i++)
tmp[i] = 0;
}
public byte[] Encrypt(byte[] In, byte[] Salt)
{
ulong[] Buf1 = new ulong[16];
ulong[] Buf2 = new ulong[16];
byte[] Buf3;
byte[] tmpBuf = new byte[128];
Console.WriteLine(Len);
int cnt = 127 - ((int)Len % 128);
byte PadSize = (byte)(cnt + 1);
tmpBuf[0] = PadSize;
byte[] tmp = new byte[cnt];
int NewLen = Len + PadSize + 128 + 16;
byte[] Out = new byte[NewLen];
Buffer.BlockCopy(Salt, 0, Out, 0, 128);
RNGCryptoServiceProvider rnd = new RNGCryptoServiceProvider();
rnd.GetBytes(tmp);
if (PadSize!=128) Buffer.BlockCopy(In, 0, tmpBuf, PadSize, 128 -
PadSize);
ThreeF.SetTweak(ThreeFTweak);
Buffer.BlockCopy(tmpBuf, 0, Buf1, 0, 128);
ThreeF.Encrypt(Buf1, Buf2);
Buffer.BlockCopy(Buf2, 0, tmpBuf, 0, 128);
ThreeFTweak[0] = Buf2[0] ^ Buf2[2] ^ Buf2[4] ^ Buf2[6] ^ Buf2[8] ^
Buf2[10] ^ Buf2[12] ^ Buf2[14];
ThreeFTweak[1] = Buf2[1] ^ Buf2[3] ^ Buf2[5] ^ Buf2[7] ^ Buf2[9] ^
Buf2[11] ^ Buf2[13] ^ Buf2[15];
Buf3 = Ch20.NextBlock();
for (int i = 0; i < 64; i++)
tmpBuf[i] ^= Buf3[i];
Buf3 = Ch20.NextBlock();
for (int i = 0; i < 64; i++)
tmpBuf[i + 64] ^= Buf3[i];
Buffer.BlockCopy(tmpBuf, 0, Out, 128, 128);
for (int j = 0; j < (Len / 128); j++)
{
Buffer.BlockCopy(In, j * 128 + (128 - PadSize), tmpBuf, 0,
128);
ThreeF.SetTweak(ThreeFTweak);
Buffer.BlockCopy(tmpBuf, 0, Buf1, 0, 128);
ThreeF.Encrypt(Buf1, Buf2);
Buffer.BlockCopy(Buf2, 0, tmpBuf, 0, 128);
ThreeFTweak[0] = Buf2[0] ^ Buf2[2] ^ Buf2[4] ^ Buf2[6] ^
Buf2[8] ^ Buf2[10] ^ Buf2[12] ^ Buf2[14];
ThreeFTweak[1] = Buf2[1] ^ Buf2[3] ^ Buf2[5] ^ Buf2[7] ^
Buf2[9] ^ Buf2[11] ^ Buf2[13] ^ Buf2[15];
Buf3 = Ch20.NextBlock();
for (int i = 0; i < 64; i++)
tmpBuf[i] ^= Buf3[i];
Buf3 = Ch20.NextBlock();
for (int i = 0; i < 64; i++)
tmpBuf[i + 64] ^= Buf3[i];
Buffer.BlockCopy(tmpBuf, 0, Out, 256 + j * 128, 128);
}
Poly1305Donna.poly1305_auth(Out, NewLen - 16, Out, 128, NewLen -
128 - 16, ref PolyKey);
return Out;
}
public byte[] Decrypt(byte[] Data)
{
ulong[] Buf1 = new ulong[16];
ulong[] Buf2 = new ulong[16];
byte[] Buf3;
byte[] tmpBuf = new byte[128];
byte[] Mac = new byte[16];
bool isMacCorrect = true;
Poly1305Donna.poly1305_auth(Mac, 0, Data, 128, Data.Length - 128 -
16, ref PolyKey);
for (int i = 0; i < 16; i++)
if (!isMacCorrect) return null;
Buffer.BlockCopy(Data, 128, tmpBuf, 0, 128);
Buf3 = Ch20.NextBlock();
for (int i = 0; i < 64; i++)
tmpBuf[i] ^= Buf3[i];
Buf3 = Ch20.NextBlock();
for (int i = 0; i < 64; i++)
tmpBuf[i + 64] ^= Buf3[i];
ThreeF.SetTweak(ThreeFTweak);
Buffer.BlockCopy(tmpBuf, 0, Buf2, 0, 128);
ThreeF.Decrypt(Buf2, Buf1);
Buffer.BlockCopy(Buf1, 0, tmpBuf, 0, 128);
ThreeFTweak[0] = Buf2[0] ^ Buf2[2] ^ Buf2[4] ^ Buf2[6] ^ Buf2[8] ^
Buf2[10] ^ Buf2[12] ^ Buf2[14];
ThreeFTweak[1] = Buf2[1] ^ Buf2[3] ^ Buf2[5] ^ Buf2[7] ^ Buf2[9] ^
Buf2[11] ^ Buf2[13] ^ Buf2[15];
PadSize = tmpBuf[0];
int NewLen = Data.Length - 128 - 16 - PadSize;
byte[] Out = new byte[NewLen];
if (PadSize != 128)
Buffer.BlockCopy(tmpBuf, PadSize, Out, 0, 128 - PadSize);
for (int j = 0; j < (NewLen / 128); j++)
{
Buffer.BlockCopy(Data, 256 + j * 128, tmpBuf, 0, 128);
Buf3 = Ch20.NextBlock();
for (int i = 0; i < 64; i++)
tmpBuf[i] ^= Buf3[i];
Buf3 = Ch20.NextBlock();
for (int i = 0; i < 64; i++)
tmpBuf[i + 64] ^= Buf3[i];
ThreeF.SetTweak(ThreeFTweak);
Buffer.BlockCopy(tmpBuf, 0, Buf2, 0, 128);
ThreeF.Decrypt(Buf2, Buf1);
ThreeFTweak[0] = Buf2[0] ^ Buf2[2] ^ Buf2[4] ^ Buf2[6] ^
Buf2[8] ^ Buf2[10] ^ Buf2[12] ^ Buf2[14];
ThreeFTweak[1] = Buf2[1] ^ Buf2[3] ^ Buf2[5] ^ Buf2[7] ^
Buf2[9] ^ Buf2[11] ^ Buf2[13] ^ Buf2[15];
Buffer.BlockCopy(Buf1, 0, Out, j * 128 + 128 - PadSize, 128);
}
return Out;
}
public void Clear()
{
ulong[] tmp1 = new ulong[16];
ThreeFTweak[0] = 0;
ThreeFTweak[1] = 0;
Ch20.Clear();
ThreeF.SetKey(tmp1);
ThreeF.SetTweak(ThreeFTweak);
PolyKey.x0 = 0;
PolyKey.x1 = 0;
PolyKey.x2 = 0;
PolyKey.x3 = 0;
PolyKey.x4 = 0;
PolyKey.x5 = 0;
PolyKey.x6 = 0;
PolyKey.x7 = 0;
}
}
public static class ParanoidHelpers
{
public static byte[] MakeEncryptedMessage(byte[] key, Byte[] Data)
{
Paranoid P;
byte[] Salt = new byte[128];
ParanoidRNG.ParanoidalRNG(Salt, 0, 128);
byte[] ZippedData =
SevenZip.Compression.LZMA.SevenZipHelper.Compress(Data);
P = new Paranoid(key, Salt);
byte[] RetVal = P.Encrypt(ZippedData, Salt);
P.Clear();
return RetVal;
}
public static byte[] DecryptMessage(byte[] key, byte[] Data)
{
Paranoid P;
byte[] Salt = new byte[128];
Buffer.BlockCopy(Data, 0, Salt, 0, 128);
P = new Paranoid(key, Salt);
byte[] Decrypted = P.Decrypt(Data);
P.Clear();
if (Decrypted == null) return null;
try
{
byte[] Unzipped =
SevenZip.Compression.LZMA.SevenZipHelper.Decompress(Decrypted);
return Unzipped;
}
catch
{
return null;
0 new messages