выбираем новый ГПСЧ в DiskCryptor
В новой версии DiskCryptor, в целях улучшения доверия, я хочу поменять ГПСЧ на какую-нибудь стандартную, хорошо изученную конструкцию.
Рассмотренные варианты:
1. AES_CTR_DRBG. Плюсы: простота, изученность. Минусы: DC помимо AES позволяет использовать Twofish, Serpent, а также каскады. Завязывание на AES увеличивает количество точек отказа при использовании альтернативных шифров.
2. HASH_DRBG на sha512, который уже используется в pkdbf2 разворачивании ключей, следовательно его использование в PRNG не увеличивает количество точек отказа.
3. HMAC_DRBG. ИМХО более безопасный вариант, имеющий запас прочности на случай взлома хэшей. HMAC уже есть в программе, есть резон его использовать.
4. Yarrow. Плюсы: изученность, используется в BSD. Минусы: использует sha1, лишняя точка отказа. Нет официальных тестовых векторов.
5. Fortuna. Плюсы: самая параноидальная конструкция. Минусы: громоздкий, требует два криптопримитива, нет тестовых векторов.
6. Keccak. Плюсы: самый современный (но плюс ли это?), продвинутый дизайн. Минусы: еще не стандарт, использование лишних криптопримитивов (новая точка отказа).
Итого: наиболее подходящим видится HMAC DRBG. Какие мысли будут у вас?
комментариев: 1079 документов: 58 редакций: 59
комментариев: 9796 документов: 488 редакций: 5664
1,2,3 — это, условно, одна группа. Хотя, 1 — можно выделить в отдельную, допустим, нулевую группу.
4,5 — другая.
6 — это особый случай, скажем так, который вообще не укладывается в традиционную классификацию.
Это неравноценные алгоритмы по областям применения. В каких-то конкретных случаях алгоритм из одной группы не может быть заменён алгоритмом из другой группы. Ну примерно, как молоток для невропатолога нельзя заменить кувалдой и наоборот, хотя формально они относятся к классу ударных инструментов.
Т.е., следует сначала с формальными моделями под свою конкретную задачу разобраться, считая, что все известные алгоритмы — равноценно-идеально стойкие.
P.S.:
стандарта NIST опубликован альтернативный метод выбора координат точек эллиптической кривой для Dual_EC_DRBG. В своё время также было с константами для DH и DSA.
В сентябрьской версии
Только часть формул в этом разделе почему-то закрыта белыми плашками (цензура?). Или потому, что это черновик такой?
комментариев: 371 документов: 19 редакций: 20
Задача – накопление энтропии из множества источников, каждый из которых по отдельности ненадежен, и генерация ключей для дискового шифрования.
Вот как сделано сейчас. Эта конструкция уже обсуждалась, но хочется заменить ее на аналогичную по свойствам, но пользующуюся доверием.
Варианты 1, 4 и 6 можно не рассматривать из-за увеличения количества используемых криптопримитивов, остается выбор между 2, 3 и 5, если кто-нибудь не предложит иное.
Криптопримитивы которые уже используются: SHA512, HMAC_SHA512, PBKDF2 (на HMAC_SHA512), Aes256, Twofish и Serpent, включая каскады.
комментариев: 9796 документов: 488 редакций: 5664
4 — устарел, есть какие-то атаки.
5 — теоретически плохо обоснован.
6 — пока интересная игрушка в будущих исследованиях для теоретиков.
Для задачи, которую вы хотите решить, надёжного протокола не разработано. Всё, что используется, будут менять.
Подробнее см.
Интересно, и много есть людей на свете, которые способы прочитать эти 30 страниц и всё понять? Там есть чётко формализованный алгоритм, понятный программистам и готовый для стандартизации? Ну, чтоб этот алгоритм мог
осилитьпонять человек без PhD в криптографии/CS за разумное время.Оно, кстати, уже упоминалось в предыдущих обсуждениях RNG.
комментариев: 9796 документов: 488 редакций: 5664
http://cr.yp.to/chacha.html
комментариев: 371 документов: 19 редакций: 20
Также, с добавлением чего-либо в загрузчик будут проблемы, там полностью исчерпан лимит доступной памяти, еще один шифр не влезет.
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 371 документов: 19 редакций: 20
Остановился на HMAC DRBG в качестве основы ГСЧ, этот примитив прост, стандартизован, имеет все нужные входы для подмешивания энтропии, и имеет стандартные тестовые вектора. Сам набор источников энтропии остается прежним, только добавлю поддержку rdrand.
З.Ы. забаньте троля пожалуйста.
комментариев: 11558 документов: 1036 редакций: 4116
комментариев: 9796 документов: 488 редакций: 5664
На аналог /dev/random (сбор и выдача энтропии с ОС) могут претендовать 4 и 5 — они специально для этого были разработаны.
6 — теоретически во множестве своих разновидностей м.б. использован для всего самого неожиданного, но это неизученная область.
комментариев: 371 документов: 19 редакций: 20
В NIST SP 800-90A сказано что от источника энтропии требуется уровень энтропии соответствующий требуемой безопасности, но в качестве входа DRBG разрешаются использовать более длинные, но менее случайные последовательности.
Итоговая конструкция мне видится так: в момент инициализации DRBG собираем пул энтропии, содержащий по минимальным оценкам, 256 случайных бит (статистически равномерное распределение неважно, т.к. пул хэшируется внутри DRBG). Затем, при каждом запросе на генерацию, собираем и добавляем дополнительную энтропию (DRBG имеет нужные входы). Также, в процессе работы собираем энтропию и как только набирается 256 бит (по минимальным оценкам), делаем reseeding DRBG (при reseeding внутреннее состояние не удаляется, новая энтропия добавляется к уже накопленной).
По фортуне:
Проблема, как реализовать фортуну так, чтобы она не смотрелась как инородное включение и не создавала лишних точек отказа. Возникает ряд вопросов:
1 – Можно ли менять хэш на произвольный? Авторская реализация использует sha1, он мне абсолютно ни к месту.
2 – Какой применять блочный шифр? Разделы могут шифроваться Aes, Thowish, Serpent и каскадами. Получается какой ни применяй, возникает лишняя точка уязвимости. Использовать в ГПСЧ именно тот блочный шифр который используется для конкретного раздела, это переусложнение и место для всяких неочевидных багов. Например если ГПСЧ используется для генерации ключевого файла, который будет ключом к разделу зашифрованному иным шифром, нежели применяемый в ГПСЧ, безопасность определяется наиболее слабым из этих двух шифров. HMAC DRBG в этом плане удобен тем что HMAC всегда используется для получения header key.
3 – Что насчет режимов шифрования? Я видел реализации где используется ECB и CBC, а у меня все реализации заточены под XTS. Городить же дополнительные ради одного ГПСЧ...
комментариев: 9796 документов: 488 редакций: 5664
По первой части. Если всё так просто, почему теоретики разрабатывают спецпротоколы под эту задачу? Даже когда придумывали /dev/random, нагородили что-то своё, но не взяли простой ГПСЧ, хотя конструкции, аналогичные 1,2,3 — лет двадцать как известны и являются самым первым и простым, что приходит в голову. У меня у самого нет чёткого понимания этого вопроса, только отдельные догадки.
Я не очень понимаю, вы всё-таки пытаетесь сделать общесистемный аналог /dev/random или доступ будет только у одного пользователя, как на чтение энтропии, так и на сбор данных для неё? Причём пользователь этот считается доверенным и изолированным? Или это работает на уровне ядра ОС, а читать энтропию (и частично, но естественно, не полностью, влиять на вход генератора) могут все пользователи, включая злонамеренных, но сами пользователи надёжно разделены и пытаются предсказать гамму друг друга только по распределяемой каждому персонально гамме? При том, что пользователи надёжно изолированы? Из-за этих тонкостей и возникает какие-то возможности для атак, когда одно приложение может собрать свою гамму и отправить куда, где проведут криптоанализ и попытаются восстановить другую гамму, получаемую другим приложением, но из этого же источника.
По второй части — все решения по трудностям с ресурсами для реализации — это ваш выбор. Ничего не могу посоветовать.
Представьте, что есть некий идеальный шифр и проблемы выбора пока нет. Что, в этой области всё остальное настолько понятно, что достаточно только взять и реализовать?
В стандарте на DRBG этот момент учитывается. При генерации рекомендуется включать идентификатор запрашивающего приложения в additional input.