Шифрование с произвольным доступом с помощью AES в режиме счетчика с использованием Fortuna PRNG:

Question

Я строю шифрование файлов на основе AES, которое должно работать в режиме произвольного доступа (доступ к любой части файла). Например, можно использовать AES в Counter, но хорошо известно, что нам нужна уникальная последовательность, никогда не используемая дважды. Можно ли в этом случае использовать упрощенный PRNG Fortuna (шифровать счетчик случайно выбранным уникальным ключом, специфичным для конкретного файла)? Есть ли слабые места в этом подходе?

Таким образом, шифрование / дешифрование может выглядеть следующим образом

Шифрование блока со смещением:

rndsubseq = AESEnc(Offset, FileUniqueKey)
xoredplaintext = plaintext xor rndsubseq
ciphertext = AESEnc(xoredplaintext, PasswordBasedKey)

Расшифровка блока со смещением:

rndsubseq = AESEnc(Offset, FileUniqueKey)
xoredplaintext = AESDec(ciphertext, PasswordBasedKey)
plaintext = xoredplaintext xor rndsubseq

Одно наблюдение. Я сам пришел к идее, использованной в Фортуне, и позже обнаружил, что она уже придумана. Но, как я читаю повсюду, ключевым моментом в этом отношении является безопасность, но есть еще один хороший момент: это, так сказать, отличный генератор псевдослучайных чисел с произвольным доступом (в упрощенном виде). Таким образом, PRNG, который не только производит очень хорошую последовательность (я тестировал ее с Ent и Die Hard), но также позволяет получить доступ к любой подпоследовательности, если вы знаете номер шага. Так можно ли использовать Fortuna в качестве PRNG с произвольным доступом в приложениях безопасности?

EDIT:

Другими словами, я предлагаю использовать Fortuna PRNG в качестве настройки для формирования настраиваемого шифра AES с возможностью произвольного доступа. Я читал работы Лискова, Ривеста и Вагнера, но не мог понять, в чем было основное различие между шифром в режиме работы и настраиваемым шифром. Они сказали, что предложили перенести этот подход с самого высокого уровня внутри самого шифра, но, например, в моем случае ксероксация простого текста с твиком, это твик или нет?

Answer 1

Я думаю, вы, возможно, захотите посмотреть, как работают «настраиваемые блочные шифры», и посмотреть, как решается проблема шифрования диска: Теория шифрования диска . Шифрование всего диска похоже на вашу проблему: шифрование каждого сектора должно выполняться независимо (вы хотите независимое шифрование данных с различными смещениями), и в то же время все это должно быть безопасным. Над этим много работы сделано. Википедия, кажется, дает хороший обзор.

ИЗМЕНЕНО, чтобы добавить: Повторяйте ваши изменения: Да, вы пытаетесь сделать настраиваемый блочный шифр из AES, XOR с помощью открытого текста. Более конкретно, у вас есть Enc (T, K, M) = AES (K, f (T) xor M), где AES (K, ...) означает шифрование AES с ключом K, а f (T) является некоторой функцией твик (в твоем случае я думаю это Фортуна). Я кратко посмотрел на статью, которую вы упомянули, и насколько я вижу, можно показать, что этот метод не создает безопасный блочный шифр с возможностью настройки. Идея (основанная на определениях из раздела 2 статьи Лискова, Ривеста, Вагнера) заключается в следующем. У нас есть доступ либо к оракулу шифрования, либо к случайной перестановке, и мы хотим сказать, с кем мы взаимодействуем. Мы можем установить твик T и открытый текст M и получить обратно соответствующий зашифрованный текст, но мы не знаем ключ, который используется. Вот как можно выяснить, если мы используем конструкцию AES (K, f (T) xor M). Выберите любые два различных значения T, T ', вычислите f (T), f (T'). Выберите любое сообщение M, а затем вычислите второе сообщение как M '= M xor f (T) xor f (T'). Теперь попросите оракула шифрования зашифровать M с помощью настройки T, а M - с помощью настройки T. Если мы будем иметь дело с рассматриваемой конструкцией, то результаты будут идентичны. Если мы имеем дело со случайными перестановками, результаты будут почти наверняка (с вероятностью 1-2 ^ -128) отличаться. Это связано с тем, что оба входа для шифрования AES будут одинаковыми, поэтому шифротексты также будут идентичны. Это не будет иметь место, когда мы используем случайные перестановки, потому что вероятность того, что два выхода идентичны, составляет 2 ^ -128. Суть в том, что подстройка ксиринга для ввода, вероятно, не является безопасным методом.

В статье приводятся некоторые примеры того, что может оказаться безопасной конструкцией. Самым простым кажется, что Enc (T, K, M) = AES (K, T xor AES (K, M)). Вам нужно два шифрования на блок, но они доказывают безопасность этой конструкции. Они также упоминают более быстрые варианты, но они требуют дополнительных примитивов (почти-xor-универсальные семейства функций).

Answer 2

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

Другая проблема заключается в том, как сохранить FileUniqueKey в безопасности? Зашифровано паролем? Целая куча проблем возникает при использовании нескольких клавиш.

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