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

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

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

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

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

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

рекомендации NIST

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

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

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

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

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

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

Уже не раз говорили:
1. Если использовать разные независимые ключи для каждого шифра каскада – надежность больше надежности одного шифра.

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

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

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

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

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

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

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

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

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

Тогда это будет выглядеть так:
ключ -> шифр1.
ключ -> хеш-функция1 – шифр2.
ключ -> хеш-функция2 – хеш-функция3 – шифр3.

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

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

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

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

Смотрим в rfc2898 схему 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-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)

Или использовать надо что-то наподобие AES-CMAC.

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

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

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

Вот что в итоге есть ещё про S2V, но это черновые стандарты, стойкость этой 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.

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

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

Вобщем, если не сильно мудрить, схема следующая, как я понял,

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

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

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

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

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

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