Является ли эта простая зашифрованная связь XOR абсолютно безопасной?

23

Скажем, у Алисы и Питера есть флешка на 4 ГБ. Они встречают и сохраняют на обеих палочках два файла с именами alice_to_peter.key(2 ГБ) и peter_to_alice.key(2 ГБ), которые содержат случайно сгенерированные биты. Они никогда не встречаются снова, но общаются в электронном виде. Алиса также поддерживает переменную с именем, alice_pointerа Питер поддерживает переменную с именем peter_pointer, обе из которых изначально установлены в ноль.

Когда Алисе необходимо отправить сообщение Питеру, она делает это (где nнаходится n-й байт сообщения):

encrypted_message_to_peter[n] = message_to_peter[n] XOR alice_to_peter.key[alice_pointer + n]
encrypted_payload_to_peter = alice_pointer + encrypted_message_to_peter
alice_pointer += length(encrypted_message_to_peter)

(и для максимальной безопасности, использованная часть ключа может быть стерта)

Питер получает encrypted_payload_to_peter, читает, alice_pointerхранится в начале сообщения и делает:

message_to_peter[n] = encrypted_message_to_peter[n] XOR alice_to_peter.key[alice_pointer + n]

А для максимальной безопасности после прочтения сообщения также сотрите использованную часть ключа. - РЕДАКТИРОВАТЬ: На самом деле этот шаг с помощью этого простого алгоритма (без проверки целостности и аутентификации) снижает безопасность, см. Пост Paŭlo Ebermann ниже.

Когда Питеру нужно отправить сообщение Алисе, они делают обратное, на этот раз с peter_to_alice.keyи peter_pointer.

С помощью этой тривиальной схемы они могут отправлять каждый день в течение следующих 50 лет 2 ГБ / (50 * 365) = ~ 115 КБ зашифрованных данных в обоих направлениях. Если им нужно больше данных для отправки, они могли бы использовать более крупные ключи, например, с сегодняшними 2 ТБ HD (1 ТБ ключи) можно было бы обменивать 60 МБ / день в течение следующих 50 лет! Это много данных на практике; например, используя сжатие, это более часа высококачественной голосовой связи.

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

Я прав? Действительно ли эта схема связи абсолютно безопасна? И если это безопасно, у него есть собственное имя? Шифрование XOR хорошо известно, но я ищу название этого конкретного практического приложения, использующего большие ключи с обеих сторон? Я смиренно ожидаю, что это приложение было изобретено кем-то до меня. :-)

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

РЕДАКТИРОВАТЬ: Я думаю, что это будет более практичным в будущем, поскольку затраты на хранение уменьшатся.Это может решить безопасную связь навсегда.Сегодня у вас нет уверенности в том, что кто-то успешно атакует существующие шифры даже через год и делает их часто дорогие реализации небезопасными. Во многих случаях до того, как происходит общение, когда обе стороны встречаются лично, самое время генерировать ключи. Я думаю, что он идеально подходит для военного общения, например, между подводными лодками, которые могут иметь жесткие диски с большими ключами, а военный центр может иметь HD для каждой подводной лодки. Это также может быть практичным в повседневной жизни, например, для контроля вашего банковского счета, потому что, когда вы создаете свой счет, вы встречаетесь с банком и т. Д.

user3123061
источник
4
Помимо конкретной схемы для координации того, какую часть клавиши использовать, это всего лишь одноразовый блокнот . Но при ближайшем рассмотрении оказывается, что на самом деле это бесполезно для 99% случаев использования.
10
Поскольку этот вопрос о силе конкретного алгоритма шифрования, он может быть более подходящим для crypto.stackexchange.com . Чтобы переместить свой вопрос туда, вы можете пометить внимание модератора и попросить о миграции.
Барт ван Инген Шенау
12
ОТП были изобретены более столетия назад и использовались в качестве настоящих бумажных прокладок в обеих мировых войнах. ( en.wikipedia.org/wiki/One-time_pad ) Проблема в криптографии тогда, как и сейчас, заключается в обмене ключами.
Gort the Robot
6
Обратите внимание, что это все еще оставляет вам возможность решить проблему генерации достаточного количества уникальных ключей для всех ожидаемых данных до тех пор, пока две стороны не встретятся снова, и что ключи должны быть сгенерированы посредством ОЧЕНЬ случайного процесса - генераторы псевдослучайных чисел уязвимы для анализа, и все в большей степени по мере появления большего количества образцов, использующих тот же PRNG.
Кешлам
1
@keshlam. Генерация истинных квантово-случайных чисел становится очень дешевой. Интересная статья на arxiv: Генерация квантовых случайных чисел на мобильном телефоне: arxiv.org/abs/1405.0435
user3123061

Ответы:

50

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

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

Vatine
источник
52
Я думаю, что стоит подчеркнуть, что «теоретически безопасный» означает, что математически доказано, что он не взломан , при условии, что ключи действительно случайны и не используются повторно. Это в значительной степени самая сильная гарантия, которую вы можете получить в криптографии.
Майкл Боргвардт
1
@MichaelBorgwardt огромная точка там. В этом случае «теоретически безопасный» на самом деле лучше, чем «практически безопасный».
Марк
2
Например, у меня есть случайный ключ размером 2 ГБ, который имеет 16 последовательных байтов по 0.
Майкл
@ Майкл Шансы на это примерно 1 из 10 ^ 27.
это
1
@Floris Мой "расчет": байт имеет 256 возможных значений. Это один из 256, что все будет ноль. 256 ^ 16, чтобы получить шанс на 16 байтов. А затем разделите количество байтов в 2 ГБ на эту возможность. Я думаю, что я пропустил деление на 16, так или иначе здесь (1024 * 1024 * 1024 * 1024 * 2 * (1/16)) / (256 ^ 16) Ваш последний пункт делает этот расчет в любом случае неуместным.
это
32

