выбираем новый ГПСЧ в DiskCryptor

1,2,3 — это, условно, одна группа. Хотя, 1 — можно выделить в отдельную, допустим, нулевую группу.
4,5 — другая.
6 — это особый случай, скажем так, который вообще не укладывается в традиционную классификацию.

Это неравноценные алгоритмы по областям применения. В каких-то конкретных случаях алгоритм из одной группы не может быть заменён алгоритмом из другой группы. Ну примерно, как молоток для невропатолога нельзя заменить кувалдой и наоборот, хотя формально они относятся к классу ударных инструментов.

Т.е., следует сначала с формальными моделями под свою конкретную задачу разобраться, считая, что все известные алгоритмы — равноценно-идеально стойкие.

P.S.:
В сентябрьской версии стандарта NIST опубликован альтернативный метод выбора координат точек эллиптической кривой для Dual_EC_DRBG. В своё время также было с константами для DH и DSA.

Только часть формул в этом разделе почему-то закрыта белыми плашками (цензура?). Или потому, что это черновик такой?

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

Вот как сделано сейчас. Эта конструкция уже обсуждалась, но хочется заменить ее на аналогичную по свойствам, но пользующуюся доверием.
Варианты 1, 4 и 6 можно не рассматривать из-за увеличения количества используемых криптопримитивов, остается выбор между 2, 3 и 5, если кто-нибудь не предложит иное.

Криптопримитивы которые уже используются: SHA512, HMAC_SHA512, PBKDF2 (на HMAC_SHA512), Aes256, Twofish и Serpent, включая каскады.

забаньте троля пожалуйста

1, 2, 3 — предназначены для сбора энтропии с одного источника

В NIST SP 800-90A сказано что от источника энтропии требуется уровень энтропии соответствующий требуемой безопасности, но в качестве входа DRBG разрешаются использовать более длинные, но менее случайные последовательности.

Ideally, the entropy input will have full entropy; however, the DRBG mechanisms have been specified to allow for some bias in the entropy input by allowing the length of the entropy input to be longer than the required amount of entropy (expressed in bits). The entropy input can be defined to be a variable length (within limits), as well as fixed length. In all cases, the DRBG mechanism expects that when entropy input is requested, the returned bitstring will contain at least the requested amount of entropy. Additional entropy beyond the amount requested is not required, but is desirable.
Итоговая конструкция мне видится так: в момент инициализации DRBG собираем пул энтропии, содержащий по минимальным оценкам, 256 случайных бит (статистически равномерное распределение неважно, т.к. пул хэшируется внутри DRBG). Затем, при каждом запросе на генерацию, собираем и добавляем дополнительную энтропию (DRBG имеет нужные входы). Также, в процессе работы собираем энтропию и как только набирается 256 бит (по минимальным оценкам), делаем reseeding DRBG (при reseeding внутреннее состояние не удаляется, новая энтропия добавляется к уже накопленной).

По фортуне:
Проблема, как реализовать фортуну так, чтобы она не смотрелась как инородное включение и не создавала лишних точек отказа. Возникает ряд вопросов:
1 – Можно ли менять хэш на произвольный? Авторская реализация использует sha1, он мне абсолютно ни к месту.
2 – Какой применять блочный шифр? Разделы могут шифроваться Aes, Thowish, Serpent и каскадами. Получается какой ни применяй, возникает лишняя точка уязвимости. Использовать в ГПСЧ именно тот блочный шифр который используется для конкретного раздела, это переусложнение и место для всяких неочевидных багов. Например если ГПСЧ используется для генерации ключевого файла, который будет ключом к разделу зашифрованному иным шифром, нежели применяемый в ГПСЧ, безопасность определяется наиболее слабым из этих двух шифров. HMAC DRBG в этом плане удобен тем что HMAC всегда используется для получения header key.
3 – Что насчет режимов шифрования? Я видел реализации где используется ECB и CBC, а у меня все реализации заточены под XTS. Городить же дополнительные ради одного ГПСЧ...

По первой части. Если всё так просто, почему теоретики разрабатывают спецпротоколы под эту задачу? Даже когда придумывали /dev/random, нагородили что-то своё, но не взяли простой ГПСЧ, хотя конструкции, аналогичные 1,2,3 — лет двадцать как известны и являются самым первым и простым, что приходит в голову. У меня у самого нет чёткого понимания этого вопроса, только отдельные догадки.

Я не очень понимаю, вы всё-таки пытаетесь сделать общесистемный аналог /dev/random или доступ будет только у одного пользователя, как на чтение энтропии, так и на сбор данных для неё? Причём пользователь этот считается доверенным и изолированным? Или это работает на уровне ядра ОС, а читать энтропию (и частично, но естественно, не полностью, влиять на вход генератора) могут все пользователи, включая злонамеренных, но сами пользователи надёжно разделены и пытаются предсказать гамму друг друга только по распределяемой каждому персонально гамме? При том, что пользователи надёжно изолированы? Из-за этих тонкостей и возникает какие-то возможности для атак, когда одно приложение может собрать свою гамму и отправить куда, где проведут криптоанализ и попытаются восстановить другую гамму, получаемую другим приложением, но из этого же источника.

По второй части — все решения по трудностям с ресурсами для реализации — это ваш выбор. Ничего не могу посоветовать.

Представьте, что есть некий идеальный шифр и проблемы выбора пока нет. Что, в этой области всё остальное настолько понятно, что достаточно только взять и реализовать?

Я не очень понимаю, вы всё-таки пытаетесь сделать общесистемный аналог /dev/random или доступ будет только у одного пользователя, как на чтение энтропии, так и на сбор данных для неё?

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