— unknown (26/03/2009 13:32)   

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

Наоборот, ни одного потокового шифра, равного по доказуемой стойкости блочному, не создано. Нет нормальной теории потоковых шифров, у многих есть "различители", конкурс eCrypt на лучший потоковый шифр длится долго и результаты пока неубедительны.

И почему именно 128 бит, а не более?

Размер блока или размер ключа?

Блок 64 бита – даёт утечку открытого текста в некоторых режимах шифрования на примерно 8 гигабайтах, а 128 – на примерно 32000000000 гигабайтах.

размер ключа 64 бит может быть подобран современными компьютерными мощностями, 128 бит требует на подбор при минимальных затратах энергии (1 электронвольт, теоретический физический предел) столько, сколько её потребуется на то, чтобы растопить льды Антарктиды. Дальнейший рост симметричного ключа – только перестраховка от атак на несовершенство шифра, режима шифрования или протокола или изобретения квантовых компьютеров, а даже при росте мощностей обычных – основные проблемы возникают у асимметричных алгоритмов, которые и становятся слабым звеном.

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

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

— unknown (26/03/2009 13:40, исправлен 26/03/2009 13:41)   
По поводу 1024-битных блоков:

Чем больше длина блока, тем сложнее добиться правильной, с точки зрения криптостойкости, диффузии – распространения изменений вдоль блока.

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

И шифр да, должен быть универсальным: какой-то сервер этим же шифром может обрабатывать сотни тысяч соединений и лишний килобайты и миллисекунды могут перемножиться в большие величины. И тот же шифр и на микросхемах должен работать с крошечным ОЗУ и слабыи процессором.

Специально конструируют шифры с большим блоком – для ядра хэш-функций и в попытках создать особо стойкое дисковое шифрование (где размер сектора например 4096 бит и хорошо бы его весь и перешифровывать при записи).

— Konrad (27/03/2009 09:29)   

размер ключа 64 бит может быть подобран современными компьютерными мощностями, 128 бит требует на подбор при минимальных затратах энергии (1 электронвольт, теоретический физический предел) столько, сколько её потребуется на то, чтобы растопить льды Антарктиды.

При ключе 128 бит =>2^128 стойкость шифра равна корень(2^128)=2^64.
log(2^64)=19,3.

Теперь 10^9( частота процессора)+ 10^3 (процессоров)+10^2 ( таких компов)+
+ 10^log( 60сек*60мин*24часа*31день)=10^20,4.
Соответственно с большой вероятностью взлом блочного шифра за месяц.
( +тут не учтены оптимизации, слабые места реализации и т.д.).

И шифр да, должен быть универсальным

Вот этого я не понимаю.

Опыт жизни показывает – для конкретной цели нужен конкретный инструмент.
(есть легковушки, есть автобусы, есть грузовики и т.д., и ни у кого не возникает вопроса а зачем столько автомобилей?).

какой-то сервер этим же шифром может обрабатывать сотни тысяч соединений и лишний килобайты и миллисекунды могут перемножиться в большие величины.

Вот для таких целей использовать современные блочные шифры, но

скажем мне нужно отправить письмо размером 3 Кб, то зачем мне простой шифр? Тут уже нужна надежность..

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

Домашний ПК: 2ГГцпроцессор,2Гб оперативка и т.д., этого мало для того чтобы отказаться от ЭС- блоков на 4 бита, и перейти на более крупные блоки?

— unknown (27/03/2009 10:08)   

При ключе 128 бит =>2^128 стойкость шифра равна корень(2^128)=2^64.
log(2^64)=19,3.

Только при специфических атаках. В том виде, как шифр реализован в программах шифрования его стойкость и остаётся 2¹²⁸.

И шифр да, должен быть универсальным

Вот этого я не понимаю.

Потому что на шифрование нужен единый стандарт. И даже на его анализ уходят годы и усилия множества людей. И даже на стандарты не хватает усилия исследователей. Так, до сих пор не решены проблемы стандартизации режимов дискового шифрования, например. Нет доверяемого стандарта на режим шифрования с аутентификацией.

А с криптопримитивами (блочными шифрами, хэшами и пр.), если кто-то будет изобретать под каждую задачу – качественных работ по полному анализу не ждите.

