Це просте спілкування із зашифрованою XOR абсолютно безпечним?


23

Скажімо, у кожної Аліси та Пітера є флеш-пам’ять USB на 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]

А для максимальної безпеки після прочитання повідомлення також стерте використану частину ключа. - EDIT: Насправді цей крок за допомогою цього простого алгоритму (без перевірки цілісності та автентифікації) знижує безпеку, див. Пост Пагла Ебермана нижче.

Коли Пітеру потрібно надіслати повідомлення Алісі, вони роблять зворотній шлях, на цей раз з peter_to_alice.keyі peter_pointer.

За допомогою цієї банальної схеми вони можуть надсилати щодня протягом наступних 50 років 2 ГБ / (50 * 365) = ~ 115 кБ зашифрованих даних в обох напрямках. Якщо їм потрібно більше даних для надсилання, вони могли б використовувати більші клавіші, наприклад, з сьогоднішніми HD-дисками 2 ТБ (клавішами 1 ТБ), можна було б обмінюватися 60 Мб / день протягом наступних 50 років! На практиці дуже багато даних; наприклад, за допомогою стиснення - це більше години високоякісного голосового спілкування.

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

Чи правий я? Чи справді ця схема спілкування абсолютно безпечна? А якщо це безпечно, чи має своє ім’я? Шифрування XOR добре відоме, але я шукаю назву цього конкретного практичного додатка, використовуючи великі клавіші з обох сторін? Я смиренно чекаю, що цю програму хтось винайшов перед собою. :-)

Примітка: Якщо це абсолютно безпечно, то це дивовижно, тому що з сьогоднішніми низькими витратами на великі накопичувальні пристрої було б набагато дешевше безпечне спілкування, ніж із дорогою квантовою криптографією, і це має рівноцінну безпеку!

EDIT: Я думаю, що це буде більш практичним у майбутньому, оскільки зменшуються витрати на зберігання.Це може вирішити безпечне спілкування назавжди.Сьогодні ви не знаєте, чи хтось вдало атакує існуючі шифри навіть через рік і робить його часто дорогі реалізації незахищеними. У багатьох випадках, перш ніж відбувається спілкування, коли обидві сторони зустрічаються особисто, саме час генерувати ключі. Я думаю, що це ідеально підходить для військової комунікації, наприклад між підводними човнами, які можуть мати HD з великими клавішами, а військовий центральний може мати HD для кожної підводного човна. Це також може бути практичним у повсякденному житті, наприклад, контролювати свій банківський рахунок, оскільки, створюючи свій рахунок, ви зустрічаєтесь з банком тощо.


4
Окрім конкретної схеми, яка координує, яку частину ключа використовувати, це лише разовий набір . Але при ретельному огляді виявляється, що насправді це не корисно для 99% випадків використання.

10
Оскільки це питання стосується міцності певного алгоритму криптовалюти, воно може бути більше підходить для crypto.stackexchange.com . Щоб перемістити своє питання туди, ви можете позначити увагу модератора та попросити міграцію.
Барт ван Інген Шенау

12
ОТП були винайдені понад століття тому і використовувалися як фактичні фізичні прокладки паперу в обох світових війнах. ( en.wikipedia.org/wiki/One-time_pad ) Проблема в криптографії тоді як зараз обмін ключовими.
Gort the Robot

6
Зауважте, що це все ще дозволяє вирішити проблему генерації достатньо унікальних ключів для всіх очікуваних даних, поки обидві сторони знову не зустрінуться, і що ключі повинні бути створені за загальним випадковим процесом - генератори псевдовипадкових чисел вразливі до аналізу, все частіше оскільки більше зразків, що використовують той же PRNG, стають доступними.
keshlam

1
@keshlam. Генерація справжніх квантово-випадкових чисел стає дуже дешевою. Цікава стаття в arxiv: Квантове генерація випадкових чисел на мобільному телефоні: arxiv.org/abs/1405.0435
користувач3123061

Відповіді:


50

Так, це одноразова прокладка . Якщо ключовий матеріал ніколи не використовується повторно, він теоретично є надійним.

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


52
Я думаю, що варто підкреслити, що "теоретично захищений" означає, що це математично доведено, що його не можна зламати , за умови, що ключі справді випадкові і не використовуються повторно. Це майже найсильніша гарантія, яку ви можете отримати в будь-якому місці криптографії.
Майкл Боргвардт

1
@MichaelBorgwardt величезна точка там. У цьому випадку "теоретично безпечний" насправді краще, ніж "практично безпечний".
Марк

2
У конкретному випадку: у мене є 2 Гб випадковий ключ, у якого 16 послідовних байтів 0.
Майкл

@Michael Шанси на те, що це станеться, становлять приблизно 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 полягає в тому, що ключ є (принаймні) до тих пір, поки повідомлення для шифрування, і потребує дуже якісного джерела випадкових чисел.
Дональні стипендіати

