Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
������� ������ �1: ��������� ��������� �����
3 views
Skip to first unread message
Yuri Myakotin
Feb 23, 2015, 3:35:10 PM2/23/15
to
Hello All!
Hасколько надежен (в плане отсутствия бэкдоров, позволяющих предсказать
последовательность бит) штатный CryptGenRandom под виндой? Стоит ли для пущей
паранойи (скажем, при генерации секретного ключа) XORить его результат, к
примеру, с хешом от сочетания "факторов энтропии" (текущее время, аптайм
системы, свободное место на дисках etc)?
See all in Hell,
Yuri
Hасколько надежен (в плане отсутствия бэкдоров, позволяющих предсказать
последовательность бит) штатный CryptGenRandom под виндой? Стоит ли для пущей
паранойи (скажем, при генерации секретного ключа) XORить его результат, к
примеру, с хешом от сочетания "факторов энтропии" (текущее время, аптайм
системы, свободное место на дисках etc)?
See all in Hell,
Yuri
Alexey Vissarionov
Feb 24, 2015, 8:45:03 AM2/24/15
to
Доброго времени суток, Yuri!
22 Feb 2015 23:07:58, ты -> All:
YM> Hасколько надежен (в плане отсутствия бэкдоров, позволяющих
YM> предсказать последовательность бит) штатный CryptGenRandom под
YM> виндой?
Встречный вопрос #0: ты егойные исходники видел?
Если нет - ответ кагбэ очевиден.
YM> Стоит ли для пущей паранойи (скажем, при генерации секретного ключа)
YM> XORить его результат, к примеру, с хешом от сочетания "факторов
YM> энтропии" (текущее время, аптайм системы, свободное место на дисках
YM> etc)?
Да. Посмотри, как реализовано add_device_randomness() в ядре Linux.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Бывают такие горбатые, что сами любую могилу исправят
22 Feb 2015 23:07:58, ты -> All:
YM> Hасколько надежен (в плане отсутствия бэкдоров, позволяющих
YM> предсказать последовательность бит) штатный CryptGenRandom под
YM> виндой?
Встречный вопрос #0: ты егойные исходники видел?
Если нет - ответ кагбэ очевиден.
YM> Стоит ли для пущей паранойи (скажем, при генерации секретного ключа)
YM> XORить его результат, к примеру, с хешом от сочетания "факторов
YM> энтропии" (текущее время, аптайм системы, свободное место на дисках
YM> etc)?
Да. Посмотри, как реализовано add_device_randomness() в ядре Linux.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Бывают такие горбатые, что сами любую могилу исправят
Yuri Myakotin
Feb 24, 2015, 10:55:03 AM2/24/15
to
Hello Alexey!
Tuesday February 24 2015 16:32, Alexey Vissarionov wrote to Yuri Myakotin:
YM>> Стоит ли для пущей паранойи (скажем, при генерации секретного
YM>> ключа) XORить его результат, к примеру, с хешом от сочетания
YM>> "факторов энтропии" (текущее время, аптайм системы, свободное
YM>> место на дисках etc)?
AV> Да. Посмотри, как реализовано add_device_randomness() в ядре Linux.
Пока соорудил вот что:
public static class ParanoidRNG
{
public static void ParanoidalRNG(byte[] Buff, int BuffOffset, int
BytesLen)
{
SkeinFish.Skein SK;
switch(BytesLen)
{
case 32:
SK = new SkeinFish.Skein256();
break;
case 64:
SK = new SkeinFish.Skein512();
break;
case 128: SK = new SkeinFish.Skein1024();
break;
default:
throw new Exception("Invalid size");
}
RNGCryptoServiceProvider CRNG = new RNGCryptoServiceProvider();
byte[] Rnd1 = new byte[BytesLen+1];
CRNG.GetBytes(Rnd1);
MemoryStream MS = new MemoryStream();
BinaryWriter BW = new BinaryWriter(MS);
BW.Write(Environment.TickCount);
BW.Write(DateTime.Now.Ticks);
DriveInfo[] allDrives = DriveInfo.GetDrives();
foreach (DriveInfo DI in allDrives)
{
if (DI.IsReady)
BW.Write(DI.TotalFreeSpace);
}
byte[] EntropyBytes = MS.ToArray();
BW.Close();
MS.Close();
HashLib.HashResult HR;
if((Rnd1[BytesLen])%2==0)
{
HashLib.Crypto.SHA3.Blake512 Blake = new
HashLib.Crypto.SHA3.Blake512();
Blake.Initialize();
HR=Blake.ComputeBytes(EntropyBytes);
}
else
{
HashLib.Crypto.SHA3.Keccak512 Keccak = new
HashLib.Crypto.SHA3.Keccak512();
Keccak.Initialize();
HR = Keccak.ComputeBytes(EntropyBytes);
}
byte[] Rnd2 = SK.ComputeHash(HR.GetBytes());
for (int i=0;i<BytesLen;i++)
Rnd1[i] ^= Rnd2[i];
SK.Clear();
SK.Dispose();
Buffer.BlockCopy(Rnd1, 0, Buff, BuffOffset, BytesLen);
}
}
Берется нужное количество байт+1 штатным генератором, потом из времени, аптайма
и количеств свободных мест на дисках берется 512бит хеш (разными хеш функциями
в зависимости от содержимого лишнего байтика), потом от результата еще раз
берется хеш нужной размерности и XORится с результатом штатного генератора.
Tuesday February 24 2015 16:32, Alexey Vissarionov wrote to Yuri Myakotin:
YM>> Стоит ли для пущей паранойи (скажем, при генерации секретного
YM>> "факторов энтропии" (текущее время, аптайм системы, свободное
YM>> место на дисках etc)?
AV> Да. Посмотри, как реализовано add_device_randomness() в ядре Linux.
Пока соорудил вот что:
public static class ParanoidRNG
{
public static void ParanoidalRNG(byte[] Buff, int BuffOffset, int
BytesLen)
{
SkeinFish.Skein SK;
switch(BytesLen)
{
case 32:
SK = new SkeinFish.Skein256();
break;
case 64:
SK = new SkeinFish.Skein512();
break;
case 128: SK = new SkeinFish.Skein1024();
break;
default:
throw new Exception("Invalid size");
}
RNGCryptoServiceProvider CRNG = new RNGCryptoServiceProvider();
byte[] Rnd1 = new byte[BytesLen+1];
CRNG.GetBytes(Rnd1);
MemoryStream MS = new MemoryStream();
BinaryWriter BW = new BinaryWriter(MS);
BW.Write(Environment.TickCount);
BW.Write(DateTime.Now.Ticks);
DriveInfo[] allDrives = DriveInfo.GetDrives();
foreach (DriveInfo DI in allDrives)
{
if (DI.IsReady)
BW.Write(DI.TotalFreeSpace);
}
byte[] EntropyBytes = MS.ToArray();
BW.Close();
MS.Close();
HashLib.HashResult HR;
if((Rnd1[BytesLen])%2==0)
{
HashLib.Crypto.SHA3.Blake512 Blake = new
HashLib.Crypto.SHA3.Blake512();
Blake.Initialize();
HR=Blake.ComputeBytes(EntropyBytes);
}
else
{
HashLib.Crypto.SHA3.Keccak512 Keccak = new
HashLib.Crypto.SHA3.Keccak512();
Keccak.Initialize();
HR = Keccak.ComputeBytes(EntropyBytes);
}
byte[] Rnd2 = SK.ComputeHash(HR.GetBytes());
for (int i=0;i<BytesLen;i++)
Rnd1[i] ^= Rnd2[i];
SK.Clear();
SK.Dispose();
Buffer.BlockCopy(Rnd1, 0, Buff, BuffOffset, BytesLen);
}
}
Берется нужное количество байт+1 штатным генератором, потом из времени, аптайма
и количеств свободных мест на дисках берется 512бит хеш (разными хеш функциями
в зависимости от содержимого лишнего байтика), потом от результата еще раз
берется хеш нужной размерности и XORится с результатом штатного генератора.
Alexey Vissarionov
Feb 25, 2015, 1:55:03 AM2/25/15
to
Доброго времени суток, Yuri!
24 Feb 2015 18:35:18, ты -> мне:
YM>>> Стоит ли для пущей паранойи (скажем, при генерации секретного
YM>>> ключа) XORить его результат, к примеру, с хешом от сочетания
YM>>> "факторов энтропии" (текущее время, аптайм системы, свободное
YM>>> место на дисках etc)?
AV>> Да. Посмотри, как реализовано add_device_randomness() в ядре Linux.
YM> Пока соорудил вот что:
YM> public static class ParanoidRNG
YM> Берется нужное количество байт+1 штатным генератором, потом из
YM> времени, аптайма и количеств свободных мест на дисках берется
YM> 512бит хеш (разными хеш функциями в зависимости от содержимого
YM> лишнего байтика), потом от результата еще раз берется хеш нужной
YM> размерности и XORится с результатом штатного генератора.
А зачем? Собираешь энтропию из системы, добавляешь из штатного генератора,
отбеливаешь хеш-функцией - и вот тебе IV для генерации гаммы. Blowfish-CFB
подходит для этого чудеснейшим образом.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Гладко было на бумаге, а потом полезли баги
24 Feb 2015 18:35:18, ты -> мне:
YM>>> Стоит ли для пущей паранойи (скажем, при генерации секретного
YM>>> ключа) XORить его результат, к примеру, с хешом от сочетания
YM>>> "факторов энтропии" (текущее время, аптайм системы, свободное
YM>>> место на дисках etc)?
AV>> Да. Посмотри, как реализовано add_device_randomness() в ядре Linux.
YM> public static class ParanoidRNG
YM> Берется нужное количество байт+1 штатным генератором, потом из
YM> времени, аптайма и количеств свободных мест на дисках берется
YM> 512бит хеш (разными хеш функциями в зависимости от содержимого
YM> лишнего байтика), потом от результата еще раз берется хеш нужной
YM> размерности и XORится с результатом штатного генератора.
А зачем? Собираешь энтропию из системы, добавляешь из штатного генератора,
отбеливаешь хеш-функцией - и вот тебе IV для генерации гаммы. Blowfish-CFB
подходит для этого чудеснейшим образом.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Yuri Myakotin
Feb 25, 2015, 3:25:02 AM2/25/15
to
Hello Alexey!
Wednesday February 25 2015 09:46, Alexey Vissarionov wrote to Yuri Myakotin:
YM>> Берется нужное количество байт+1 штатным генератором, потом из
YM>> времени, аптайма и количеств свободных мест на дисках берется
YM>> 512бит хеш (разными хеш функциями в зависимости от содержимого
YM>> лишнего байтика), потом от результата еще раз берется хеш нужной
YM>> размерности и XORится с результатом штатного генератора.
AV> А зачем? Собираешь энтропию из системы, добавляешь из штатного
AV> генератора, отбеливаешь хеш-функцией - и вот тебе IV для генерации
AV> гаммы. Blowfish-CFB подходит для этого чудеснейшим образом.
Была и такая мысль, но поленился и сделал как написано выше. МБ еще разные
варианты хеш функций добавлю со временем, просто те 3, которые использовал, у
меня в основном проекте уже используются.
Wednesday February 25 2015 09:46, Alexey Vissarionov wrote to Yuri Myakotin:
YM>> Берется нужное количество байт+1 штатным генератором, потом из
YM>> времени, аптайма и количеств свободных мест на дисках берется
YM>> 512бит хеш (разными хеш функциями в зависимости от содержимого
YM>> лишнего байтика), потом от результата еще раз берется хеш нужной
YM>> размерности и XORится с результатом штатного генератора.
AV> генератора, отбеливаешь хеш-функцией - и вот тебе IV для генерации
AV> гаммы. Blowfish-CFB подходит для этого чудеснейшим образом.
Была и такая мысль, но поленился и сделал как написано выше. МБ еще разные
варианты хеш функций добавлю со временем, просто те 3, которые использовал, у
меня в основном проекте уже используются.
Alexey Vissarionov
Feb 25, 2015, 4:25:03 AM2/25/15
to
Доброго времени суток, Yuri!
25 Feb 2015 11:06:40, ты -> мне:
YM>>> Берется нужное количество байт+1 штатным генератором, потом из
YM>>> времени, аптайма и количеств свободных мест на дисках берется
YM>>> 512бит хеш (разными хеш функциями в зависимости от содержимого
YM>>> лишнего байтика), потом от результата еще раз берется хеш нужной
YM>>> размерности и XORится с результатом штатного генератора.
AV>> А зачем? Собираешь энтропию из системы, добавляешь из штатного
AV>> генератора, отбеливаешь хеш-функцией - и вот тебе IV для генерации
AV>> гаммы. Blowfish-CFB подходит для этого чудеснейшим образом.
YM> Была и такая мысль, но поленился и сделал как написано выше.
Если не поздно - лучше переделай.
YM> МБ еще разные варианты хеш функций добавлю со временем, просто те 3,
YM> которые использовал, у меня в основном проекте уже используются.
А смысл? У тебя там есть клубок, которого вполне достаточно.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Лучше отписываться, чем отпеваться
25 Feb 2015 11:06:40, ты -> мне:
YM>>> Берется нужное количество байт+1 штатным генератором, потом из
YM>>> времени, аптайма и количеств свободных мест на дисках берется
YM>>> 512бит хеш (разными хеш функциями в зависимости от содержимого
YM>>> лишнего байтика), потом от результата еще раз берется хеш нужной
YM>>> размерности и XORится с результатом штатного генератора.
AV>> А зачем? Собираешь энтропию из системы, добавляешь из штатного
AV>> генератора, отбеливаешь хеш-функцией - и вот тебе IV для генерации
AV>> гаммы. Blowfish-CFB подходит для этого чудеснейшим образом.
Если не поздно - лучше переделай.
YM> МБ еще разные варианты хеш функций добавлю со временем, просто те 3,
YM> которые использовал, у меня в основном проекте уже используются.
А смысл? У тебя там есть клубок, которого вполне достаточно.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Yuri Myakotin
Feb 25, 2015, 5:05:03 AM2/25/15
to
Hello Alexey!
Wednesday February 25 2015 12:12, Alexey Vissarionov wrote to Yuri Myakotin:
YM>>>> нужной размерности и XORится с результатом штатного генератора.
AV>>> образом.
А смысл? Так как сейчас - имеем смесь хеша и штатного рандома, т.е. при
предсказуемости любой из частей общий результат все равно получается
непредсказуемым.
Wednesday February 25 2015 12:12, Alexey Vissarionov wrote to Yuri Myakotin:
YM>>>> нужной размерности и XORится с результатом штатного генератора.
AV>>> А зачем? Собираешь энтропию из системы, добавляешь из штатного
AV>>> генератора, отбеливаешь хеш-функцией - и вот тебе IV для
AV>>> генерации гаммы. Blowfish-CFB подходит для этого чудеснейшим
AV>>> генератора, отбеливаешь хеш-функцией - и вот тебе IV для
AV>>> образом.
YM>> Была и такая мысль, но поленился и сделал как написано выше.
AV> Если не поздно - лучше переделай.
А смысл? Так как сейчас - имеем смесь хеша и штатного рандома, т.е. при
предсказуемости любой из частей общий результат все равно получается
непредсказуемым.
Serguei E. Leontiev
Mar 7, 2015, 4:48:50 PM3/7/15
to
Привет Юрий,
От 22 февраля 2015 г., 23:07:59 в fido7.ru.crypt ты писал:
YM> Hello All!
YM> Hасколько надежен (в плане отсутствия бэкдоров, позволяющих
YM> предсказать последовательность бит) штатный CryptGenRandom под
YM> виндой?
Было несколько статей посвящённых исследованию CryptGenRandom() под
Windows, если мне не изменяет память, некоторые даже сравнивали с Linux.
В принципе, два сапога - пара, при правильной эксплуатации достаточно
надёжны (если не забывать, что ну у одной из спецслужб нет претензий в
части нарушения Вассенарских соглашений, ни к Microsoft, ни к
производителям Linux :); Т.е. их устраивает текущее положение дел)
YM> Стоит ли для пущей паранойи (скажем, при генерации
YM> секретного ключа) XORить его результат, к примеру, с хешом от
YM> сочетания "факторов энтропии" (текущее время, аптайм системы,
YM> свободное место на дисках etc)? See all in Hell,
Hе надо ограничивать собственную паранойю, однако, станет ли лучше?
--
Успехов, Сергей Леонтьев. E-mail: l...@CryptoPro.ru
От 22 февраля 2015 г., 23:07:59 в fido7.ru.crypt ты писал:
YM> Hello All!
YM> Hасколько надежен (в плане отсутствия бэкдоров, позволяющих
YM> предсказать последовательность бит) штатный CryptGenRandom под
YM> виндой?
Было несколько статей посвящённых исследованию CryptGenRandom() под
Windows, если мне не изменяет память, некоторые даже сравнивали с Linux.
В принципе, два сапога - пара, при правильной эксплуатации достаточно
надёжны (если не забывать, что ну у одной из спецслужб нет претензий в
части нарушения Вассенарских соглашений, ни к Microsoft, ни к
производителям Linux :); Т.е. их устраивает текущее положение дел)
YM> Стоит ли для пущей паранойи (скажем, при генерации
YM> секретного ключа) XORить его результат, к примеру, с хешом от
YM> сочетания "факторов энтропии" (текущее время, аптайм системы,
YM> свободное место на дисках etc)? See all in Hell,
Hе надо ограничивать собственную паранойю, однако, станет ли лучше?
--
Успехов, Сергей Леонтьев. E-mail: l...@CryptoPro.ru
Serguei E. Leontiev
Mar 7, 2015, 4:51:51 PM3/7/15
to
Привет Алексей,
От 24 февраля 2015 г., 16:32:00 в fido7.ru.crypt ты писал:
AV> Встречный вопрос #0: ты егойные исходники видел?
AV> Если нет - ответ кагбэ очевиден.
Как говорил Деннис Ритчи, в лекции на получение Тьюринга, вы либо верите
хорошему программисту, либо нет, а исходные тексты вам не помогут за ним
уследить.
Hе даром, у ФСТЭК на определённом уровне предусмотрена проверка
соответствия бинарных и исходных кодов.
А бинарный код CryptGenRandom(), он тоже каждому доступен, берёшь IDA и
в путь, с песней.
YM>> Стоит ли для пущей паранойи (скажем, при генерации
YM>> секретного ключа) XORить его результат, к примеру, с хешом
YM>> от сочетания "факторов энтропии" (текущее время, аптайм
YM>> системы, свободное место на дисках etc)?
AV> Да. Посмотри, как реализовано add_device_randomness() в ядре
Только вот точно так делать не стоит, там есть нехорошие места (я знаю,
ты не веришь в это, но лучше товарищу пару статей прочитать, что бы хотя
бы осознать постановку задачи и те проблемы, которые имеются у
существующих генераторов).
От 24 февраля 2015 г., 16:32:00 в fido7.ru.crypt ты писал:
YM>> Hасколько надежен (в плане отсутствия бэкдоров, позволяющих
YM>> предсказать последовательность бит) штатный CryptGenRandom
YM>> под виндой?
YM>> предсказать последовательность бит) штатный CryptGenRandom
AV> Встречный вопрос #0: ты егойные исходники видел?
AV> Если нет - ответ кагбэ очевиден.
Как говорил Деннис Ритчи, в лекции на получение Тьюринга, вы либо верите
хорошему программисту, либо нет, а исходные тексты вам не помогут за ним
уследить.
Hе даром, у ФСТЭК на определённом уровне предусмотрена проверка
соответствия бинарных и исходных кодов.
А бинарный код CryptGenRandom(), он тоже каждому доступен, берёшь IDA и
в путь, с песней.
YM>> Стоит ли для пущей паранойи (скажем, при генерации
YM>> от сочетания "факторов энтропии" (текущее время, аптайм
YM>> системы, свободное место на дисках etc)?
AV> Да. Посмотри, как реализовано add_device_randomness() в ядре
Только вот точно так делать не стоит, там есть нехорошие места (я знаю,
ты не веришь в это, но лучше товарищу пару статей прочитать, что бы хотя
бы осознать постановку задачи и те проблемы, которые имеются у
существующих генераторов).
Serguei E. Leontiev
Mar 7, 2015, 5:30:22 PM3/7/15
to
Привет Юрий,
От 24 февраля 2015 г., 18:35:19 в fido7.ru.crypt ты писал:
YM> Hello Alexey!
YM> Tuesday February 24 2015 16:32, Alexey Vissarionov wrote to
YM> Yuri Myakotin:
YM>>> хешом от сочетания "факторов энтропии" (текущее время,
YM>>> аптайм системы, свободное место на дисках etc)?
1. CryptGenRandom() не верим совсем, предполагаем, что настоящий
нарушитель знает все биты, которые от него идут. Используем только для
дополнительной защиты от достаточно вероятного сочетания "пионеров" и
лажи в нашем коде;
2. Hе хорошо использовать только открытую информацию, она конечно
трудно поддаётся предсказанию, даже для настоящего нарушителя. Hо легко
наблюдаема со стороны, так что настоящий нарушитель её полностью знает;
3. Всяческая информация записанная на диск или не стёртая из ОЗУ так,
или иначе станет известной настоящему нарушителю;
4. Использование предварительных версий алгоритмов без соответствующего
обоснования нельзя счесть разумным. Да, пару лет назад Keccak выиграл
конкурс на SHA-3, но стандарт, насколько мне известно, ещё не принят.
Кто знает причины задержки?
5. Использование хороших алгоритмов не означает хорошего результата. К
твоему коду следует приложить хотя бы приблизительную формулировку
соответствующей теоремы и её, хотя бы приблизительное, доказательство
или обоснование.
В сумме, настоящий параноик мог бы внести следующие исправления:
а. По п. 2 завести где то, на флэшке, в голове пользователя и т.п.
некоторый секрет и его использовать;
б. Hазвание MemoryStream() слишком обыденное, вряд ли его конструктор
хотя бы блокирует область ОЗУ в памяти или, что лучше, выставляет
обработчик на события выгрузки страницы из ОЗУ в своп или область сна
ОС. Так же вряд ли его деструктор стирает соответствующие области
памяти. Следует завести свой класс с интерфейсом MemoryStream() и
массива EntropyBytes, с соответствующей функциональностью;
в. Как показывают исследования энтропии полученной от информации о
системе не так уж и много, т.е. если известна часть значения
хэш-функции, которая, скажем, попала в синхропосылку (IV) и т.п. То
простым перебором возможно восстановить исходную информацию и,
соответственно другие части хэш-функции, которые были использованы как
ключ. Следует использовать правильное(!) накопление достаточного
количество событий, а не результаты одного измерения.
А без этих измерений, если нарушитель может "взломать" даже
CryptGenRandom(), то ParanoidRNG ему на один зуб, так что безопасность,
ИМХО, не повысилась.
А даже понизилась, если учесть то, что появились дополнительные области
памяти, куда попадают копии значений от RNGCryptoServiceProvider и
прочие возможные ошибки кодирования.
От 24 февраля 2015 г., 18:35:19 в fido7.ru.crypt ты писал:
YM> Hello Alexey!
YM> Tuesday February 24 2015 16:32, Alexey Vissarionov wrote to
YM> Yuri Myakotin:
YM>>> Стоит ли для пущей паранойи (скажем, при генерации
YM>>> секретного ключа) XORить его результат, к примеру, с
YM>>> хешом от сочетания "факторов энтропии" (текущее время,
YM>>> аптайм системы, свободное место на дисках etc)?
AV>> Да. Посмотри, как реализовано add_device_randomness() в
AV>> ядре Linux.
YM> Пока соорудил вот что:
Как-то вот совсем не параноидально. Поясню с точки зрения параноика:
1. CryptGenRandom() не верим совсем, предполагаем, что настоящий
нарушитель знает все биты, которые от него идут. Используем только для
дополнительной защиты от достаточно вероятного сочетания "пионеров" и
лажи в нашем коде;
2. Hе хорошо использовать только открытую информацию, она конечно
трудно поддаётся предсказанию, даже для настоящего нарушителя. Hо легко
наблюдаема со стороны, так что настоящий нарушитель её полностью знает;
3. Всяческая информация записанная на диск или не стёртая из ОЗУ так,
или иначе станет известной настоящему нарушителю;
4. Использование предварительных версий алгоритмов без соответствующего
обоснования нельзя счесть разумным. Да, пару лет назад Keccak выиграл
конкурс на SHA-3, но стандарт, насколько мне известно, ещё не принят.
Кто знает причины задержки?
5. Использование хороших алгоритмов не означает хорошего результата. К
твоему коду следует приложить хотя бы приблизительную формулировку
соответствующей теоремы и её, хотя бы приблизительное, доказательство
или обоснование.
В сумме, настоящий параноик мог бы внести следующие исправления:
а. По п. 2 завести где то, на флэшке, в голове пользователя и т.п.
некоторый секрет и его использовать;
б. Hазвание MemoryStream() слишком обыденное, вряд ли его конструктор
хотя бы блокирует область ОЗУ в памяти или, что лучше, выставляет
обработчик на события выгрузки страницы из ОЗУ в своп или область сна
ОС. Так же вряд ли его деструктор стирает соответствующие области
памяти. Следует завести свой класс с интерфейсом MemoryStream() и
массива EntropyBytes, с соответствующей функциональностью;
в. Как показывают исследования энтропии полученной от информации о
системе не так уж и много, т.е. если известна часть значения
хэш-функции, которая, скажем, попала в синхропосылку (IV) и т.п. То
простым перебором возможно восстановить исходную информацию и,
соответственно другие части хэш-функции, которые были использованы как
ключ. Следует использовать правильное(!) накопление достаточного
количество событий, а не результаты одного измерения.
А без этих измерений, если нарушитель может "взломать" даже
CryptGenRandom(), то ParanoidRNG ему на один зуб, так что безопасность,
ИМХО, не повысилась.
А даже понизилась, если учесть то, что появились дополнительные области
памяти, куда попадают копии значений от RNGCryptoServiceProvider и
прочие возможные ошибки кодирования.
Alexey Vissarionov
Mar 8, 2015, 3:35:02 AM3/8/15
to
Доброго времени суток, Serguei!
08 Mar 2015 00:51:48, ты -> мне:
YM>>> Стоит ли для пущей паранойи (скажем, при генерации секретного
YM>>> ключа) XORить его результат, к примеру, с хешом от сочетания
YM>>> "факторов энтропии" (текущее время, аптайм системы, свободное
YM>>> место на дисках etc)?
Функция, строка?
SL> (я знаю, ты не веришь в это,
Пока не увижу описание атаки, не поверю. Знаю разве что про эксперимент
https://factorable.net/weakkeys12.extended.pdf - но там авторы разве что
экспериментировали с отключением ядерных источников энтрогпии, а попутно
(случайно и не совсем очевидно) вынесли смертный приговор systemd.
SL> но лучше товарищу пару статей прочитать, что бы хотя бы осознать
SL> постановку задачи и те проблемы, которые имеются у существующих
SL> генераторов).
Ну, это еще никому не вредило...
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Опыты над мышами подтверждают, что встреча с черной кошкой - плохая примета
08 Mar 2015 00:51:48, ты -> мне:
YM>>> Стоит ли для пущей паранойи (скажем, при генерации секретного
YM>>> ключа) XORить его результат, к примеру, с хешом от сочетания
YM>>> "факторов энтропии" (текущее время, аптайм системы, свободное
YM>>> место на дисках etc)?
AV>> Да. Посмотри, как реализовано add_device_randomness() в ядре
SL> Только вот точно так делать не стоит, там есть нехорошие места
Функция, строка?
SL> (я знаю, ты не веришь в это,
Пока не увижу описание атаки, не поверю. Знаю разве что про эксперимент
https://factorable.net/weakkeys12.extended.pdf - но там авторы разве что
экспериментировали с отключением ядерных источников энтрогпии, а попутно
(случайно и не совсем очевидно) вынесли смертный приговор systemd.
SL> но лучше товарищу пару статей прочитать, что бы хотя бы осознать
SL> постановку задачи и те проблемы, которые имеются у существующих
SL> генераторов).
Ну, это еще никому не вредило...
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Yuri Myakotin
Mar 8, 2015, 5:35:02 AM3/8/15
to
Hello Serguei!
Sunday March 08 2015 01:30, Serguei E. Leontiev wrote to Yuri Myakotin:
SL> Как-то вот совсем не параноидально. Поясню с точки зрения параноика:
SL> 1. CryptGenRandom() не верим совсем, предполагаем, что настоящий
SL> нарушитель знает все биты, которые от него идут. Используем только для
SL> дополнительной защиты от достаточно вероятного сочетания "пионеров" и
SL> лажи в нашем коде;
SL> 2. Hе хорошо использовать только открытую информацию, она конечно
SL> трудно поддаётся предсказанию, даже для настоящего нарушителя. Hо
SL> легко наблюдаема со стороны, так что настоящий нарушитель её полностью
SL> знает;
SL> 3. Всяческая информация записанная на диск или не стёртая из ОЗУ так,
SL> или иначе станет известной настоящему нарушителю;
Предполагаем, что супостат не имеет физического доступа к компьютеру. Если
имеет - он и так всю информацию на нем прочтет, без необходимости перехватывать
и расшифровывать сетевой трафик.
SL> 4. Использование предварительных версий алгоритмов без
SL> соответствующего обоснования нельзя счесть разумным. Да, пару лет
SL> назад Keccak выиграл конкурс на SHA-3,
Я использовал 3 алгоритма-финалиста конкурса, один из двух (Blake/Keccak) как
"предварительный" этап с 512 бит на выходе, и третий (Skein) как окончательный,
дающий на выходе нужную битность. Т.е. даже найденная дыра в одном из трех - не
делает дырявой всю схему.
SL> 5. Использование хороших алгоритмов не означает хорошего результата.
SL> К твоему коду следует приложить хотя бы приблизительную
SL> формулировку соответствующей теоремы и её, хотя бы приблизительное,
SL> доказательство или обоснование.
SL> В сумме, настоящий параноик мог бы внести следующие исправления:
SL> а. По п. 2 завести где то, на флэшке, в голове пользователя и т.п.
SL> некоторый секрет и его использовать;
Для генерации секретной части разовых сессионных ключей (Shared key получаю
алгоритмом Curve25519) это было бы несколько неудобно (особенно на сервере, где
все должно крутиться автономно). А для вот генерации длительно используемых
ключей (например, тех, которыми пользователь A шифрует свои сообщения для
пользователя Б) - так и так будет использована дополнительная энтропия от
действий пользователя.
Sunday March 08 2015 01:30, Serguei E. Leontiev wrote to Yuri Myakotin:
SL> Как-то вот совсем не параноидально. Поясню с точки зрения параноика:
SL> 1. CryptGenRandom() не верим совсем, предполагаем, что настоящий
SL> нарушитель знает все биты, которые от него идут. Используем только для
SL> дополнительной защиты от достаточно вероятного сочетания "пионеров" и
SL> лажи в нашем коде;
SL> 2. Hе хорошо использовать только открытую информацию, она конечно
SL> трудно поддаётся предсказанию, даже для настоящего нарушителя. Hо
SL> легко наблюдаема со стороны, так что настоящий нарушитель её полностью
SL> знает;
SL> 3. Всяческая информация записанная на диск или не стёртая из ОЗУ так,
SL> или иначе станет известной настоящему нарушителю;
Предполагаем, что супостат не имеет физического доступа к компьютеру. Если
имеет - он и так всю информацию на нем прочтет, без необходимости перехватывать
и расшифровывать сетевой трафик.
SL> 4. Использование предварительных версий алгоритмов без
SL> соответствующего обоснования нельзя счесть разумным. Да, пару лет
SL> назад Keccak выиграл конкурс на SHA-3,
Я использовал 3 алгоритма-финалиста конкурса, один из двух (Blake/Keccak) как
"предварительный" этап с 512 бит на выходе, и третий (Skein) как окончательный,
дающий на выходе нужную битность. Т.е. даже найденная дыра в одном из трех - не
делает дырявой всю схему.
SL> 5. Использование хороших алгоритмов не означает хорошего результата.
SL> К твоему коду следует приложить хотя бы приблизительную
SL> формулировку соответствующей теоремы и её, хотя бы приблизительное,
SL> доказательство или обоснование.
SL> В сумме, настоящий параноик мог бы внести следующие исправления:
SL> а. По п. 2 завести где то, на флэшке, в голове пользователя и т.п.
SL> некоторый секрет и его использовать;
Для генерации секретной части разовых сессионных ключей (Shared key получаю
алгоритмом Curve25519) это было бы несколько неудобно (особенно на сервере, где
все должно крутиться автономно). А для вот генерации длительно используемых
ключей (например, тех, которыми пользователь A шифрует свои сообщения для
пользователя Б) - так и так будет использована дополнительная энтропия от
действий пользователя.
Alexey Vissarionov
Mar 8, 2015, 2:35:02 PM3/8/15
to
Доброго времени суток, Yuri!
08 Mar 2015 12:25:34, ты -> Serguei E. Leontiev:
SL>> 4. Использование предварительных версий алгоритмов без
SL>> соответствующего обоснования нельзя счесть разумным. Да,
SL>> пару лет назад Keccak выиграл конкурс на SHA-3,
Было бы странно, если бы не выиграл: деньги на его разработку к моменту
проведения конкурса были не только получены, но и давно распилены.
YM> Я использовал 3 алгоритма-финалиста конкурса, один из двух
YM> (Blake/Keccak) как "предварительный" этап с 512 бит на выходе, и
YM> третий (Skein) как окончательный, дающий на выходе нужную битность.
YM> Т.е. даже найденная дыра в одном из трех - не делает дырявой всю
YM> схему.
Для отбеливания достаточно одного (любого, хотя я бы взял клубок).
SL>> завести где то, на флэшке, в голове пользователя и т.п. некоторый
SL>> секрет и его использовать;
YM> Для генерации секретной части разовых сессионных ключей (Shared key
YM> получаю алгоритмом Curve25519)
Использование алгоритмов, основанных на эллиптических кривых - решение, мягко
говоря, далекое от мудрости уже потому, что описать на заданном конечном поле
кривую с нужными свойствами (обеспечивающими закладку) проще, чем исследовать
предложенную кем-то другим (искать ту закладку).
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... GCC/IT d- s: a C++ UL++++$ P++ L++++$ E--- W- N++ w-- PS- PE PGP++ y? h+
08 Mar 2015 12:25:34, ты -> Serguei E. Leontiev:
SL>> 4. Использование предварительных версий алгоритмов без
SL>> соответствующего обоснования нельзя счесть разумным. Да,
Было бы странно, если бы не выиграл: деньги на его разработку к моменту
проведения конкурса были не только получены, но и давно распилены.
YM> Я использовал 3 алгоритма-финалиста конкурса, один из двух
YM> (Blake/Keccak) как "предварительный" этап с 512 бит на выходе, и
YM> третий (Skein) как окончательный, дающий на выходе нужную битность.
YM> Т.е. даже найденная дыра в одном из трех - не делает дырявой всю
YM> схему.
Для отбеливания достаточно одного (любого, хотя я бы взял клубок).
SL>> завести где то, на флэшке, в голове пользователя и т.п. некоторый
SL>> секрет и его использовать;
YM> Для генерации секретной части разовых сессионных ключей (Shared key
YM> получаю алгоритмом Curve25519)
Использование алгоритмов, основанных на эллиптических кривых - решение, мягко
говоря, далекое от мудрости уже потому, что описать на заданном конечном поле
кривую с нужными свойствами (обеспечивающими закладку) проще, чем исследовать
предложенную кем-то другим (искать ту закладку).
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Yuri Myakotin
Mar 8, 2015, 4:45:03 PM3/8/15
to
Hello Alexey!
Sunday March 08 2015 21:12, Alexey Vissarionov wrote to Yuri Myakotin:
YM>> Для генерации секретной части разовых сессионных ключей (Shared
YM>> key получаю алгоритмом Curve25519)
AV> Использование алгоритмов, основанных на эллиптических кривых -
AV> решение, мягко говоря, далекое от мудрости уже потому, что описать на
AV> заданном конечном поле кривую с нужными свойствами (обеспечивающими
AV> закладку) проще, чем исследовать предложенную кем-то другим (искать ту
AV> закладку).
Hу, конкретно эту сейчас использует тот же Тор.
http://habrahabr.ru/post/247873/ подробнее о алгоритме и авторе.
Sunday March 08 2015 21:12, Alexey Vissarionov wrote to Yuri Myakotin:
YM>> Для генерации секретной части разовых сессионных ключей (Shared
AV> Использование алгоритмов, основанных на эллиптических кривых -
AV> решение, мягко говоря, далекое от мудрости уже потому, что описать на
AV> заданном конечном поле кривую с нужными свойствами (обеспечивающими
AV> закладку) проще, чем исследовать предложенную кем-то другим (искать ту
AV> закладку).
Hу, конкретно эту сейчас использует тот же Тор.
http://habrahabr.ru/post/247873/ подробнее о алгоритме и авторе.
Alexey Vissarionov
Mar 9, 2015, 2:45:02 AM3/9/15
to
Доброго времени суток, Yuri!
08 Mar 2015 23:27:36, ты -> мне:
YM>>> Для генерации секретной части разовых сессионных ключей (Shared
YM>>> key получаю алгоритмом Curve25519)
AV>> Использование алгоритмов, основанных на эллиптических кривых
AV>> - решение, мягко говоря, далекое от мудрости уже потому, что
AV>> описать на заданном конечном поле кривую с нужными свойствами
AV>> (обеспечивающими закладку) проще, чем исследовать предложенную
AV>> кем-то другим (искать ту закладку).
YM> Hу, конкретно эту сейчас использует тот же Тор.
Вспомни, кто этот тор изначально разрабатывал...
YM> http://habrahabr.ru/post/247873/ подробнее о алгоритме и авторе.
Автор - широко известный в узких кругах DJB... Прославился редкостным
головожопием (как ни странно, без рукожопия) в области программирования:
достаточно назвать недоброй памяти qmail.
А еще разработчики эхотажных алгоритмов в массе своей далеки от "железа",
которое будет выполнять оные в реальной жизни. Причем просеры бывают и у
признанных мэтров наподобие Шнайера - тот же Twofish всем хорош, но я бы
выполнял его только в многопоточной среде, потому что операция начального
отбеливания позволяет срисовать ключ из криптопроцессора, наблюдая за его
энергопотреблением.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Пренебрежение страховкой карается по закону. Всемирного тяготения.
08 Mar 2015 23:27:36, ты -> мне:
YM>>> Для генерации секретной части разовых сессионных ключей (Shared
YM>>> key получаю алгоритмом Curve25519)
AV>> Использование алгоритмов, основанных на эллиптических кривых
AV>> описать на заданном конечном поле кривую с нужными свойствами
AV>> (обеспечивающими закладку) проще, чем исследовать предложенную
AV>> кем-то другим (искать ту закладку).
YM> Hу, конкретно эту сейчас использует тот же Тор.
Вспомни, кто этот тор изначально разрабатывал...
YM> http://habrahabr.ru/post/247873/ подробнее о алгоритме и авторе.
Автор - широко известный в узких кругах DJB... Прославился редкостным
головожопием (как ни странно, без рукожопия) в области программирования:
достаточно назвать недоброй памяти qmail.
А еще разработчики эхотажных алгоритмов в массе своей далеки от "железа",
которое будет выполнять оные в реальной жизни. Причем просеры бывают и у
признанных мэтров наподобие Шнайера - тот же Twofish всем хорош, но я бы
выполнял его только в многопоточной среде, потому что операция начального
отбеливания позволяет срисовать ключ из криптопроцессора, наблюдая за его
энергопотреблением.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Yuri Myakotin
Mar 9, 2015, 8:55:03 AM3/9/15
to
Hello Alexey!
Monday March 09 2015 09:33, Alexey Vissarionov wrote to Yuri Myakotin:
AV>>> кем-то другим (искать ту закладку).
YM>> Hу, конкретно эту сейчас использует тот же Тор.
AV> Вспомни, кто этот тор изначально разрабатывал...
I2P тоже? Hу и в OpenSSL последних версий Curve25519 уже как дефолт
принимается.
Альтернативы-то для получения shared ключей есть еще какие? Громоздкий (в плане
размеров паблик ключа) RSA, короткие ключи которого небезопасны уже сейчас?
Monday March 09 2015 09:33, Alexey Vissarionov wrote to Yuri Myakotin:
AV>>> кем-то другим (искать ту закладку).
YM>> Hу, конкретно эту сейчас использует тот же Тор.
I2P тоже? Hу и в OpenSSL последних версий Curve25519 уже как дефолт
принимается.
Альтернативы-то для получения shared ключей есть еще какие? Громоздкий (в плане
размеров паблик ключа) RSA, короткие ключи которого небезопасны уже сейчас?
Alexey Vissarionov
Mar 9, 2015, 9:45:03 AM3/9/15
to
Доброго времени суток, Yuri!
09 Mar 2015 15:44:38, ты -> мне:
AV>>>> кем-то другим (искать ту закладку).
YM>>> Hу, конкретно эту сейчас использует тот же Тор.
AV>> Вспомни, кто этот тор изначально разрабатывал...
YM> I2P тоже? Hу и в OpenSSL последних версий Curve25519 уже как дефолт
YM> принимается.
К счастью, при сборке все еще можно сказать "No EC".
А вот выпилить оттуда Rijndael уже нельзя...
YM> Альтернативы-то для получения shared ключей есть еще какие?
YM> Громоздкий (в плане размеров паблик ключа) RSA, короткие ключи
YM> которого небезопасны уже сейчас?
Или тот же Эль-Гамаль, но в обычном кольце вычетов. Главное - увеличивать
требования нужно не только к вычислительной мощности, но и к топологии
криптопроцессора, и к его энергопотреблению. Сам подумай: какой смысл в
датацентре, способном что-то там факторизовать, если ему для работы нужно
построить рядом десяток РБМК, а потом куда-то отвести тепло от всей егойной
электроники? :-)
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... ИМХО: Имею Мнение - Хрен Оспоришь
09 Mar 2015 15:44:38, ты -> мне:
AV>>>> кем-то другим (искать ту закладку).
YM>>> Hу, конкретно эту сейчас использует тот же Тор.
AV>> Вспомни, кто этот тор изначально разрабатывал...
YM> принимается.
К счастью, при сборке все еще можно сказать "No EC".
А вот выпилить оттуда Rijndael уже нельзя...
YM> Альтернативы-то для получения shared ключей есть еще какие?
YM> Громоздкий (в плане размеров паблик ключа) RSA, короткие ключи
YM> которого небезопасны уже сейчас?
Или тот же Эль-Гамаль, но в обычном кольце вычетов. Главное - увеличивать
требования нужно не только к вычислительной мощности, но и к топологии
криптопроцессора, и к его энергопотреблению. Сам подумай: какой смысл в
датацентре, способном что-то там факторизовать, если ему для работы нужно
построить рядом десяток РБМК, а потом куда-то отвести тепло от всей егойной
электроники? :-)
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Serguei E. Leontiev
Mar 9, 2015, 10:55:26 AM3/9/15
to
Юрий, привет,
Yuri Myakotin <Yuri.M...@p1.f4441.n5020.z2.fidonet.org> wrote:
>> 3. Всяческая информация записанная на диск или не стёртая из ОЗУ так,
ремонтника. Да и разные программы, бывает, передают в сеть
неинициализированные буфера.
>> 4. Использование предварительных версий алгоритмов без
>> В сумме, настоящий параноик мог бы внести следующие исправления:
сервера правильным администратором, вставь в него, хотя бы, секретную
флэшку.
> А для вот генерации длительно используемых
> ключей (например, тех, которыми пользователь A шифрует свои сообщения для
> пользователя Б) - так и так будет использована дополнительная энтропия от
> действий пользователя.
Действия пользователя и энтропия от них наблюдаемы, а секрет нет.
--
Успехов, Сергей Леонтьев, <http://www.cryptopro.ru> (NewsTap)
Yuri Myakotin <Yuri.M...@p1.f4441.n5020.z2.fidonet.org> wrote:
>> 3. Всяческая информация записанная на диск или не стёртая из ОЗУ так,
>> или иначе станет известной настоящему нарушителю;
> Предполагаем, что супостат не имеет физического доступа к компьютеру. Если
> имеет - он и так всю информацию на нем прочтет, без необходимости перехватывать
> и расшифровывать сетевой трафик.
Hу, ты его когда-нибудь выкинешь, заменишь диск или вообще пригласишь
> Предполагаем, что супостат не имеет физического доступа к компьютеру. Если
> имеет - он и так всю информацию на нем прочтет, без необходимости перехватывать
> и расшифровывать сетевой трафик.
ремонтника. Да и разные программы, бывает, передают в сеть
неинициализированные буфера.
>> 4. Использование предварительных версий алгоритмов без
>> соответствующего обоснования нельзя счесть разумным. Да, пару лет
>> назад Keccak выиграл конкурс на SHA-3,
> Я использовал 3 алгоритма-финалиста конкурса, один из двух (Blake/Keccak) как
> "предварительный" этап с 512 бит на выходе, и третий (Skein) как окончательный,
> дающий на выходе нужную битность. Т.е. даже найденная дыра в одном из трех - не
> делает дырявой всю схему.
Или наоборот, дыра найденная в любом из них делает дырявой всю схему.
> Я использовал 3 алгоритма-финалиста конкурса, один из двух (Blake/Keccak) как
> "предварительный" этап с 512 бит на выходе, и третий (Skein) как окончательный,
> дающий на выходе нужную битность. Т.е. даже найденная дыра в одном из трех - не
> делает дырявой всю схему.
>> В сумме, настоящий параноик мог бы внести следующие исправления:
>> а. По п. 2 завести где то, на флэшке, в голове пользователя и т.п.
>> некоторый секрет и его использовать;
> Для генерации секретной части разовых сессионных ключей (Shared key получаю
> алгоритмом Curve25519) это было бы несколько неудобно (особенно на сервере, где
> все должно крутиться автономно).
И? Hеудобно? Hо тогда зачем всё? Если не нравится процедура перезапуска
> Для генерации секретной части разовых сессионных ключей (Shared key получаю
> алгоритмом Curve25519) это было бы несколько неудобно (особенно на сервере, где
> все должно крутиться автономно).
сервера правильным администратором, вставь в него, хотя бы, секретную
флэшку.
> А для вот генерации длительно используемых
> ключей (например, тех, которыми пользователь A шифрует свои сообщения для
> пользователя Б) - так и так будет использована дополнительная энтропия от
> действий пользователя.
--
Успехов, Сергей Леонтьев, <http://www.cryptopro.ru> (NewsTap)
Serguei E. Leontiev
Mar 9, 2015, 11:10:56 AM3/9/15
to
Привет Алексей,
От 8 марта 2015 г., 10:30:00 в fido7.ru.crypt ты писал:
AV> Функция, строка?
Грубо говоря, алгоритм в целом, смотри соответствующие статьи.
От 8 марта 2015 г., 10:30:00 в fido7.ru.crypt ты писал:
AV>>> Да. Посмотри, как реализовано add_device_randomness() в
AV>>> ядре
SL>> Только вот точно так делать не стоит, там есть нехорошие
SL>> места
AV> Функция, строка?
Грубо говоря, алгоритм в целом, смотри соответствующие статьи.
Serguei E. Leontiev
Mar 9, 2015, 11:20:27 AM3/9/15
to
Привет Алексей,
От 8 марта 2015 г., 21:12:22 в fido7.ru.crypt ты писал:
AV> Использование алгоритмов, основанных на эллиптических кривых -
AV> решение, мягко говоря, далекое от мудрости уже потому, что
AV> описать на заданном конечном поле кривую с нужными свойствами
AV> (обеспечивающими закладку) проще, чем исследовать предложенную
AV> кем-то другим (искать ту закладку). --
У тебя есть обоснованное недоверие процедуре получения подтверждаемых
параметров эллиптической кривой согласно X9.62?
Или есть недоверие к наборам параметров, которые были получены в разрез
с этой процедурой, таким как параметры по умолчанию в алгоритме ДСЧ NIST
SP 800-90A?
От 8 марта 2015 г., 21:12:22 в fido7.ru.crypt ты писал:
AV> Использование алгоритмов, основанных на эллиптических кривых -
AV> решение, мягко говоря, далекое от мудрости уже потому, что
AV> описать на заданном конечном поле кривую с нужными свойствами
AV> (обеспечивающими закладку) проще, чем исследовать предложенную
AV> кем-то другим (искать ту закладку). --
У тебя есть обоснованное недоверие процедуре получения подтверждаемых
параметров эллиптической кривой согласно X9.62?
Или есть недоверие к наборам параметров, которые были получены в разрез
с этой процедурой, таким как параметры по умолчанию в алгоритме ДСЧ NIST
SP 800-90A?
Yuri Myakotin
Mar 9, 2015, 12:15:02 PM3/9/15
to
Hello Serguei!
Monday March 09 2015 17:55, Serguei E. Leontiev wrote to Yuri Myakotin:
>> Предполагаем, что супостат не имеет физического доступа к
>> компьютеру. Если имеет - он и так всю информацию на нем прочтет, без
>> необходимости перехватывать и расшифровывать сетевой трафик.
SL> Hу, ты его когда-нибудь выкинешь, заменишь диск или вообще пригласишь
SL> ремонтника.
... и получим то же самое - нешифрованную исходную информацию в чужих руках,
которую восстановить проще и эффективнее, чем искать в свопе разовый ключ от
сетевой сессии, прошедшей фиг-знает-когда.
SL> Да и разные программы, бывает, передают в сеть
SL> неинициализированные буфера.
Hу, вот этого я избегаю :) даже если нужно добить сообщение до размера
шифроблока - добивается рандомом же.
>> (Blake/Keccak) как "предварительный" этап с 512 бит на выходе, и
>> третий (Skein) как окончательный, дающий на выходе нужную битность.
>> Т.е. даже найденная дыра в одном из трех - не делает дырявой всю
>> схему.
SL> Или наоборот, дыра найденная в любом из них делает дырявой всю схему.
2 последовательных преобразования, одно из них дырявое, другое нет - как
дырявость одного из них поможет узнать, что было на входе?
>> Для генерации секретной части разовых сессионных ключей (Shared key
>> получаю алгоритмом Curve25519) это было бы несколько неудобно
>> (особенно на сервере, где все должно крутиться автономно).
SL> И? Hеудобно? Hо тогда зачем всё? Если не нравится процедура
SL> перезапуска сервера правильным администратором, вставь в него, хотя
SL> бы, секретную флэшку.
Собственно, в софте, который я сейчас делаю, на сервере вообще ничего
секретного нет - шифрация трафика лишь мешает условному СОРМу отследить, кто
именно кому именно шлет сообщение. А вот само сообщение перед отправкой
шифруется уже гораздо более серьезно, без полностью автономной генерации
ключей. И сервер этих ключей не видит и не имеет, они только у посылающего и
адресата.
PS to All: нубский вопрос номер два: Разные ключи для приема и для отсылки
(полностью независимые алгоритмически) - имеют смысл?
Monday March 09 2015 17:55, Serguei E. Leontiev wrote to Yuri Myakotin:
>> Предполагаем, что супостат не имеет физического доступа к
>> компьютеру. Если имеет - он и так всю информацию на нем прочтет, без
>> необходимости перехватывать и расшифровывать сетевой трафик.
SL> ремонтника.
... и получим то же самое - нешифрованную исходную информацию в чужих руках,
которую восстановить проще и эффективнее, чем искать в свопе разовый ключ от
сетевой сессии, прошедшей фиг-знает-когда.
SL> Да и разные программы, бывает, передают в сеть
SL> неинициализированные буфера.
Hу, вот этого я избегаю :) даже если нужно добить сообщение до размера
шифроблока - добивается рандомом же.
>> (Blake/Keccak) как "предварительный" этап с 512 бит на выходе, и
>> третий (Skein) как окончательный, дающий на выходе нужную битность.
>> Т.е. даже найденная дыра в одном из трех - не делает дырявой всю
>> схему.
2 последовательных преобразования, одно из них дырявое, другое нет - как
дырявость одного из них поможет узнать, что было на входе?
>> Для генерации секретной части разовых сессионных ключей (Shared key
>> получаю алгоритмом Curve25519) это было бы несколько неудобно
>> (особенно на сервере, где все должно крутиться автономно).
SL> перезапуска сервера правильным администратором, вставь в него, хотя
SL> бы, секретную флэшку.
Собственно, в софте, который я сейчас делаю, на сервере вообще ничего
секретного нет - шифрация трафика лишь мешает условному СОРМу отследить, кто
именно кому именно шлет сообщение. А вот само сообщение перед отправкой
шифруется уже гораздо более серьезно, без полностью автономной генерации
ключей. И сервер этих ключей не видит и не имеет, они только у посылающего и
адресата.
PS to All: нубский вопрос номер два: Разные ключи для приема и для отсылки
(полностью независимые алгоритмически) - имеют смысл?
Alexey Vissarionov
Mar 9, 2015, 12:25:02 PM3/9/15
to
Доброго времени суток, Serguei!
09 Mar 2015 18:10:54, ты -> мне:
AV>>>> Да. Посмотри, как реализовано add_device_randomness()
Единственное, что я нашел осмысленного - это исследование, упомянутое в
предыдущем сообщении (2 назад по треду). Но там речь идет лишь о том, что
генерировать ключевые пары полагается не в процессе "холодной" загрузки
(пользуясь случаем передаю большой превед любителям systemd), а чучуть
подождать, чтобы генератор сабжа набрал энтропию.
Про эту особенность я знаю, и именно поэтому использую дополнительное
USB-устройство (на сдвоенном операционнике и ATtiny 85), которое способно
заполнить пул энтропии ядерного ГСЧ менее чем за секунду.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Детский WikiLeaks: Деда Мороза не существует, жопа от сладкого не слипается
09 Mar 2015 18:10:54, ты -> мне:
AV>>>> Да. Посмотри, как реализовано add_device_randomness()
SL>>> Только вот точно так делать не стоит, там есть нехорошие
SL>>> места
AV>> Функция, строка?
SL> Грубо говоря, алгоритм в целом, смотри соответствующие статьи.
SL>>> места
AV>> Функция, строка?
Единственное, что я нашел осмысленного - это исследование, упомянутое в
предыдущем сообщении (2 назад по треду). Но там речь идет лишь о том, что
генерировать ключевые пары полагается не в процессе "холодной" загрузки
(пользуясь случаем передаю большой превед любителям systemd), а чучуть
подождать, чтобы генератор сабжа набрал энтропию.
Про эту особенность я знаю, и именно поэтому использую дополнительное
USB-устройство (на сдвоенном операционнике и ATtiny 85), которое способно
заполнить пул энтропии ядерного ГСЧ менее чем за секунду.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Alexey Vissarionov
Mar 9, 2015, 12:55:02 PM3/9/15
to
Доброго времени суток, Serguei!
09 Mar 2015 18:20:24, ты -> мне:
AV>> Использование алгоритмов, основанных на эллиптических кривых -
AV>> решение, мягко говоря, далекое от мудрости уже потому, что
AV>> описать на заданном конечном поле кривую с нужными свойствами
AV>> (обеспечивающими закладку) проще, чем исследовать предложенную
AV>> кем-то другим (искать ту закладку).
SL> У тебя есть обоснованное недоверие процедуре получения
SL> подтверждаемых
Кем и как?
SL> параметров эллиптической кривой согласно X9.62?
Да, по вышепроцитированной причине. А если еще вспомнить про крайне слабую
документированность этих процедур... то есть, "вот эти не используйте, они
совсем слабые" - и все.
SL> Или есть недоверие к наборам параметров, которые были получены
SL> в разрез с этой процедурой, таким как параметры по умолчанию в
SL> алгоритме ДСЧ NIST SP 800-90A?
Там вообще откровеннейшая закладка...
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Вопрос понял, ответ думаю
09 Mar 2015 18:20:24, ты -> мне:
AV>> Использование алгоритмов, основанных на эллиптических кривых -
AV>> решение, мягко говоря, далекое от мудрости уже потому, что
AV>> описать на заданном конечном поле кривую с нужными свойствами
AV>> (обеспечивающими закладку) проще, чем исследовать предложенную
AV>> кем-то другим (искать ту закладку).
SL> подтверждаемых
Кем и как?
SL> параметров эллиптической кривой согласно X9.62?
Да, по вышепроцитированной причине. А если еще вспомнить про крайне слабую
документированность этих процедур... то есть, "вот эти не используйте, они
совсем слабые" - и все.
SL> Или есть недоверие к наборам параметров, которые были получены
SL> в разрез с этой процедурой, таким как параметры по умолчанию в
SL> алгоритме ДСЧ NIST SP 800-90A?
Там вообще откровеннейшая закладка...
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Alexey Vissarionov
Mar 9, 2015, 12:55:02 PM3/9/15
to
Доброго времени суток, Yuri!
09 Mar 2015 19:03:20, ты -> Serguei E. Leontiev:
YM> PS to All: нубский вопрос номер два: Разные ключи для приема и для
YM> отсылки (полностью независимые алгоритмически) - имеют смысл?
Внутри одной сессии - нет.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
09 Mar 2015 19:03:20, ты -> Serguei E. Leontiev:
YM> PS to All: нубский вопрос номер два: Разные ключи для приема и для
YM> отсылки (полностью независимые алгоритмически) - имеют смысл?
Внутри одной сессии - нет.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Yuri Myakotin
Mar 9, 2015, 1:25:03 PM3/9/15
to
Hello Alexey!
Monday March 09 2015 19:42, Alexey Vissarionov wrote to Yuri Myakotin:
YM>> PS to All: нубский вопрос номер два: Разные ключи для приема и
YM>> для отсылки (полностью независимые алгоритмически) - имеют смысл?
AV> Внутри одной сессии - нет.
А если брать не сессию, а шифрование собственно сообщений? Типа Вася сообщения
Пете шифрует ключом А, а Петя Васе - ключом Б? Речь, естественно, о ключах
симметричных алгоритмов.
Monday March 09 2015 19:42, Alexey Vissarionov wrote to Yuri Myakotin:
YM>> PS to All: нубский вопрос номер два: Разные ключи для приема и
AV> Внутри одной сессии - нет.
А если брать не сессию, а шифрование собственно сообщений? Типа Вася сообщения
Пете шифрует ключом А, а Петя Васе - ключом Б? Речь, естественно, о ключах
симметричных алгоритмов.
Alexey Vissarionov
Mar 9, 2015, 1:35:03 PM3/9/15
to
Доброго времени суток, Yuri!
09 Mar 2015 20:13:42, ты -> мне:
YM>>> PS to All: нубский вопрос номер два: Разные ключи для приема и
YM>>> для отсылки (полностью независимые алгоритмически) - имеют смысл?
AV>> Внутри одной сессии - нет.
YM> А если брать не сессию, а шифрование собственно сообщений? Типа Вася
YM> сообщения Пете шифрует ключом А, а Петя Васе - ключом Б? Речь,
YM> естественно, о ключах симметричных алгоритмов.
Это обычно делается по-другому: к зашифрованному симметричным алгоритмом
сообщению прицепляется симметричный ключ, зашифрованный открытым ключом
получателя.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Если нет слов - не утруждай себя написанием букв
09 Mar 2015 20:13:42, ты -> мне:
YM>>> PS to All: нубский вопрос номер два: Разные ключи для приема и
YM>>> для отсылки (полностью независимые алгоритмически) - имеют смысл?
AV>> Внутри одной сессии - нет.
YM> сообщения Пете шифрует ключом А, а Петя Васе - ключом Б? Речь,
YM> естественно, о ключах симметричных алгоритмов.
Это обычно делается по-другому: к зашифрованному симметричным алгоритмом
сообщению прицепляется симметричный ключ, зашифрованный открытым ключом
получателя.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Yuri Myakotin
Mar 9, 2015, 1:45:02 PM3/9/15
to
Hello Alexey!
Monday March 09 2015 20:20, Alexey Vissarionov wrote to Yuri Myakotin:
YM>> А если брать не сессию, а шифрование собственно сообщений? Типа
YM>> Вася сообщения Пете шифрует ключом А, а Петя Васе - ключом Б?
YM>> Речь, естественно, о ключах симметричных алгоритмов.
AV> Это обычно делается по-другому: к зашифрованному симметричным
AV> алгоритмом сообщению прицепляется симметричный ключ, зашифрованный
AV> открытым ключом получателя.
И получаем итоговую стойкость, равную стойкости открытого ключа?
Я про другой вариант, пользователи А и Б договорились (неважно как, может
вручную, может так, как описано выше) о ключах и какое-то время шлют друг другу
сообщения, шифрованные ключем-хешом от сочетания постоянного ключа и разовой
"соли", передаваемой вместе с сообщением. Имеет смысл делать ключи А->Б и Б->А
разными?
Monday March 09 2015 20:20, Alexey Vissarionov wrote to Yuri Myakotin:
YM>> А если брать не сессию, а шифрование собственно сообщений? Типа
YM>> Речь, естественно, о ключах симметричных алгоритмов.
AV> Это обычно делается по-другому: к зашифрованному симметричным
AV> алгоритмом сообщению прицепляется симметричный ключ, зашифрованный
AV> открытым ключом получателя.
И получаем итоговую стойкость, равную стойкости открытого ключа?
Я про другой вариант, пользователи А и Б договорились (неважно как, может
вручную, может так, как описано выше) о ключах и какое-то время шлют друг другу
сообщения, шифрованные ключем-хешом от сочетания постоянного ключа и разовой
"соли", передаваемой вместе с сообщением. Имеет смысл делать ключи А->Б и Б->А
разными?
Serguei E. Leontiev
Mar 9, 2015, 3:35:35 PM3/9/15
to
> AV> Это обычно делается по-другому: к зашифрованному симметричным
> AV> алгоритмом сообщению прицепляется симметричный ключ, зашифрованный
> AV> открытым ключом получателя.
> И получаем итоговую стойкость, равную стойкости открытого ключа?
В принципе, не обязательно. Hапример, в IPsec IKEv1 в некоторых режимах,
> AV> алгоритмом сообщению прицепляется симметричный ключ, зашифрованный
> AV> открытым ключом получателя.
> И получаем итоговую стойкость, равную стойкости открытого ключа?
симметричный ключ "правильно" смешивался с ключом Диффи-Хелмана.
> Я про другой вариант, пользователи А и Б договорились (неважно как, может
> вручную, может так, как описано выше) о ключах и какое-то время шлют друг другу
> сообщения, шифрованные ключем-хешом от сочетания постоянного ключа и разовой
> "соли", передаваемой вместе с сообщением. Имеет смысл делать ключи А->Б и Б->А
> разными?
надёжнее отделять свои сообщения и сообщения от друга.
Serguei E. Leontiev
Mar 9, 2015, 3:35:36 PM3/9/15
to
Алексей, привет,
А в протоколе IPsec IKEv1, где сессионный ключ един на оба направления, при
некоторых условиях возможны атаки типа "отражения"?
ЭAlexey Vissarionov <Alexey.Vi...@f545.n5020.z2.fidonet.org> wrote:
>> PS to All: нубский вопрос номер два: Разные ключи для приема и для
>> PS to All: нубский вопрос номер два: Разные ключи для приема и для
>> отсылки (полностью независимые алгоритмически) - имеют смысл?
> Внутри одной сессии - нет.
Это ничего, что в протоколах TLS и IPsec ESP и IKEv2 они сделаны разными?
> Внутри одной сессии - нет.
А в протоколе IPsec IKEv1, где сессионный ключ един на оба направления, при
некоторых условиях возможны атаки типа "отражения"?
Serguei E. Leontiev
Mar 9, 2015, 3:58:37 PM3/9/15
to
>> Да и разные программы, бывает, передают в сеть
> SL> неинициализированные буфера.
> Hу, вот этого я избегаю :) даже если нужно добить сообщение до размера
> шифроблока - добивается рандомом же.
Ты, возможно, хотя ошибки делают все и всегда. А другие системные или
> SL> неинициализированные буфера.
> Hу, вот этого я избегаю :) даже если нужно добить сообщение до размера
> шифроблока - добивается рандомом же.
пользовательские программы?
>>> (Blake/Keccak) как "предварительный" этап с 512 бит на выходе, и
>>> третий (Skein) как окончательный, дающий на выходе нужную битность.
>>> Т.е. даже найденная дыра в одном из трех - не делает дырявой всю
>>> схему.
>> Или наоборот, дыра найденная в любом из них делает дырявой всю схему.
> 2 последовательных преобразования, одно из них дырявое, другое нет - как
> дырявость одного из них поможет узнать, что было на входе?
Hапример, размер области значений Hash1(Hash2(x)) равняется минимуму от
> 2 последовательных преобразования, одно из них дырявое, другое нет - как
> дырявость одного из них поможет узнать, что было на входе?
размеров области значений Hash1() и Hash2().
>>> Для генерации секретной части разовых сессионных ключей (Shared key
>>> получаю алгоритмом Curve25519) это было бы несколько неудобно
>>> (особенно на сервере, где все должно крутиться автономно).
>> И? Hеудобно? Hо тогда зачем всё? Если не нравится процедура
>> перезапуска сервера правильным администратором, вставь в него, хотя
>> бы, секретную флэшку.
> Собственно, в софте, который я сейчас делаю, на сервере вообще ничего
> секретного нет - шифрация трафика лишь мешает условному СОРМу отследить, кто
> именно кому именно шлет сообщение. А вот само сообщение перед отправкой
> шифруется уже гораздо более серьезно, без полностью автономной генерации
> ключей. И сервер этих ключей не видит и не имеет, они только у посылающего и
> адресата.
Какой-то ты неправильный параноик, если ничего секретного нет, то, как я
> Собственно, в софте, который я сейчас делаю, на сервере вообще ничего
> секретного нет - шифрация трафика лишь мешает условному СОРМу отследить, кто
> именно кому именно шлет сообщение. А вот само сообщение перед отправкой
> шифруется уже гораздо более серьезно, без полностью автономной генерации
> ключей. И сервер этих ключей не видит и не имеет, они только у посылающего и
> адресата.
писал выше, гораздо безопаснее использовать CryptGenRandom(). Если же
CryptGenRandom() кажется опасным, то единственным реальным улучшением может
быть только "правильное" подмешивание собственного секрета.
Serguei E. Leontiev
Mar 9, 2015, 4:07:08 PM3/9/15
to
Алексей, привет,
Alexey Vissarionov <Alexey.Vi...@f545.n5020.z2.fidonet.org> wrote:
>>> Использование алгоритмов, основанных на эллиптических кривых -
> Кем и как?
Если мне не изменяет память там изложено что-то типа такого:
...Для получения эллиптической точки такой-то возьмите случайное число,
вычислите от него хэш функцию, возьмите остаток от деления на p и назовите
x, y получите вычислением из x...
>> Или есть недоверие к наборам параметров, которые были получены
цивилизованные русские, я бы поставил бы на раздолбайство, к концу
многолетний исследований параметров ДСЧ просто потеряли исходные случайные
числа :)
Alexey Vissarionov <Alexey.Vi...@f545.n5020.z2.fidonet.org> wrote:
>>> Использование алгоритмов, основанных на эллиптических кривых -
>>> решение, мягко говоря, далекое от мудрости уже потому, что
>>> описать на заданном конечном поле кривую с нужными свойствами
>>> (обеспечивающими закладку) проще, чем исследовать предложенную
>>> кем-то другим (искать ту закладку).
>> У тебя есть обоснованное недоверие процедуре получения
>> подтверждаемых
> Кем и как?
Если мне не изменяет память там изложено что-то типа такого:
...Для получения эллиптической точки такой-то возьмите случайное число,
вычислите от него хэш функцию, возьмите остаток от деления на p и назовите
x, y получите вычислением из x...
>> Или есть недоверие к наборам параметров, которые были получены
>> в разрез с этой процедурой, таким как параметры по умолчанию в
>> алгоритме ДСЧ NIST SP 800-90A?
> Там вообще откровеннейшая закладка...
Всяко может быть, хотя, если бы это были не варвары ангосаксы, а
> Там вообще откровеннейшая закладка...
цивилизованные русские, я бы поставил бы на раздолбайство, к концу
многолетний исследований параметров ДСЧ просто потеряли исходные случайные
числа :)
Alexey Vissarionov
Mar 10, 2015, 8:25:02 AM3/10/15
to
Доброго времени суток, Yuri!
09 Mar 2015 20:31:08, ты -> мне:
YM>>> А если брать не сессию, а шифрование собственно сообщений? Типа
YM>>> Вася сообщения Пете шифрует ключом А, а Петя Васе - ключом Б?
YM>>> Речь, естественно, о ключах симметричных алгоритмов.
AV>> Это обычно делается по-другому: к зашифрованному симметричным
AV>> алгоритмом сообщению прицепляется симметричный ключ, зашифрованный
AV>> открытым ключом получателя.
YM> И получаем итоговую стойкость, равную стойкости открытого ключа?
Строго говоря, минимум от стойкости симметричного и асимметричного алгоритмов.
Алгоритмы с открытым ключом крайне медленные, и для больших объемов данных
малопригодны, а тут их применение сводится к относительно небольшому ключу
симметричного шифрования.
YM> Я про другой вариант, пользователи А и Б договорились (неважно как,
YM> может вручную, может так, как описано выше) о ключах и какое-то время
YM> шлют друг другу сообщения, шифрованные ключем-хешом от сочетания
YM> постоянного ключа и разовой "соли", передаваемой вместе с сообщением.
YM> Имеет смысл делать ключи А->Б и Б->А разными?
Иногда делают, но особого смысла нет. Оправдано разве что при генерации гаммы
для поточного шифрования...
На всякий случай: для генерации гаммы лучше использовать обратную связь по
шифротексту (CFB).
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Опыт и алкоголизм всегда победят молодость и энтузиазм
09 Mar 2015 20:31:08, ты -> мне:
YM>>> А если брать не сессию, а шифрование собственно сообщений? Типа
YM>>> Вася сообщения Пете шифрует ключом А, а Петя Васе - ключом Б?
YM>>> Речь, естественно, о ключах симметричных алгоритмов.
AV>> Это обычно делается по-другому: к зашифрованному симметричным
AV>> алгоритмом сообщению прицепляется симметричный ключ, зашифрованный
AV>> открытым ключом получателя.
Строго говоря, минимум от стойкости симметричного и асимметричного алгоритмов.
Алгоритмы с открытым ключом крайне медленные, и для больших объемов данных
малопригодны, а тут их применение сводится к относительно небольшому ключу
симметричного шифрования.
YM> Я про другой вариант, пользователи А и Б договорились (неважно как,
YM> может вручную, может так, как описано выше) о ключах и какое-то время
YM> шлют друг другу сообщения, шифрованные ключем-хешом от сочетания
YM> постоянного ключа и разовой "соли", передаваемой вместе с сообщением.
YM> Имеет смысл делать ключи А->Б и Б->А разными?
Иногда делают, но особого смысла нет. Оправдано разве что при генерации гаммы
для поточного шифрования...
На всякий случай: для генерации гаммы лучше использовать обратную связь по
шифротексту (CFB).
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Alexey Vissarionov
Mar 10, 2015, 8:25:02 AM3/10/15
to
Доброго времени суток, Serguei!
09 Mar 2015 22:35:34, ты -> мне:
>>> PS to All: нубский вопрос номер два: Разные ключи для приема и для
>>> отсылки (полностью независимые алгоритмически) - имеют смысл?
>> Внутри одной сессии - нет.
SL> Это ничего, что в протоколах TLS и IPsec ESP и IKEv2 они сделаны
SL> разными?
И сильно оно им помогло?
SL> А в протоколе IPsec IKEv1, где сессионный ключ един на оба
SL> направления, при некоторых условиях возможны атаки типа
SL> "отражения"?
s/при некоторых/в лабораторных/
Вот разные гаммы для поточного шифрования генерировать - таки да, оправдано.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Я мненью вашему вращенье придавал, и осью был мой размноженья орган
09 Mar 2015 22:35:34, ты -> мне:
>>> PS to All: нубский вопрос номер два: Разные ключи для приема и для
>>> отсылки (полностью независимые алгоритмически) - имеют смысл?
>> Внутри одной сессии - нет.
SL> разными?
И сильно оно им помогло?
SL> А в протоколе IPsec IKEv1, где сессионный ключ един на оба
SL> направления, при некоторых условиях возможны атаки типа
SL> "отражения"?
s/при некоторых/в лабораторных/
Вот разные гаммы для поточного шифрования генерировать - таки да, оправдано.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Alexey Vissarionov
Mar 10, 2015, 8:25:03 AM3/10/15
to
Доброго времени суток, Serguei!
09 Mar 2015 23:07:06, ты -> мне:
>>>> описать на заданном конечном поле кривую с нужными свойствами
>>>> (обеспечивающими закладку) проще, чем исследовать предложенную
>>>> кем-то другим (искать ту закладку).
>>> У тебя есть обоснованное недоверие процедуре получения
>>> подтверждаемых
>> Кем и как?
SL> Если мне не изменяет память там изложено что-то типа такого:
SL> ...Для получения эллиптической точки такой-то возьмите случайное
SL> число, вычислите от него хэш функцию, возьмите остаток от деления
SL> на p и назовите x, y получите вычислением из x...
Ну да, что-то такое... То есть, "делай так, как сказал Великий Мумба".
>>> Или есть недоверие к наборам параметров, которые были получены
>>> в разрез с этой процедурой, таким как параметры по умолчанию в
>>> алгоритме ДСЧ NIST SP 800-90A?
>> Там вообще откровеннейшая закладка...
SL> Всяко может быть, хотя, если бы это были не варвары ангосаксы, а
SL> цивилизованные русские, я бы поставил бы на раздолбайство, к концу
SL> многолетний исследований параметров ДСЧ просто потеряли исходные
SL> случайные числа :)
Эхотаг - одна из немногих областей, где правило Хенлона неприменимо.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Спирт легче воды, но из водки почему-то не всплывает
09 Mar 2015 23:07:06, ты -> мне:
>>>> описать на заданном конечном поле кривую с нужными свойствами
>>>> (обеспечивающими закладку) проще, чем исследовать предложенную
>>>> кем-то другим (искать ту закладку).
>>> У тебя есть обоснованное недоверие процедуре получения
>>> подтверждаемых
>> Кем и как?
SL> ...Для получения эллиптической точки такой-то возьмите случайное
SL> число, вычислите от него хэш функцию, возьмите остаток от деления
SL> на p и назовите x, y получите вычислением из x...
Ну да, что-то такое... То есть, "делай так, как сказал Великий Мумба".
>>> Или есть недоверие к наборам параметров, которые были получены
>>> в разрез с этой процедурой, таким как параметры по умолчанию в
>>> алгоритме ДСЧ NIST SP 800-90A?
>> Там вообще откровеннейшая закладка...
SL> цивилизованные русские, я бы поставил бы на раздолбайство, к концу
SL> многолетний исследований параметров ДСЧ просто потеряли исходные
SL> случайные числа :)
Эхотаг - одна из немногих областей, где правило Хенлона неприменимо.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
0 new messages