Зоопарк шифров никто не будет поддерживать. Гораздо больше вероятности, что ошибка дизайна "сверхнадёжного" и "сверхтяжёлого" шифра останется незамеченной.

— Konrad (27/03/2009 11:08)   
Я ведь пишу с точки зрения простого потребителя.

Если есть спрос (есть люди которые хотят шифровать надежными шифрами), то будет и товар, независимо от того что кто-то не хочеть это поддерживать.

И судя по моим поискам в гугле, таких(очень сложных) шифров практически нет.

— unknown (27/03/2009 13:22, исправлен 27/03/2009 13:36)   

Я ведь пишу с точки зрения простого потребителя.

Если есть спрос (есть люди которые хотят шифровать надежными шифрами), то будет и товар, независимо от того что кто-то не хочеть это поддерживать.

как простой потребитель может оценить, какой шифр надёжный?

Кто из серьёзных криптографов будет тратить своё время не на разработку и анализ стандарта шифрования, а распылять силы на шифры узкого применения? Криптопримитив – это не программа, которая должна просто работать. Для того, чтобы он обрёл репутацию, нужно внимание и изучение всего сообщества.

Плюс, сложный – не значит автоматически более стойкий. Можно специально придумать очень сложный с хитрой трудновыявляемой аналитической лазейкой.

Или случайно допустить трудновыявляемый дефект.

По поводу – "есть спрос – есть товар" – напоминает аналогию с лекарствами и рекламу фарма-индустрии, которая потакает некомпетентному спросу (хочу чтобы просто лечило и желательно от всего) и получает прибыли.

Шифры – это не товар. Это результат деятельности прикладных научных исследований. Они бесплатны (кроме практически никому не нужных исключений).

— SATtva (27/03/2009 17:46, исправлен 27/03/2009 17:46)   

Если есть спрос (есть люди которые хотят шифровать надежными шифрами), то будет и товар, независимо от того что кто-то не хочеть это поддерживать.

И судя по моим поискам в гугле, таких(очень сложных) шифров практически нет.

Есть каскадное шифрование несколькими различными шифрами с помощью независимых ключей.

— Konrad (30/03/2009 15:15)   
Спасибо.
При каскадном шифровании какие режимы посоветуете?

— unknown (30/03/2009 16:05)   
Самое простое – такие же как и при обычном. Рассматривать каскад, как единый шифр, который можно использовать в любых режимах.

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

— Сергей (04/05/2009 21:36)   
Подскажите, пожалуйста, имеет ли смысл последовательно (каскадно, как я понял) шифровать файл с использованием разных алгоритмов шифрования (например одного блочного и одного потокового шифра), но одним и тем же ключом. Повысит ли это стойкость файла к взлому, или понизит?

— Гость (04/05/2009 22:05)   
Почти наверняка повысит.

— SATtva (05/05/2009 08:16)   
...Но, тем не менее, устоявшаяся практика состоит в использовании уникальных несвязанных ключей для каждого алгоритма в каскаде. В ином случае, если один из алгоритмов окажется уязвим, теоретически появится возможность восстановить ключ всего шифртекста.

— unknown (05/05/2009 09:13, исправлен 05/05/2009 09:13)   
каскадом шифров называется последовательное шифрование разными шифрами с независимыми ключами. Это как-бы в определении заложено. В некоторых работах рекомендуется использовать шифры с одинаковым размером блока, а число шифров в каскаде должно быть нечётным и даже простым.

Для выработки нескольких условно независимых ключей из одного можно использовать KDF (Key Derivation Function) – криптостойкую функцию генерации производных ключей.

— unknown (05/05/2009 09:33, исправлен 05/05/2009 09:34)   
Смотрите работы:

Cryptanalysis of Multiple Modes of Operation^[link1]

Cryptanalysis of Triple-Modes of Operation^[link2]

Там рассмотрены и каскады из разных шифров и режимов, в частности случай:

A multiple mode may not be weaker than its strongest component, if the component keys are chosen independently

А во многих случаях тупое смешивание в каскад (там на примере одного шифра – DES, но с разными шифрами и одним ключом скорее всего будет также):

In a previous paper we analyzed multiple modes of operation and showed that the security of many multiple modes is significantly smaller than expected. In this paper we extend these results, with new cryptanalytic techniques, and show that all the (cascaded) triple modes of operation are not much more secure than a single encryption