Как показывает ответ Ватина , ваш алгоритм в основном одноразовый.

Однако, чтобы прокомментировать одну из ваших заметок:

Примечание: если он абсолютно защищен, то он удивителен, потому что с современными недорогими большими объемами памяти это намного более безопасный способ безопасного общения, чем дорогая квантовая криптография и с эквивалентной безопасностью!

Мой ответ - нет, это не удивительно. Дьявол всегда в деталях, а дьявол здесь в обмене ключами. Ваш метод зависит от безупречного обмена ключами лицом к лицу. Я не могу позволить себе посылать Джеймса Бонда с 4 ГБ флэш-диском для меня каждому торговцу в Интернете каждый раз, когда я хочу что-то купить или иметь другие безопасные соединения.

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

как зовут
источник
13
Еще одна вещь, касающаяся OTP, заключается в том, что ключ (по крайней мере) длится столько времени, сколько необходимо для шифрования сообщения, и требует очень высокого качества источника случайных чисел.
Donal Fellows
Многие алгоритмы шифрования работают, так или иначе, преобразовывая ключ в поток данных, который неотличим от случайных данных, и затем используют эти данные в качестве одноразовой панели. С точки зрения злоумышленника, нет никакой разницы между данными, которые являются действительно случайными, и данными, которые неотличимы от случайных данных (по определению; если вы обнаружили разницу, она не была неразличимой), так что в теории это так же безопасно, как OTP , Конечно, когда мы говорим, что данные неотличимы от настоящих случайных данных, обычно есть куча предостережений. Это объяснение, конечно, является чрезмерным упрощением.
Брайан
21

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

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

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

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

Обе эти проблемы вызваны отсутствием целостности и защиты аутентификации - у вас есть идеальный шифр, но нет MAC.

Добавьте MAC к вашему протоколу одноразовой памяти, чтобы сделать его действительно безопасным. Каждое сообщение должно получить «контрольную сумму», которая гарантирует, что оно действительно было отправлено предполагаемым отправителем и не было изменено между Кроме того, вам следует отправить некоторый порядковый номер, чтобы получатель знал, какую часть ключа использовать, когда предыдущее сообщение потеряно (или отклонить сообщение, если оно дублируется) - включите его в вычисление контрольной суммы.

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

Пауло Эберманн
источник
Если злоумышленник вставляет или удаляет какое-либо сообщение (или его часть), указатели Алисы и Боба становятся несинхронными, и каждое последующее сообщение прерывается. Указатели являются независимыми и не нуждаются в синхронизации, поэтому в случае потери сообщения связь не будет нарушена (фактическое смещение ключа, используемого для шифрования сообщения, отправляется вместе с этим сообщением). Но вы отчасти правы: несинхронизированная часть ключа используется на принимающей стороне, которая не стирается, поскольку удаленное сообщение не принимается (использованная часть будет удалена со следующим полученным сообщением).
user3123061
Но вы правы. Представлен простой алгоритм пропуска целостности и аутентификации. Практическая реализация должна быть более надежной.
user3123061
@ user3123061 Я бы не стал игнорировать честность и аутентификацию на вашем месте. Техника адаптивной выбранной атаки зашифрованного текста использует отсутствие защиты целостности для нарушения конфиденциальности . Я бы даже сказал, что классический одноразовый блокнот (который вы заново изобрели) совершенно небезопасен , несмотря на кажущуюся математическую прочность, только из-за этой атаки.
zwol
2
Адаптивная выбранная атака на основе шифротекста - довольно неудачный выбор атаки на проверенный человеком OTP. ООС будет замечен, и ваш атакующий будет наказан довольно быстро. Только если получатель обработан машиной и дает ответ, эта атака будет вообще полезна.
Джошуа
@ Zack Есть много проблем с OTP, но ни одна из них не угрожает конфиденциальности. Обратите внимание, что даже если вы прекрасно угадаете плантекст + ключ предыдущего сообщения, следующее сообщение зашифровано совершенно новым независимым ключом (также большого размера). Там нет ничего, чтобы адаптироваться к нескольким взаимодействиям.
4

На самом деле это не совсем безопасно. Утечка вашего протокола - это ДЛИНА передаваемого сообщения.

Например, если шпион знает, что вы ответите «да» или «нет» и увидит длину = 2, он может определить, что это «нет».

На самом деле удивительно, сколько можно вывести только из известных длин, если можно угадать контекст.

w.pasman
источник
3
Это довольно легко исправить, но при разумном уровне безопасности, поскольку вы можете заполнить сообщение случайным мусором, поэтому длина сообщения будет кратна фиксированному размеру блока, скажем, 256 символов. Это побеждает простой анализ «да против нет», за счет более быстрого использования OTP.
Питер Баньялл
Действительно - поскольку вы можете отправлять ~ 115 КБ каждый день в течение следующих 50 лет, вы можете ожидать, что каждый блок будет иметь размер не менее 20 КБ, что означает, что длина не так важна.
Апнортон