длина ключа
появились тут мысли на тему: есть ли смысл использовать большие ключи (к примеру, больше 256 бит для симметриков), исходя из логики компенсации плохого ГСЧ.. и вроде как получается, что есть..
у кого какие мысли по этому поводу, пишите..
комментариев: 11558 документов: 1036 редакций: 4118
в консерваториив ГСЧ подправить?комментариев: 88 документов: 13 редакций: 3
комментариев: 9796 документов: 488 редакций: 5664
Во-вторых — во что засунуть > 256-битовый ключ? Во что-то отличное от AES? В каскад? Во что-то ещё более нестандартное? Это будет обоснованный выбор?
Ну и в третьих:
Возьмём достаточно сильное и общее определение нестойкости Г(П) СЧ — на практике обычно используется что-то комбинированное — из ГСЧ берётся зерно для разворачиваемой с помощью ГПСЧ гаммы.
Допустим если Г(П) СЧ нестоек, то для получение гаммы выхода практически любой длины n достаточно провести атаку, которая требует < 2256 вычислений, доступных противнику образцов исходных данных или образцов доступных фрагментов гаммы с выхода ГПСЧ.
Вполне можно предположить, что при такой атаке противнику не составит труда вычислить гамму размером хоть n, хоть 2n или больше, хотя и возможно, что более длинные гаммы вычислить труднее, но если внутреннее состояние ГПСЧ вскрыто полностью, то длина разворачиваемой гаммы, которую может вычислить противник, может быть достаточно большой.
Т.е. может существовать (что неудивительно) атака, которая нарушает протокол, противоречащий принципам доказуемой безопасности. Или собирайте весь протокол из идеальных компонентов или доказывайте, что компенсация неидеальности компонента неизбежна и жизненно необходима (а здесь это заведомо не тот случай) и полна (а пример гипотетической атаки показывает, что в данном случае — нет).
комментариев: 88 документов: 13 редакций: 3
к примеру я ничего не делаю и не исправляю, я беру готовый продукт и пользуюсь им. при этом остается надеяться на компетентность автора программы и на грамотную и правильную реализацию работы всех компонентов
а причем тут AES? =\\
или у вас любое шифрование упирается только в него? =\\
несколько расплывчатые рассуждения :) "вполне возможно что да, но может и нет" .. понятно, что все зависит от ГПСЧ, но с ростом вычислительных возможностей компьютеров и с все большей распространенностью облачных сервисов, просчитывать их будет становиться все проще..
з.ы. вспомнилось тут насчет того, что AES128 (из-за неприменения к нему какой то из атак) более стойкий, чем AES256; так получается, что в этом случае лучше шифровать каскадно двумя разными 128 битными ключами, чем одним 256 битным? А как насчет других алгоритмов?
комментариев: 90 документов: 0 редакций: 0
Нет. Просто AES256 имеет относительно меньший запас прочности. Но практически они равнозначны из-за одинаковой длины блока.
Зависит от того какой(какие) алгоритм.
комментариев: 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.
Стойкие каскады получаются только из нечётного числа шифров. Известно даже бесполезное на практике доказательство стойкости, показывающее, что число шифров в каскаде должно быть простым.
При проектировании каскада необходимо учитывать, что вместо большого ключа, который пройдёт через все раунды ключевого расписания мы получим, что части ключа пройдут через части раундов, соответствующие отдельным шифрам. Эта тема не является до конца исследованной.
А можно немного подробнее? Никогда раньше не слышал об этом, Яндекс на вскидку ничего не дал, но очень интересно.
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 155 документов: 20 редакций: 5
комментариев: 9796 документов: 488 редакций: 5664
Ещё есть слухи про микросхемы с проверкой части подлинности ключа по MAC, чтобы ключи мог генерировать только центр распределения ключей, а пользователь не мог загружать собственые сгенерированные ключи.
комментариев: 11558 документов: 1036 редакций: 4118