— Почкин (05/05/2009 13:24)   
В моём понимании, каскадность это страховка на случай будущей компрометации одного из использованных алгоритмов. (Допустим, перехваченная шифровка всё ещё представляет ценность через n лет, когда использованный алгоритм уже не стоек.) Для усиления обычной стойкости дальше 256-битного ключа мне кажется идти бессмысленно.

— Гость (05/05/2009 13:48)   
Можно ли в качестве Key Derivation Function использовать шифрование?

— unknown (05/05/2009 14:17)   

каскадность это страховка на случай будущей компрометации одного из использованных алгоритмов

да, только для этого.

Можно ли в качестве Key Derivation Function использовать шифрование?

Впервую очередь нужно смотреть, а не придуман ли на такую тривиальную вещь как KDF, стандарт:

рекомендации NIST^[link3]

RFC2898^[link4] – смотрите отдельные главы про KDF.

Или можете дождаться завершения конкурса SHA-3 и надеяться, что победит хэш со встроенной опцией KDF.

Впоследнюю очередь, что нужно делать – это изобретать протокол для KDF самому, какой бы обманчиво простой эта задача не казалась.

— Сергей (06/05/2009 03:59)   
А не подскажите, где взять практическую реализацию Key Derivation Function? Интересует открытый исходный код на C (или C++) без каких-либо ограничений на использование.

— Гость (06/05/2009 21:04)   

Можно ли в качестве Key Derivation Function использовать шифрование?

RFC2898 предлагает для "производства" ключей применять псевдослучайную функцию по схеме PBKDF2. В качестве примера псевдослучайной функции предлагается брать HMAC-SHA-1.
Но если каскадное шифрование применяется на случай взлома некоторых из используемых шифров, надо учитывать и возможность взлома используемой псевдослучайной функции. Если для получения производных ключей применить каскад из KDF, взлом SHA-1 уже не будет страшен.
А поскольку невзломанный шифр имеет псевдослучайный выход, в качестве участвующих в каскаде KDF дополнительных псевдослучайных функций удобно брать сами шифры, участвующие в каскадном шифровании, ведь предполагается, что не все из них будут взломаны. :)

— Гость (06/05/2009 22:16)   
Уже не раз говорили:
1. Если использовать разные независимые ключи для каждого шифра каскада – надежность больше надежности одного шифра.

2. Если используем один и тот жеключ для всех шифров каскада – надежность равна надежности самого слабого шифра.

3. Если использовать какую нить функцию образования последовательности ключей – получиться что-то среднее между первым и вторым случаем.

— Гость (06/05/2009 22:28)   

получиться что-то среднее

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

— Сергей (06/05/2009 22:30)   

в качестве участвующих в каскаде KDF дополнительных псевдослучайных функций удобно брать сами шифры

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

— Гость (06/05/2009 22:41)   
1. Гость (06/05/2009 22:28) – напиши пример реализации.
2. Сергей:
Твоя схема эквивалентна следующей:

ключ -> шифр1.
ключ -> хеш-функция – шифр2.
ключ -> хеш-функция – хеш-функция – шифр3.

— Сергей (06/05/2009 23:12)   
Да, вы правы, это именно такая схема.
На мой взгляд она идеально впишется в каскадное шифрование, если на каждом этапе применить хеш-функции с разными алгоритмами. С одной стороны – разные шифры, с другой – разные хеш-функции.

— Гость (06/05/2009 23:29)   
Тогда это будет выглядеть так:
ключ -> шифр1.
ключ -> хеш-функция1 – шифр2.
ключ -> хеш-функция2 – хеш-функция3 – шифр3.

Алгоритмы как хеш-функций так и шифров по идее должны быть известны.
Тогда для взлома всего каскада нужно взломать последнее звено:
ключ -> хеш-функция2 – хеш-функция3 – шифр3.

Впринципе данная схема надежней схемы с одним ключем для всех шифров каскада, но все таки слабей схемы с различными ключами для шифров каскада.

С другой стороны возникает вопрос:
Чем каскадная схема с одним ключем надежней от одного шифра с одним ключем?
Тем что для последнего шифра каскада открытий текст будет псевдослучайними данными?
Довольно сомнительно.
Хотя...?

— Гость (07/05/2009 01:35, исправлен 07/05/2009 09:43)   

Гость (06/05/2009 22:28) – напиши пример реализации.

