Привет Юрий,
От 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 и
прочие возможные ошибки кодирования.
--
Успехов, Сергей Леонтьев. E-mail: ***@CryptoPro.ru