выбираем новый ГПСЧ в 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. Какие мысли будут у вас?
Ссылки
[link1] http://csrc.nist.gov/publications/drafts/800-90/draft_sp800_90a_rev1.pdf
[link2] https://diskcryptor.net/wiki/RNG/ru
[link3] http://crypto.2013.rump.cr.yp.to/8b2da6d5dd33f1c1129df45fc0446d42.pdf
[link4] http://eprint.iacr.org/2013/338
[link5] http://www.pgpru.com/comment70136
[link6] http://www.pgpru.com/comment72612
[link7] http://forum.gkfx.ru/index.php/topic/369-холивар-на-пауке-сб-и-прочая-и-прочая/
[link8] https://en.wikipedia.org/wiki/Random_walk
[link9] https://en.wikipedia.org/wiki/Independent_and_identically_distributed_random_variables
Fortuna бери, что тут думать))Хотя конечно по реализации лучше HMAC DRBG, я про Фартуну сказал, исходя из того, что любое устройство может сореждать бекдор и поэтому должно использоваться один раз в совокупности с другими как источник энтропии. Кстати, под Linux планируется версия?
1,2,3 — это, условно, одна группа. Хотя, 1 — можно выделить в отдельную, допустим, нулевую группу.
4,5 — другая.
6 — это особый случай, скажем так, который вообще не укладывается в традиционную классификацию.
Это неравноценные алгоритмы по областям применения. В каких-то конкретных случаях алгоритм из одной группы не может быть заменён алгоритмом из другой группы. Ну примерно, как молоток для невропатолога нельзя заменить кувалдой и наоборот, хотя формально они относятся к классу ударных инструментов.
Т.е., следует сначала с формальными моделями под свою конкретную задачу разобраться, считая, что все известные алгоритмы — равноценно-идеально стойкие.
P.S.:
В сентябрьской версии стандарта NIST[link1] опубликован альтернативный метод выбора координат точек эллиптической кривой для Dual_EC_DRBG. В своё время также было с константами для DH и DSA.
Только часть формул в этом разделе почему-то закрыта белыми плашками (цензура?). Или потому, что это черновик такой?
Задача – накопление энтропии из множества источников, каждый из которых по отдельности ненадежен, и генерация ключей для дискового шифрования.
Вот как сделано сейчас[link2]. Эта конструкция уже обсуждалась, но хочется заменить ее на аналогичную по свойствам, но пользующуюся доверием.
Варианты 1, 4 и 6 можно не рассматривать из-за увеличения количества используемых криптопримитивов, остается выбор между 2, 3 и 5, если кто-нибудь не предложит иное.
Криптопримитивы которые уже используются: SHA512, HMAC_SHA512, PBKDF2 (на HMAC_SHA512), Aes256, Twofish и Serpent, включая каскады.
1,2,3 — строго говоря, не являются инструментами для вашей задачи, а могут быть только кирпичиками для создания протокола.
4 — устарел, есть какие-то атаки.
5 — теоретически плохо обоснован.
6 — пока интересная игрушка в будущих исследованиях для теоретиков.
Для задачи, которую вы хотите решить, надёжного протокола не разработано. Всё, что используется, будут менять.
Подробнее см. здесь[link3] и здесь[link4].
Интересно, и много есть людей на свете, которые способы прочитать эти 30 страниц и всё понять? Там есть чётко формализованный алгоритм, понятный программистам и готовый для стандартизации? Ну, чтоб этот алгоритм мог
осилитьпонять человек без PhD в криптографии/CS за разумное время.Оно, кстати, уже упоминалось в предыдущих[link5] обсуждениях[link6] RNG.
Вот мы и имеем то, что используется в OpenSSL и текущем /dev/random.
Простите за оффтоп. Можно ли добавить еще один алгоритм шифрования Chacha?
http://cr.yp.to/chacha.html
Это поточный шифр, он не подходит для дискового шифрования. Для режима XTS требуется блочный шифр с 128 битным блоком.
Также, с добавлением чего-либо в загрузчик будут проблемы, там полностью исчерпан лимит доступной памяти, еще один шифр не влезет.
По поводу изначального вопроса. Для сбора системной энтропии, поскольку вменяемых проверенных и изученных конструкций нет, то скорее только Fortuna. Хотя, её тоже назвать хорошо проверенной и изученной сложно. Шнайер с соавторами её распиарил через одну свою популярную книжку, не помню, был ли у него солидный набор работ и доклады на конференциях хотя бы. Надежд на её массовый сторонний анализ особо нет, теоретиков интересуют более легковесные конструкции.
Fortuna смущает тем что авторская реализация не содержит в себе стандарта, завязана на sha1/aes и нет тестовых векторов (как иначе доказать что реализация правильная?).
Остановился на HMAC DRBG в качестве основы ГСЧ, этот примитив прост, стандартизован, имеет все нужные входы для подмешивания энтропии, и имеет стандартные тестовые вектора. Сам набор источников энтропии остается прежним, только добавлю поддержку rdrand.
З.Ы. забаньте троля пожалуйста.
Просто не обращайте внимания.
1, 2, 3 — предназначены для сбора энтропии с одного источника. Скорее, для отбеливания шума с физического RNG, с опциональной возможностью растягивания в псевдослучайную строку при нехватке потока энтропии.
На аналог /dev/random (сбор и выдача энтропии с ОС) могут претендовать 4 и 5 — они специально для этого были разработаны.
6 — теоретически во множестве своих разновидностей м.б. использован для всего самого неожиданного, но это неизученная область.
В 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. Городить же дополнительные ради одного ГПСЧ...
По первой части. Если всё так просто, почему теоретики разрабатывают спецпротоколы под эту задачу? Даже когда придумывали /dev/random, нагородили что-то своё, но не взяли простой ГПСЧ, хотя конструкции, аналогичные 1,2,3 — лет двадцать как известны и являются самым первым и простым, что приходит в голову. У меня у самого нет чёткого понимания этого вопроса, только отдельные догадки.
Я не очень понимаю, вы всё-таки пытаетесь сделать общесистемный аналог /dev/random или доступ будет только у одного пользователя, как на чтение энтропии, так и на сбор данных для неё? Причём пользователь этот считается доверенным и изолированным? Или это работает на уровне ядра ОС, а читать энтропию (и частично, но естественно, не полностью, влиять на вход генератора) могут все пользователи, включая злонамеренных, но сами пользователи надёжно разделены и пытаются предсказать гамму друг друга только по распределяемой каждому персонально гамме? При том, что пользователи надёжно изолированы? Из-за этих тонкостей и возникает какие-то возможности для атак, когда одно приложение может собрать свою гамму и отправить куда, где проведут криптоанализ и попытаются восстановить другую гамму, получаемую другим приложением, но из этого же источника.
По второй части — все решения по трудностям с ресурсами для реализации — это ваш выбор. Ничего не могу посоветовать.
Представьте, что есть некий идеальный шифр и проблемы выбора пока нет. Что, в этой области всё остальное настолько понятно, что достаточно только взять и реализовать?
Общесистемный ГПСЧ в Windows уже есть, закрытый и неизвестного качества. Я пытаюсь сделать ГПСЧ для одной программы. Доступ на чтение будет у всех пользователей с правами администратора (они могут скомпрометировать любое шифрование, просто модифицировав загруженный в память код). Сбор энтропии – независимый от пользователя, из системных событий, на часть из которых могут повлиять пользователи с низкими правами.
В стандарте на DRBG этот момент учитывается. При генерации рекомендуется включать идентификатор запрашивающего приложения в additional input.
Тогда выбор из стандарта м.б. приемлемым за неимением реальной лучшей альтернативы. Опять же, даже всевозможные широкораспространённые SSL, VPN и пр. не всегда могут служить образцом в этом деле. Если считать стандарт неидеальным, то в реальных, даже известных программах, всё может быть реализовано условно хуже. /dev/random — тоже объект критики исследователей.
Финансисты работают[link7] с рядами ГПСЧ и утверждают, что могут прогнозировать их. Может ли подобный анализ быть рассмотрен как своего рода атака на код с применением ГПСЧ?
Если для какого-то ГПСЧ криптоаналитики не могут найти различитель, то никто не может прогнозировать его ни в малейшей мере. А форекс это разводка для лохов, на форукс курсах вам что угодно расскажут.
ГПСЧ, который они использовали для построения моделей, может быть некриптостойким. Модель рынка, которую они нагородили из ГПСЧ, может оказаться неслучайной — так же как из криптостойких криптопримитивов можно создать нестойкий протокол (имеющий различитель). Может быть ещё миллион причин, указывающих на то, что их аналитические изыскания не имеют никакого отношения к криптографии.
Не знаю, что там подразумевается под ГПСЧ (при поверхностном чтении ничего про ГПСЧ там не увидел), но поведение рынка обычно описывается случайными блужданиями[link8], которые есть вроде как тип марковского процесса. Именно из-за этого кривые выглядят хоть и ломаными, но грубо аппроксимируемыми какими-то интерполянтами (в полностью случайном процессе значения бы скакали на каждом шаге на произвольную величину, и аппроксимация стала бы бессмысленной).
Произвольный случайный процесс, в общем случае, конечно же немарковский, поэтому все эти модели прогнозов на нём не сработают. Т.е. нужно отличать случайность в рамках модели от случайности самой модели. Например, монетка со смещённым распределением (орёл выпадает чаще, чем решка) может быть совершенно случайной и непрогнозируемой в рамках своей модели, но наличие какой-то конкретной модели уже вносит некоторую конкретику, поэтому угадать выпадание смещённой монетки на практике проще, чем несмещённой (хотя полностью случайны как та, так и эта).
Ещё можно так пояснить: в теории вероятности полностью случайным называют то, что принципиально нельзя описать точнее, чем задав вероятности выборок из пространства событий (это подразумевает любые возможные типы распределений для случайной величины). А в криптографии полностью случайным называют конкретное распределение — i.i.d[link9] (независимые одинаково распределённые случайные величины).