Смотрим в rfc2898^[link4] схему PBKDF2:
PBKDF2 (P, S, c, dkLen) Options: PRF underlying pseudorandom function (hLen denotes the length in octets of the pseudorandom function output) Input: P password, an octet string S salt, an octet string c iteration count, a positive integer dkLen intended length in octets of the derived key, a positive integer, at most (2^32 - 1) * hLen Output: DK derived key, a dkLen-octet string Steps: 1. If dkLen > (2^32 - 1) * hLen, output "derived key too long" and stop. 2. Let l be the number of hLen-octet blocks in the derived key, rounding up, and let r be the number of octets in the last block: l = CEIL (dkLen / hLen) , r = dkLen - (l - 1) * hLen . Here, CEIL (x) is the "ceiling" function, i.e. the smallest integer greater than, or equal to, x. 3. For each block of the derived key apply the function F defined below to the password P, the salt S, the iteration count c, and the block index to compute the block: T_1 = F (P, S, c, 1) , T_2 = F (P, S, c, 2) , ... T_l = F (P, S, c, l) , where the function F is defined as the exclusive-or sum of the first c iterates of the underlying pseudorandom function PRF applied to the password P and the concatenation of the salt S and the block index i: F (P, S, c, i) = U_1 \xor U_2 \xor ... \xor U_c where U_1 = PRF (P, S || INT (i)) , U_2 = PRF (P, U_1) , ... U_c = PRF (P, U_{c-1}) . Here, INT (i) is a four-octet encoding of the integer i, most significant octet first. 4. Concatenate the blocks and extract the first dkLen octets to produce a derived key DK: DK = T_1 || T_2 || ... || T_l<0..r-1> 5. Output the derived key DK.
В этой функции качестве параметра PRF используется псевдослучайная функция с двумя аргументами. Я предлагаю для получения ключа использовать PBKDF2 несколько раз, подставляя её выход на место соли, а в дополнение к рекомендованной HMAC^[link5]-SHA-1, последовательно использовать в этом качестве все шифры, участвующие в каскаде.

The first argument to the pseudorandom function PRF serves as HMAC's

"key," and the second serves as HMAC's "text." In the case of PBKDF2,
the "key" is thus the password and the "text" is the salt.

If a random number generator or pseudorandom generator is not

available, a deterministic alternative for generating the salt (or
the random part of it) is to apply a password-based key derivation
function to the password and the message M to be processed. For
instance, the salt could be computed with a key derivation function
as S = KDF (P, M)

— unknown (07/05/2009 10:28, исправлен 07/05/2009 11:30)   
Или использовать надо что-то наподобие AES-CMAC^[link6].

Или нечто на основе режима SIV^[link7], который тоже фигурирует в каком-то стандарте в качестве KDF.

Обратите внимание на сложность доказательства стойкости в работах по последней ссылке. Может быть всё не так просто, поэтому проблема KDF на блочных шифрах до сих пор не решена?

Конкретно в качестве KDF предлагалось использовать S2V – гдава 5. "Enriching a PRF to take Vectors of Strings as Inputs: The S2V Construction".

Вот что в итоге есть ещё про S2V^[link8], но это черновые стандарты, стойкость этой KDF явно до конца не изучена.

If S2V is used as a key derivation function, the secret input MUST be

generated uniformly at random. S2V is a pseudo-random function and
is not suitable for use as a random oracle as defined in [RANDORCL].

The security bound set by the proof of security of S2V in [DAE]
depends on the number of vector-based queries made by an adversary
and the total number of all components in those queries. The
security is only proven when the number of components in each query
is limited to n-1, where n is the blocksize of the underlying pseudo-
random function. The underlying pseudo-random function used here is
based on AES whose blocksize is 128 bits. Therefore, S2V must not be
passed more than 127 components. Since SIV includes the plaintext as
a component to S2V, that limits the number of components of
associated data that can be safely passed to SIV to 126.

— Гость (07/05/2009 19:39)   

проблема KDF на блочных шифрах до сих пор не решена

А как насчёт каскадного шифрования? Доказательства есть?

— Гость (07/05/2009 20:30)   
Вобщем, если не сильно мудрить, схема следующая, как я понял,

