id: Гость   вход   регистрация
текущее время 22:49 28/03/2024
Автор темы: Paran0ik, тема открыта 13/02/2010 15:38 Печать
Категории: криптография, случайные числа
создать
просмотр
ссылки

длина ключа


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


 
Комментарии
— SATtva (13/02/2010 15:46)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Может быть лучше что-нибудь в консерватории в ГСЧ подправить?
— Paran0ik (13/02/2010 16:03)   профиль/связь   <#>
комментариев: 88   документов: 13   редакций: 3
ну каким бы ни был хорошим генератор и как его не правь – он все равно будет генерировать псевдослучайные числа..
— unknown (13/02/2010 17:20)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Во-первых нарушен принцип доказуемой безопасности — стремиться впервую сделать/выбрать исходные идеальные компоненты криптопротокола и только в последнюю очередь исправлять криптопротоколом дырки в самих компонентах. Здесь это как раз тот случай, когда этот принцип нарушать не имеет смысла, о чём выше сказал SATtva.

Во-вторых — во что засунуть > 256-битовый ключ? Во что-то отличное от AES? В каскад? Во что-то ещё более нестандартное? Это будет обоснованный выбор?

Ну и в третьих:

Возьмём достаточно сильное и общее определение нестойкости Г(П) СЧ — на практике обычно используется что-то комбинированное — из ГСЧ берётся зерно для разворачиваемой с помощью ГПСЧ гаммы.

Допустим если Г(П) СЧ нестоек, то для получение гаммы выхода практически любой длины n достаточно провести атаку, которая требует < 2256 вычислений, доступных противнику образцов исходных данных или образцов доступных фрагментов гаммы с выхода ГПСЧ.

Вполне можно предположить, что при такой атаке противнику не составит труда вычислить гамму размером хоть n, хоть 2n или больше, хотя и возможно, что более длинные гаммы вычислить труднее, но если внутреннее состояние ГПСЧ вскрыто полностью, то длина разворачиваемой гаммы, которую может вычислить противник, может быть достаточно большой.

Т.е. может существовать (что неудивительно) атака, которая нарушает протокол, противоречащий принципам доказуемой безопасности. Или собирайте весь протокол из идеальных компонентов или доказывайте, что компенсация неидеальности компонента неизбежна и жизненно необходима (а здесь это заведомо не тот случай) и полна (а пример гипотетической атаки показывает, что в данном случае — нет).
— Paran0ik (14/02/2010 15:12)   профиль/связь   <#>
комментариев: 88   документов: 13   редакций: 3
стремиться впервую сделать/выбрать исходные идеальные компоненты криптопротокола и только в последнюю очередь исправлять криптопротоколом дырки в самих компонентах.

к примеру я ничего не делаю и не исправляю, я беру готовый продукт и пользуюсь им. при этом остается надеяться на компетентность автора программы и на грамотную и правильную реализацию работы всех компонентов
Во-вторых — во что засунуть > 256-битовый ключ? Во что-то отличное от AES? В каскад? Во что-то ещё более нестандартное? Это будет обоснованный выбор?

а причем тут AES? =\\
или у вас любое шифрование упирается только в него? =\\
Вполне можно предположить, что при такой атаке противнику не составит труда вычислить гамму размером хоть n, хоть 2n или больше, хотя и возможно, что более длинные гаммы вычислить труднее
несколько расплывчатые рассуждения :) "вполне возможно что да, но может и нет" .. понятно, что все зависит от ГПСЧ, но с ростом вычислительных возможностей компьютеров и с все большей распространенностью облачных сервисов, просчитывать их будет становиться все проще..

з.ы. вспомнилось тут насчет того, что AES128 (из-за неприменения к нему какой то из атак) более стойкий, чем AES256; так получается, что в этом случае лучше шифровать каскадно двумя разными 128 битными ключами, чем одним 256 битным? А как насчет других алгоритмов?
— Migel (14/02/2010 15:30)   профиль/связь   <#>
комментариев: 90   документов: 0   редакций: 0
что AES128 (из-за неприменения к нему какой то из атак) более стойкий, чем AES256;

Нет. Просто AES256 имеет относительно меньший запас прочности. Но практически они равнозначны из-за одинаковой длины блока.

так получается, что в этом случае лучше шифровать каскадно двумя разными 128 битными ключами, чем одним 256 битным? А как насчет других алгоритмов?

Зависит от того какой(какие) алгоритм.
— unknown (14/02/2010 23:00)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Плохой ГПСЧ — это не только тот, у которого можно найти отклонения в гамме.
При рассмотрении возможностей атак нормально делать предположения, что ГПСЧ может выдавать после атаки 2n какой-то большой блок данных, независящий от n.

У нас в новостях рассматривались атаки на ГПСЧ Windows, в ходе которых исследователям удавалось восстановить 128 килобайт гаммы. Количество этих килобайтов не зависело от приложенных вычислительных усилий после некоторого n, а от периодичности смены внутреннего состояния ГПСЧ. Использование ключа размером >128 килобайт непосредственно в шифре представить сложно, если только такой массив битов предварительно не схэшировать. Также как и сложно представить на данный момент широкораспространённый и доверяемый шифр, который бы допускал намного больший допустимый размер ключа по сравнению с AES-256.

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

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

Рассмотрим упрощённый пример с шифрами, отличающимися только размером ключа и особенностью ключевого расписания. Если некий абстрактный шифр CIPHER-128 нестоек к атаке на 2128/2, а CIPHER-256 нестоек к атаке на 2256/3, то атака против CIPHER-256 намного сильнее, значит он намного слабее в сертификационном плане. Но в практическом плане CIPHER-256 сильнее, чем CIPHER-128, так как несмотря на более сильную атаку 2256/3 > 2128/2.

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

При проектировании каскада необходимо учитывать, что вместо большого ключа, который пройдёт через все раунды ключевого расписания мы получим, что части ключа пройдут через части раундов, соответствующие отдельным шифрам. Эта тема не является до конца исследованной.
— Гость (16/02/2010 01:16)   <#>
Стойкие каскады получаются только из нечётного числа шифров. Известно даже бесполезное на практике доказательство стойкости, показывающее, что число шифров в каскаде должно быть простым.

А можно немного подробнее? Никогда раньше не слышал об этом, Яндекс на вскидку ничего не дал, но очень интересно.
— unknown (16/02/2010 16:31)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Ссылки не нашёл. Ключевых слов работы не помню :-(
— Мухтар (16/02/2010 16:43)   профиль/связь   <#>
комментариев: 155   документов: 20   редакций: 5
Навскидку, помню слухи о стандартах США на ключ, в котором часть бить используется для проверки подлинности ГПСЧ
— unknown (16/02/2010 17:07)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
В DES использовался 56-битный ключ. Остальные 8-бит сохранялись прямо вместе с самим ключом для проверки чётности при использовании в микросхемах, потому что они тогда были не так надёжны и эта процедура часто использовалась.

Ещё есть слухи про микросхемы с проверкой части подлинности ключа по MAC, чтобы ключи мог генерировать только центр распределения ключей, а пользователь не мог загружать собственые сгенерированные ключи.
— SATtva (16/02/2010 17:20)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Военная DRM.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3