id: Гость   вход   регистрация
текущее время 19:38 23/07/2019
Автор темы: ntldr, тема открыта 12/12/2013 12:27 Печать
Категории: софт, diskcryptor
http://www.pgpru.com/Форум/Криптография/ВыбираемНовыйГПСЧВDiskCryptor
создать
просмотр
ссылки

выбираем новый ГПСЧ в 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. Какие мысли будут у вас?


 
На страницу: 1, 2 След.
Комментарии
— ressa (12/12/2013 13:44)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59
Fortuna бери, что тут думать))Хотя конечно по реализации лучше HMAC DRBG, я про Фартуну сказал, исходя из того, что любое устройство может сореждать бекдор и поэтому должно использоваться один раз в совокупности с другими как источник энтропии. Кстати, под Linux планируется версия?
— unknown (12/12/2013 14:24, исправлен 12/12/2013 14:49)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


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


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


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


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

— ntldr (12/12/2013 15:11, исправлен 12/12/2013 15:14)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20

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


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


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

— unknown (12/12/2013 15:39)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
1,2,3 — строго говоря, не являются инструментами для вашей задачи, а могут быть только кирпичиками для создания протокола.
4 — устарел, есть какие-то атаки.
5 — теоретически плохо обоснован.
6 — пока интересная игрушка в будущих исследованиях для теоретиков.

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

Подробнее см. fileздесь и здесь.
— Гость (13/12/2013 07:51)   <#>

Интересно, и много есть людей на свете, которые способы прочитать эти 30 страниц и всё понять? Там есть чётко формализованный алгоритм, понятный программистам и готовый для стандартизации? Ну, чтоб этот алгоритм мог осилить понять человек без PhD в криптографии/CS за разумное время.


Оно, кстати, уже упоминалось в предыдущих обсуждениях RNG.
— unknown (13/12/2013 09:48)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Вот мы и имеем то, что используется в OpenSSL и текущем /dev/random.
— Гость (16/12/2013 10:08)   <#>
Простите за оффтоп. Можно ли добавить еще один алгоритм шифрования Chacha?
http://cr.yp.to/chacha.html
— ntldr (16/12/2013 10:28)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Это поточный шифр, он не подходит для дискового шифрования. Для режима XTS требуется блочный шифр с 128 битным блоком.
Также, с добавлением чего-либо в загрузчик будут проблемы, там полностью исчерпан лимит доступной памяти, еще один шифр не влезет.
— unknown (16/12/2013 11:24)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
По поводу изначального вопроса. Для сбора системной энтропии, поскольку вменяемых проверенных и изученных конструкций нет, то скорее только Fortuna. Хотя, её тоже назвать хорошо проверенной и изученной сложно. Шнайер с соавторами её распиарил через одну свою популярную книжку, не помню, был ли у него солидный набор работ и доклады на конференциях хотя бы. Надежд на её массовый сторонний анализ особо нет, теоретиков интересуют более легковесные конструкции.
— ntldr (16/12/2013 11:47)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Fortuna смущает тем что авторская реализация не содержит в себе стандарта, завязана на sha1/aes и нет тестовых векторов (как иначе доказать что реализация правильная?).
Остановился на HMAC DRBG в качестве основы ГСЧ, этот примитив прост, стандартизован, имеет все нужные входы для подмешивания энтропии, и имеет стандартные тестовые вектора. Сам набор источников энтропии остается прежним, только добавлю поддержку rdrand.

З.Ы. забаньте троля пожалуйста.
— SATtva (16/12/2013 11:49)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4088
забаньте троля пожалуйста
Просто не обращайте внимания.
— unknown (16/12/2013 12:08)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
1, 2, 3 — предназначены для сбора энтропии с одного источника. Скорее, для отбеливания шума с физического RNG, с опциональной возможностью растягивания в псевдослучайную строку при нехватке потока энтропии.

На аналог /dev/random (сбор и выдача энтропии с ОС) могут претендовать 4 и 5 — они специально для этого были разработаны.

6 — теоретически во множестве своих разновидностей м.б. использован для всего самого неожиданного, но это неизученная область.
— ntldr (16/12/2013 13:08, исправлен 16/12/2013 13:13)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
1, 2, 3 — предназначены для сбора энтропии с одного источника

В 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. Городить же дополнительные ради одного ГПСЧ...

— unknown (16/12/2013 14:18, исправлен 16/12/2013 14:21)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


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


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



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

— Гость (16/12/2013 14:58)   <#>
Я не очень понимаю, вы всё-таки пытаетесь сделать общесистемный аналог /dev/random или доступ будет только у одного пользователя, как на чтение энтропии, так и на сбор данных для неё?
Общесистемный ГПСЧ в Windows уже есть, закрытый и неизвестного качества. Я пытаюсь сделать ГПСЧ для одной программы. Доступ на чтение будет у всех пользователей с правами администратора (они могут скомпрометировать любое шифрование, просто модифицировав загруженный в память код). Сбор энтропии – независимый от пользователя, из системных событий, на часть из которых могут повлиять пользователи с низкими правами.

Из-за этих тонкостей и возникает какие-то возможности для атак, когда одно приложение может собрать свою гамму и отправить куда, где проведут криптоанализ и попытаются восстановить другую гамму, получаемую другим приложением, но из этого же источника.
В стандарте на DRBG этот момент учитывается. При генерации рекомендуется включать идентификатор запрашивающего приложения в additional input.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3