ключ служит для получения с помощью некоторого преобразования(хеш-функции, шифры каскада, и все что душа пожелает) набора ключей: ключ1, ключ2, ключ3, которые потом используються при шифровании каскадом:
ключ1 -> шифр1.
ключ2 -> шифр2.
ключ3 -> шифр3.

Теперь допустим взламываем такой каскад прямым перебором (длина ключа, допустим 128 бит):
Понадобиться 2^128 переборов, а не 2^(3*128) как в случае независимости ключей 1,2,3.

— Гость (07/05/2009 23:10)   

Понадобиться 2^128 переборов

... и настукпит всемирный потоп, поскольку растают льды антарктиды. :)

2^(3*128) в случае независимости ключей 1,2,3

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

— Гость (07/05/2009 23:40)   

проблема KDF на блочных шифрах до сих пор не решена

Тогда в каскаде KDF применяем рекомендованную хэш-функцию последней. Как такое решение может ослабить стойкость?

— unknown (08/05/2009 09:01)   

Понадобиться 2^128 переборов, а не 2^(3*128) как в случае независимости ключей 1,2,3

Выше правильно заметили – это не от перебора. При переборе эффективная энтропия останется 2¹²⁸. Это на случай, если один из трёх шифров ненадёжен к какой-либо атаке с известным или подобранным текстом.

Ну примерно как узлы сети Tor :)

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

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

Насчёт каскада KDF. Предположим, противник взламывает один из шифров в каскаде (как он это точно определит кстати?). Он узнает один из выходов KDF. Каким типом нестойкости KDF или составляющих её хэш-функций он сможет воспользоваться, чтобы вычислить два других выхода KDF?

Почему в KDF нужно использовать каскад, а не XOR трёх KDF? Это же псевдослучайные функции (PRF), а не псевдослучайные перестановки (PRP), как блочные шифры.

Кстати, есть одна теоретическая работа, где показано, что XOR трёх (при ряде допущений даже двух) PRP даёт хорошее приближение к PRF, что хотели даже использовать в дизайне хэш-функций. Можно было бы взять три разных блочных шифра, и поксорив их выход получать PRF для KDF. Ведь основа любой KDF – это PRF, поэтому и используют хэш-функции.

Только может всё-таки доверить эту работу известным теоретикам, пусть под неё хоть какую-то доказательную базу подведут. Зачем самим-то это всё изобретать и обосновывать стойкость "на пальцах", если методами доказуемой безопасности на уровне ведущих специалистов мы всё-равно не владеем?

— Konrad (08/05/2009 10:51)   
Говорили говорили, и к чему пришли?

unknown:
"Это на случай, если один из трёх шифров ненадёжен к какой-либо атаке с известным или подобранным текстом."
А где гарантия что таким не окажеться весь каскад?

— unknown (08/05/2009 11:24, исправлен 08/05/2009 11:25)   
Если все в каскаде шифры ненадёжны, то всё пропало...

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

Оценки колеблются от "затраты на взлом каскада по крайней мере не меньше, чем на взлом самого стойкого шифра из каскада", до "если первый шифр нестоек к атакам с известными открытыми текстами, то его взлом открывает путь к взлому последующего шифра" – принцип последовательного взлома.

Хотя, наверное могут быть и более сложные варианты взаимодействия уязвимостей.

— Гость (08/05/2009 19:41)   

Только может всё-таки доверить эту работу известным теоретикам

Ещё раз повторю вопрос: есль ли теория для каскада шифров? Или без теории этим тоже лучше не заниматься?
И если мы перед применением к паролю рекомендованной KDF произведём его шифрование, как это может ухудшить ситуацию? Хотя бы гипотетически/теоретически?

— Гость (08/05/2009 19:49)   
Произведём его шифрование, заметьте, каскадом стойких шифров, проверенных и рекомендованных известными теоретиками.

— unknown (09/05/2009 00:47)   

И если мы перед применением к паролю рекомендованной KDF произведём его шифрование, как это может ухудшить ситуацию?

Ну надо хотя бы чётко понимать, что блочный шифр – это PRP, хэш-функция – PRF (до конкурса SHA3 все хэш-функции могут быть не совсем полноценными PRF из-за особенностей дизайна). Для KDF нужна PRF.
Ну такова теория KDF. Вариант каскадной KDF как XOR выхода блочных шифров я предложил выше.

