оцените PRNG

Впринципе для данного применения без разницы какой хеш использовать. Но если sha512 будет выглядеть круче и вызывать больше доверия, то использую его. Всеравно этот PRNG не нуждается в особой производительности, а значит можно себе позволить перестраховаться.
Из других изменений я планирую делать rnd_reseed_now два раза: перед генерацией числа и после нее, и при чтении каждых 64х байт (размер sha512 хеша) брать хеш не от части, а от всего пула. Это должно дать зависимость каждого выходного байта от всего пула в целом, хотя и медленее по скорости.
Может кто-то назовет такие изменения лишними, но я хочу получить максимальный запас по стойкости, чтобы в этом ни у кого не возникало сомнения.

Из других изменений я планирую делать rnd_reseed_now два раза: перед генерацией числа и после нее, и при чтении каждых 64х байт (размер sha512 хеша) брать хеш не от части, а от всего пула.

Мне это нравится. Лишним это не будет.

Всеравно этот PRNG не нуждается в особой производительности, а значит можно себе позволить перестраховаться.

И это правильно. Лучше перебдеть, чем недобдеть! :) Экономить лучше на дорогих вещах, а из недорогих брать лучшие!

http://freed0m.org/prng.c обновлен с учетом вышеуказаных изменений.

KeQuerySystemTime(&seed.seed20);
KeQueryTickCount(&seed.seed21);

Стоящие рядом, эти вызовы выдают сильно коррелирующие значения. Если между ними будут другие операторы с непостоянным временем исполнения (например один из этих вызовов можно поставить в начало процедуры) корреляция может слегка уменьшится.

Извините за неконструктивную критику, но... может чтение литературы по генераторам располагаем к пессимизму, т.к. эта теория до сих пор толком не проработана.

Вообще, чтобы оценить стойкость генератора, нужно написать работу наподобие этой.

А чтобы спроектировать генератор, нужно впервую очередь опять писать такого вида теоретическую работу и лишь в конце код для примера.

Не думаю, что среди пишущих в форум есть специалист такого уровня, который ещё и захочет этим заняться.

А на уровне общих знаний, интуитивно-эмпирическим путём, по принципу, "чтобы выглядело похоже" – это любительство.

Или придётся найти и использовать готовый стандарт, не внося никаких изменений, положившись на честность и компетентность разработчиков, для чего стандарты и делаются.

Предлагаете доверять таким стандартам? Нет уж, спасибо, лучше я буду доверять свойствам известных криптоптимитивов и собственному здравому смыслу.
В моем случае предсказаные следующего выхода PRNG по предыдущему сводиться к нахождению коллизии хеша sha512 и угадыванию случайности вносимой двумя вызовами rnd_reseed_now, которые вносят по минимуму 136 случайных бит, а по максимуму в 2-3 раза больше. Более того, дело осложняется добавлением к хешу длины сообщения, инвертированием и перемешиванием пула. Как вы думетете, реально?

В крайнем случае можно использовать параллельно два prng. Какой нибудь стандарт и эту реализацию. Хуже от этого не будет, но я считаю это уже написанием лишнего кода.

чтобы спроектировать генератор

Надо учесть, что обычно в таких случаях заботятся о производительности, откуда и трудности. Тут же эффективность не критична.

инвертированием и перемешиванием пула.

Может лучше ещё в добавок зашифровать его разок-другой с помощью AES256? И кода много писать не надо :)

можно использовать параллельно два prng

Или последовательно. А можно сделать одним из seed'ов. Или поXORить.

Вот, например Cryptographically Secure Random number on Windows without using CryptoAPI

Может лучше ещё в добавок зашифровать его разок-другой с помощью AES256? И кода много писать не надо :)

можно использовать параллельно два prng

Или последовательно. А можно сделать одним из seed'ов. Или поXORить.

Если б не упоминание AES, то можно было бы подумать, что это рассуждения в духе хакеров-шифрпанков начала 90-хх :-)

Разработка /dev/{u}random для Linux тоже велась по принципу: давайте наворотим что-нибудь посложнее, это не спасло его от нестойкости.

