построены на основе уже существующих криптографических примитивов, что принято считать плюсом. Один на основе хеш-функций, другой на основе HMAC (хешированного кода аутентификации сообщения), третий на основе блочных шифров, четвертый - на эллиптических кривых. С последним, правда, вышел конфуз по целому ряду причин. В отличие от трех первых, где примитивы уже хорошо изучены и проверены криптографическим сообществом, его схема была предложена совсем недавно, около года назад, Агентством национальной безопасности США. Алгоритм, по независимым оценкам, ничем хорошим не отличается, имеет мутную и не разъясненную разработчиком конструкцию и работает гораздо медленнее остальных трех. Да еще и несет в себе, как уже установлено, явные признаки математической закладки, с помощью секретных констант позволяющей взламывать генератор на лету.
Зачем в стандарты NIST включен столь сомнительный 'подарок', в общем-то, понятно. Но не факт, что хоть кто-то захочет по доброй воле им воспользоваться.
Этот генератор тоже построен на основе RC4. И коль скоро всякий приличный поточный шифр дает на выходе последовательность чисел, статистически неотличимую от равновероятной, то и генератор на его основе вполне отвечает требованию (1). Но вот дальше начинаются очень неприятные моменты конкретной реализации PRNG. Чтобы обеспечить свойство (2) - не допустить восстановление прошлых состояний, - в качестве тактов генерации принято использовать однонаправленные (хеш-)функции, легко вычисляемые только в одну сторону. В Windows же обратная функция вычисляется столь же просто, как и прямая генерация следующего состояния.
Такая же унылая картина и для свойства (3). Дабы воспрепятствовать восстановлению будущих состояний криптогенератора, используют так называемую рандомизацию - то есть обновление состояний случайно взятой последовательностью бит от какого-нибудь внешнего источника. Чем короче расстояние между такими 'перезагрузками', тем выше криптостойкость генератора. Хотя общая схема PRNG в Windows не менялась, в ранних версиях OC длина между перезагрузками состояний составляла 512 байт, а в Win2000, как установили израильтяне, она выросла до 16 килобайт. Если же учесть, что PRNG здесь реализован на основе восьми потоков от работающих в параллели шифров RC4, то получается, что реально длина генерируемой криптопоследовательности между перезагрузками состояний составляет 128 килобайт.
Поэтому, определив всего одно внутреннее состояние генератора (например, с помощью известного трюка с переполнением буфера памяти), злоумышленник может вычислить огромное количество ключей - как уже использованных, так и на будущее. Хуже того, перезагрузка состояний произойдет лишь в том случае, когда все эти 128 килобайт сгенерированы между включением и выключением компьютера. В терминах защищенных SSL-соединений веб-браузера это, огрубленно, означает от 600 до 1200 сеансов шифрованной связи. Понятно, что для обычного компьютера это нереально огромное число. Иными словами, в большинстве случаев криптогенератор вообще не перезагружает свои состояния, так что всего одной 'израильской атакой' можно восстановить, по сути, ВСЕ генерируемые им ключи, как вперед, так и назад.
В терминах корпорации Microsoft, напомним, этот мелкий недочет в конструкции не тянет даже на то, чтобы именоваться 'уязвимостью'. В терминах же криптографии это называется катастрофическим снижением стойкости, которое не могло появиться случайно.