Другой вариант мне попался в соседней ветке в моём же сообщении про Keccac и структуру Sponge^[link9] – вот если там взять три разных блочных шифра и из них получить каскадную PRF-KDF? Если есть одно из лучших на мой скромный взгляд доказательств близости для структуры Sponge из хэша Keccak к идеальной модели Random Oracle среди всех кандидатов SHA3, то на него можно положиться.

Но самостоятельное конструирование – это всё "игры разума", бездоказательные варианты.

есль ли теория для каскада шифров?

есть разрозненные и малочисленные работы, но полной теории нет.

Доказано что, если зашифровать с независмыми ключами E1( <R> ), E2(R XOR M), где R – истинно случайные данные и увеличить таким образом шифртекст в два раза, то такой каскад будет идеальным (на его взлом понадобиться взлом обязательно двух шифров) – это как бы передача одноразового блокнота и ключа к нему посредством двух разных шифров плюс полная рэндомизация открытого текста. Можно использовать хоть n шифров, только шифртекст будет больше открытого текста в n раз и понадобиться n-1 блоков истинно случайных (от физического источника) чисел.

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

Нужны ли вообще каскады?

вот некоторые утверждают пока не решены проблемы с ассиметрикой (постоянная недостаточность размеров ключей и резкое снижение быстродействия при их увеличении)-- то даже AES-256 не нужен^[link10].

— Гость (09/05/2009 02:58)   

Ну надо хотя бы чётко понимать, что блочный шифр – это PRP, хэш-функция – PRF. Для KDF нужна PRF. Ну такова теория KDF

Я не предлагаю убрать из KDF PRF, я даже не предлагаю менять рекомендованную KDF, я предлагаю этой рекомендованной KDF подать на вход не сам пароль, а его пермутацию с помощью PRP в виде каскада одобренный лучшими собаководами криптографами блочных шифров. КАК ЭТО МОЖЕТ УХУДШИТЬ БЕЗОПАСНОСТЬ ???

— Гость (09/05/2009 03:07)   

полной теории нет

Значит, по вашей логике, каскадное шифрование тоже "игры разума". Тогда о чём вообще речь?

— Гость (09/05/2009 03:21)   

я предлагаю этой рекомендованной KDF подать на вход не сам пароль, а его пермутацию с помощью PRP

Да, это отличается от первоначально предложенной мной схемы, но зато более ясно.

Нужны ли вообще каскады?

Это другой вопрос. Но уж если используется каскад из шифров, странно использовать KDF без каскада.

есть разрозненные и малочисленные работы

На фоне того, как все дружно громким хором кричат "AES наше всё", это наводит на нехорошие подозрения. Ну пусть нет доказательств, но хоть рекомендации-то должны бы были быть? Чтобы "на коленке" тут не изобретать...

— Гость (09/05/2009 12:32)   

наводит на нехорошие подозрения

Да уж, если пытаться усилить AES^[link11] можно прожить всю жизнь молодым...

— Гость (12/05/2009 23:32)   
Оптимистический поворот разговора...

— unknown (13/05/2009 09:18, исправлен 13/05/2009 09:20)   
...но неконструктивный.

Ну хотя бы вики по хэшам из блочных шифров^[link12] почитайте.

Схемы построения хэшей из блочных шифров Davies-Meyer, Matyas-Meyer-Oseas, Miyaguchi-Preneel, Hirose видимо изобретены просто так и доказательства к ним придумывались от нечего делать.

Но уж если используется каскад из шифров, странно использовать KDF без каскада.

На фоне того, как все дружно громким хором кричат "AES наше всё", это наводит на нехорошие подозрения. Ну пусть нет доказательств, но хоть рекомендации-то должны бы были быть?

Возмите три разных блочных шифра, чтобы получить каскадный хэш, и из него выведите готовую KDF. Ну нет тут никакого заговора – такая работа может быть просто никому неинтересна. Нет тут ни практического спроса, ни теоретического интереса. Мутная тема просто. А без формального доказательства стойкости никто это рассматривать и продвигать не будет.

Я уже третий вариант каскада из шифров для построения хэша предлагаю. Каскад PRP остаётся PRP, а KDF основана на PRF. Раз на это есть доказательства, то этому и надо следовать. Слишком много примеров, когда в элементарной и очевидной казалось бы конструкции, если её проанализировать по формальным моделям, находят уязвимости.