Просто этим же израильским криптографам пришлось поплеваться пока восстанавливали алгоритм работы из открытого кода и пытались его формализовать "reverse engeneering of open source code", но в итоге они доказали, что сложные навороты только ослабили стойкость.

Кстати, в их же работах указано, что частый reseed даёт нежелательные корреляции и уменьшает эффективную энтропию.

Дада, несомненно математически "чистый" PRNG на асимметрике с бекдором от NSA это хорошо. А "грязные" PRNG на хешах это плохо и недостойно высокой академической науки, хоть вздомать их никто еще не удосужился.
Собственно даже простейшая констркуция R = H(seed + counter) уже упирается в стойкость хеша H...

Собственно учтите, что из этого PRNG за раз читаются маленькие ключи шифрования, а не гигабайты данных. Гигабаты из него будет при всем желании прочитать затруднительно, ввиду очень невысокой производительности rnd_get_bytes.

А "грязные" PRNG на хешах это плохо и недостойно высокой академической науки, хоть вздомать их никто еще не удосужился.
Собственно даже простейшая констркуция R = H(seed + counter) уже упирается в стойкость хеша H...

В том же документе NIST, где был Dual_EC_DRBG с закладкой, остальные устроены как раз и на хэшах и на блочных шифрах. Там даже физические генераторы описаны.

Но даже простейшие конструкции вида R = H(seed + counter) вполне себе удостаиваются внимания "высокой академической науки" в многостраничных трудах и для них тоже расписывают трёхэтажные формулы. Наверное чтобы побольше извести бумаги для принтеров :-)

Собственно учтите, что из этого PRNG за раз читаются маленькие ключи шифрования, а не гигабайты данных.

И что, на это вся надежда? Допустим, были сгенерированы два ключа для разных приложений в очень короткий промежуток времени. (например захотите сделать основной и вложенный контейнеры). Один ключ противник узнал (неважно откуда), сможет ли он узнать другой ключ? Пусть эффективная энтропия пула очень мала (опять же неважно сколько источников системных событий туда напихать, важен принцип), у противника есть модель быстрого предсказания исходных значений пула, а с учётом небольшой разности времени двух генераций, энтропия будет ещё меньше.

Кто сможет точно описать модель Вашего генератора, если не в цифрах, то в буквах (при эффективной энтропии пула \epsilon в рамках модели \alpha затраты противника будут стремиться к \omega)?

с бекдором от NSA

Кто нибудь может сказать, откуда берутся константы в той же SHA?
Может стоит модифицировать эти константы (тем же SHA), и применять модифицированную SHA вместе с оригинальной исходя из гипотезы, что одна из них окажется надёжной?

придётся найти и использовать готовый стандарт

Чего посоветуете? И какое у вас мнение о генераторе из майкрософтовского CryptoAPI?

Дада, несомненно математически "чистый" PRNG на асимметрике с бекдором от NSA это хорошо.

Конечно хорошо :-) Для NSA. Для организаций своей страны им нужны стойкие алгоритмы. Но с закладкой для своих же. Чтобы врагам не достались :-)

Конечно можно, но имхо не стоит того. Тем более что я практически на 100% уверен, что модифицируя криптопримитивы сделаю только хуже.

Пока я его кода не видел, мое мнение сводиться к тому, что CryptoAPI лучше чем ничего. Но не более того. Сегодня подниму исходники windows, и если среди них удасться найти нужную часть, то выскажу более подробное мнение.

Кто нибудь может сказать, откуда берутся константы в той же SHA?

Оттуда же... Константы к SHA-1, наверное были придуманы в самом NSA.

SHA-256 использует в качестве констант 32-битные слова, полученные извлечением кубического корня из первых 64 простых чисел.
SHA-384 и SHA-512 используют для получения констант тот же метод, только более длинный ряд простых чисел и 64-битные слова.

А чем не нравятся Hash_DRBG, HMAC_DRBG и CTR_DRBG из того же документа NIST?