Багато алгоритмів шифрування працюють тим, що якимось чином перетворюють ключ у потік даних, який не відрізняється від випадкових даних, а потім використовують ці дані як єдину панель часу. З точки зору зловмисника, немає різниці між даними, які є справді випадковими, і даними, які не відрізняються від випадкових даних (за визначенням; якщо ви знайшли різницю, це було нерозрізнено), тому теоретично це так само безпечно, як OTP . Звичайно, коли ми говоримо, що дані не відрізняються від справжніх випадкових даних, зазвичай існує застереження. Це пояснення, звичайно, є грубим надмірним спрощенням.
Брайан

21

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

  • Перехоплюючий зловмисник, який правильно відгадує звичайний текст, може маніпулювати шифровим текстом до всього, що вона хоче (з однаковою довжиною).

  • Якщо зловмисник вставляє або видаляє якесь повідомлення (або його частину), покажчики Аліси та Боба виходять із синхронізації і всяке майбутнє спілкування порушується.

    Оновлення: передбачається, що обидві сторони відстежують обидва вказівника. Якщо ви надсилаєте поточне значення вказівника, ви вразливі до дворазових атак (якщо ви дозволяєте використовувати один і той же діапазон ключів не один раз) або DOS-атак (якщо ви не дозволяєте той самий діапазон ключів використовувати не один раз, наприклад, видаляючи їх).

Обидві ці проблеми викликані відсутністю цілісності та захисту автентифікації - у вас ідеальний шифр, але MAC немає.

Додайте MAC до свого протоколу одноразової прокладки, щоб зробити його фактично захищеним. Кожне повідомлення повинно отримувати "контрольну суму", яка гарантує, що воно було фактично надіслане передбачуваним відправником, і не було змінено між ними. Також вам слід надіслати деякий порядковий номер, щоб одержувач знав, яку частину ключа використовувати, коли попереднє повідомлення загубилося (або відхилити повідомлення, якщо воно дублюється) - включіть це до розрахунку контрольної суми.

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


Якщо зловмисник вставляє або видаляє якесь повідомлення (або його частину), покажчики Аліси та Боба виходять із синхронізації і всяке майбутнє спілкування порушується. Покажчики є незалежними та не потребують синхронізації, тому в майбутньому повідомлення не буде порушено, якщо повідомлення втрачено (фактичне зміщення ключа, яке використовується для шифрування повідомлення, надсилається разом із цим повідомленням). Але ви частково праві: поза синхронізацією використовується частина ключа на стороні прийому, яка не стирається, оскільки видалене повідомлення не отримано (використана частина буде стерта з наступним отриманим повідомленням).
user3123061

Але, ви праві. Представлений простий алгоритм пропускає цілісність та автентифікацію. Практична реалізація потребує більш надійної роботи.
user3123061

@ user3123061 Я б не просто знищував цілісність та автентифікацію, якби я був ти. Техніка адаптивної обраної шифротекстової атаки використовує відсутність захисту цілісності для порушення конфіденційності . Я б пішов так далеко, щоб сказати, що класичний одноразовий майданчик (який ви переосмислили) є абсолютно незахищеним , незважаючи на його очевидну математичну міцність, саме завдяки цій атаці.
zwol

2
Адаптивна обрана атака ципертексту - це досить поганий вибір атаки проти перевіреної людиною OTP. OOS буде помічено, і ваш нападник буде досить швидко покараний. Тільки якщо приймач обробляється машиною і дає відповідь, ця атака взагалі корисна.
Джошуа

@Zack Є багато проблем з OTP, але жодна не загрожує конфіденційності. Зауважте, що навіть якщо ви чудово вгадаєте плантексту + клавіші попереднього повідомлення, наступне повідомлення шифрується абсолютно новим, незалежним ключем (теж значних розмірів). Нічого не можна пристосовувати до кількох взаємодій.

4

Насправді це не зовсім безпечно. Те, що протікає ваш протокол, - ДІЛЬНІСТЬ повідомленого повідомлення

Наприклад, якщо шпигун знає, що ви відповісте "так" або "ні" і бачить довжину = 2, він може зробити висновок, що це "ні".

Насправді дивовижно, скільки можна зробити лише з відомих довжин, якщо можна вгадати контекст.


3
Це досить легко виправити, до розумного рівня безпеки, оскільки ви можете залити повідомлення випадковим небажаним, тому довжина повідомлення є кратною фіксованого розміру блоку - скажімо, 256 символів. Це перемогло б простий аналіз "так що немає", за рахунок швидшого використання OTP.
Пітер Баньялл

Дійсно - оскільки ви можете надсилати ~ 115 кБ щодня протягом наступних 50 років, ви можете очікувати, що кожен блок буде принаймні 20 кбіт, що означає, що довжина не така важлива.
apnorton
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.