Какой смысл подавать PRP на вход PRF?
Может из всех компонентов PRP сформировать PRF (воспользовавашись готовым доказательством, что каскад PRP в данной конструкции образует PRF) и уже на основе этой каскадной PRF создавать KDF?

Три варианта получения PRF из PRP:

1) XOR выхода нескольких PRP
2) Новая схема Sponge
3) Старые схемы – Davies-Meyer, Matyas-Meyer-Oseas, Miyaguchi-Preneel, относительно новая – Hirose.

и ещё режим S2V.

— unknown (25/05/2009 11:53)   

На фоне того, как все дружно громким хором кричат "AES наше всё", это наводит на нехорошие подозрения.

Да уж, если пытаться усилить AES можно прожить всю жизнь молодым...

Кстати, как отмечено в рассылке Crypto на нынешнем Еврокрипте на Rump Session представили
анонс доказательства нестойкости AES^[link13].

Если это так, то это исторический момент. Найден различитель, отсчёт пошёл...

Хотя может как в DES – будет куча непрактичных атак, а стандарт просто объявят со временем устаревшим.

— Гость (26/05/2009 00:46)   

анонс доказательства нестойкости AES.

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

— Гость (26/05/2009 03:25)   

Find 5-multicollision in few hours on the PC

Теперь в онлайновых казино кроме MD5 как доказательство их честности будут предлагать использовать в качестве хэша последовательности выпавших номеров ещё и AES :)

— unknown (26/05/2009 09:10, исправлен 26/05/2009 09:11)   
А теперь сравниваем доклад с конференции и читаем исходное описание Rijndael^[link14], после чего задумываемся над пунктами 8.7 и десятой главой. Ну да, конечно, вроде бы ничего страшного.

— Гость (19/06/2009 20:47)   
А вопрос так и остался открытым.
Что мешает сделать длину блока 4096 бит?

— Гость (19/06/2009 21:21)   
Только ненадо говорить о том, что недостаточно ресурсов комп-ра.
Современные комп. игры не шуточно грузят комп-р, и почему-то это никого не волнует...

"Зоопарк алгоритмов" появиться?

Ну смотрите:
я хочу отвести 1000 кирпичей на стройку и для этого беру мерс и пихаю в салон кирпичи?-Нет беру грузовик предназначенный для перевозки грузов.
Так почему я должен всюду использовать один АES?
Для каждой задачи должен быть свой инструмент.
А универсальный шифр всех времен и народов, это бред.
Будущее за специализированными шифрами.

— SATtva (19/06/2009 21:29)   
Похоже, пора новый пункт в FAQ добавлять...

— Гость (19/06/2009 21:33)   
SATtva, вопрос не так прост, как может показаться на первый взгляд.
Ладно...время покажет.

— SATtva (19/06/2009 21:44)   
Вот именно. Как показывают "события последних дней" ©, разработка стойких криптоалгоритмов при постоянном продвижении исследований по их взлому становится чрезвычайно сложной задачей, которая под силу единичным исследовательским группам по всему миру. Примерно столько же групп способно проанализировать подобный алгоритм, чтобы найти его слабости. А теперь представьте, что вместо нескольких общепризнанных алгоритмов, достаточно универсальных (one size fits all), будет несколько десятков, каждый для своей цели. (Хотя для этого давно существуют режимы.) Кто будет всё это разрабатывать и анализировать?

— Гость (19/06/2009 22:55)   
Ну придеться выделить некоторые средства...

— unknown (20/06/2009 15:19)   

Что мешает сделать длину блока 4096 бит?

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

Стойкий шифр должен быть неотличим от идеальной модели -PRP.

Размер блока b – это количество вариантов отктрытых текстов на одном ключе и количество вариантов соответствующих им шифртекстов, заданных некоторой таблицей перестановки размером 2^b. Ну и подберите таблицу размером 2¹²⁸.

Размер ключа k – это количество таких таблиц для всех ключей 2^k.

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

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

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

я хочу отвести 1000 кирпичей на стройку и для этого беру мерс и пихаю в салон кирпичи?-Нет беру грузовик предназначенный для перевозки грузов.
Так почему я должен всюду использовать один АES?

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

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

А на основе этих криптопримитивов, как из кирпичиков собирать режимы и протоколы на основе принципов доказуемой безопасности. Это тоже сложная работа для специалистов, условно чуть меньшей квалификации.