Якому з них віддається перевага за яких обставин?

Я хотів би побачити список критеріїв оцінювання для різних режимів, а може бути, обговорення застосованості кожного критерію.

Наприклад, я вважаю, що одним із критеріїв є "розмір коду" для шифрування та дешифрування, що важливо для вбудованих мікро-кодів систем, як мережевих адаптерів 802.11. Якщо код, необхідний для реалізації CBC, набагато менший, ніж потрібний для CTR (я не знаю, це правда, це лише приклад), то я міг би зрозуміти, чому перевагу буде режим з меншим кодом. Але якщо я пишу програму, яка працює на сервері, і бібліотека AES, яку я використовую, реалізує як CBC, так і CTR, то цей критерій не має значення.

Подивіться, що я маю на увазі під "переліком критеріїв оцінки та застосованості кожного критерію" ??

Це насправді не пов'язано з програмуванням, але це пов'язано з алгоритмом.

• ECB не слід використовувати, якщо шифрувати більше одного блоку даних одним і тим же ключем.

• CBC, OFB та CFB схожі, однак OFB / CFB краще, тому що вам потрібно лише шифрування, а не розшифровка, що може заощадити простір коду.

• CTR використовується, якщо ви хочете гарної паралелізації (тобто швидкості), а не CBC / OFB / CFB.

• Режим XTS є найпоширенішим, якщо ви кодуєте випадкові доступні дані (наприклад, жорсткий диск або оперативна пам'ять).

• OCB - це найкращий режим, оскільки він дозволяє шифрувати та автентифікувати за один прохід. Однак є патенти на нього в США.

Єдине, що ви дійсно повинні знати, це те, що ECB не повинен використовуватися, якщо ви не шифруєте лише 1 блок. XTS слід використовувати, якщо ви шифруєте випадкові дані, а не потік.

• Ви завжди повинні використовувати унікальні IV щоразу, коли ви шифруєте, і вони повинні бути випадковими . Якщо ви не можете гарантувати , що вони є випадковим чином , використання Про , як це вимагається лише тимчасове значення , не є IV , і є певна різниця. Одноразове значення не впустити безпеки , якщо люди можуть вгадати наступний, IV може викликати цю проблему.

Будь ласка, подумайте довго і наполегливо, якщо вам не вдасться обійти реалізацію власної криптографії

Потворна правда в тому, що якщо ви задасте це питання, ви, ймовірно, не зможете розробити та впровадити захищену систему.

Дозвольте проілюструвати мою думку: Уявіть, що ви створюєте веб-додаток і вам потрібно зберігати деякі дані сеансу. Ви можете призначити кожному користувачеві ідентифікатор сеансу і зберігати дані сеансу на сервері в ідентифікаційному сеансі хеш-карти, зібраним в дані сеансу. Але тоді вам доведеться зіткнутися з цим примхливим станом на сервері, і якщо в якийсь момент вам потрібно більше одного сервера, речі стануть брудними. Тому замість цього у вас є ідея зберігати дані сеансу у файлі cookie на стороні клієнта. Ви, звичайно, зашифруєте його, щоб користувач не міг читати та маніпулювати даними. Отже, який режим слід використовувати? Приїжджаючи сюди, ви читаєте головну відповідь (вибачте, що ви виділили myforwik). Перший, що охоплюється, - ECB - не для вас, ви хочете зашифрувати більше одного блоку, наступний - CBC - звучить добре, і вам не потрібен паралелізм CTR, вам не потрібен випадковий доступ, тому ніякі XTS та патенти не є ПДФА, отже, жодними OCB. Використовуючи свою криптобібліотеку, ви розумієте, що вам потрібно трохи прокладки, оскільки ви можете шифрувати лише кратні розміри блоку. Ви вибираєтеPKCS7, оскільки він був визначений у деяких серйозних стандартах криптографії. Десь прочитавши, що CBC є надійно захищеним, якщо використовується з випадковим ІV та захищеним блоковим шифром, ви відпочиваєте легко, навіть якщо зберігаєте ваші конфіденційні дані на стороні клієнта.

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

Це не гіпотетичний сценарій: Microsoft мала точну ваду в ASP.NET ще кілька років тому.

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

Що робити, якщо вам потрібно зашифрувати дані

Для прямих з'єднань використовуйте TLS (обов'язково перевірте ім'я хоста сертифіката та ланцюга емітента). Якщо ви не можете використовувати TLS, шукайте API найвищого рівня, який система може запропонувати для вашого завдання, і будьте впевнені, що ви розумієте гарантії, які вона пропонує, і важливіше те, що воно не гарантує. На прикладі вище такий фреймворк, як Play пропонує засоби зберігання на стороні клієнта , він не скасовує збережені дані через деякий час, але якщо ви змінили стан клієнтської сторони, зловмисник може відновити попередній стан, не помічаючи цього.

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

Якщо з якихось причин ви не можете використовувати криптобібліотеку високого рівня, наприклад, тому що вам потрібно певним чином взаємодіяти з існуючою системою, немає ніякого способу повного навчання. Рекомендую прочитати інженерію криптографії Фергюсона, Коно та Шнейєра . Будь ласка, не обманюйте себе, вважаючи, що ви можете створити захищену систему без необхідних підстав. Криптографія надзвичайно тонка, і перевірити безпеку системи майже неможливо.

Порівняння режимів

Лише шифрування:

• Режими, які вимагають заміщення : Як і в прикладі, прокладка може бути небезпечною, оскільки відкриває можливість окулярів. Найпростіший захист - це автентифікація кожного повідомлення перед розшифровкою. Дивись нижче.
  • ЄЦБ шифрує кожен блок даних незалежно, і той самий блок простого тексту буде призводити до того ж блоку шифротексту. Погляньте на зашифрований ЄЦБ образ Tux на сторінці Вікіпедії ЄЦБ, щоб побачити, чому це серйозна проблема. Я не знаю жодного випадку використання, де ЄЦБ було б прийнятним.
  • CBC має IV і тому потребує випадковості кожного разу, коли повідомлення шифрується, зміна частини повідомлення вимагає повторного шифрування всього після зміни, помилки передачі в одному блоці шифротексту повністю руйнують простий текст і змінюють дешифрування наступного блоку, дешифрування може бути паралелізовано / шифрування не може, простий текст в певній мірі піддатний - це може бути проблемою .
• Режими шифрування потоку : ці режими генерують псевдо випадковий потік даних, який може або не залежить від простого тексту. Аналогічно шифровим потокам, як правило, генерований псевдо випадковий потік XORed з простим текстом для генерації шифротексту. Оскільки ви можете використовувати скільки завгодно бітів випадкового потоку, вам взагалі не потрібно. Недоліком цієї простоти є те, що шифрування повністю придатне, що означає, що дешифрування може бути змінено зловмисником будь-яким способом, який йому подобається, як для простого p1, шифротексту c1 та псевдослучайного потоку r та зловмисник може вибрати різницю d таку, що дешифрування шифротексту c2 = c1⊕d є p2 = p1⊕d, так як p2 = c2⊕r = (c1 ⊕ d) ⊕ r = d ⊕ (c1 ⊕ r). Крім того, той самий псевдо випадковий потік ніколи не повинен використовуватися двічі, ніж для двох шифротекстів c1 = p1⊕r і c2 = p2⊕r, зловмисник може обчислити xor двох простих експресів як c1⊕c2 = p1⊕r⊕p2⊕r = p1⊕p2. Це також означає, що зміна повідомлення вимагає повного повторного шифрування, якщо зловмисник міг отримати оригінальне повідомлення. Усі наступні режими парових шифрів потребують лише операції шифрування блочного шифру, тому залежно від шифру це може заощадити деякий простір (кремній чи машинний код) у надзвичайно обмежених умовах.
  • CTR є простим, він створює псевдо випадковий потік, який не залежить від прямого тексту, різні псевдовипадкові потоки отримуються шляхом підрахунку від різних значень / IV, які множать на максимальну довжину повідомлення, щоб запобігти перекриття, використовуючи шифрування повідомлень nonces можливо без випадковості повідомлення, розшифрування та шифрування завершуються паралельно, помилки передачі впливають лише на неправильні біти і більше нічого
  • OFB також створює псевдослучайний потік, незалежний від простого тексту, різні псевдовипадкові потоки отримуються, починаючи з різного безвідповідального чи випадкового IV для кожного повідомлення, ні шифрування, ні дешифрування не є паралельним, як у випадку з CTR, використовуючи шифрування повідомлення, без шифру неможливо без повідомлення випадковість, як і при помилках передачі CTR, впливає лише на неправильні біти і більше нічого
  • Псевдослучайний потік CFB залежить від простого тексту, для кожного повідомлення потрібен різний безвідповідний або випадковий IV, наприклад, для CTR і OFB, використовуючи шифрування повідомлень, без яких-небудь випадків, можливе без випадковості повідомлення, дешифрування є паралелізаційним / шифрування не є, помилки передачі повністю знищити наступний блок, але тільки вплинути на неправильні біти в поточному блоці
• Режими шифрування диска : ці режими спеціалізовані для шифрування даних під абстракцією файлової системи. З міркувань ефективності для зміни деяких даних на диску потрібно лише переписати щонайменше один блок диска (512 байт або 4кіб). Вони не входять до сфери цієї відповіді, оскільки у них значно різні сценарії використання, ніж інші. Не використовуйте їх ні для чого, крім шифрування блокового рівня . Деякі члени: XEX, XTS, LRW.

Підтверджене шифрування:

Щоб запобігти атакам оракул накладки та змінам на шифротекст, ви можете обчислити код автентифікації повідомлення (MAC) на шифротексті та розшифрувати його лише тоді, коли він не був підроблений. Це називається шифрувати-потім-mac і слід віддавати перевагу будь-якому іншому порядку . За винятком дуже мало випадків використання, справжність є такою ж важливою, як і конфіденційність (останній з яких є метою шифрування). Аутентифіковані схеми шифрування (із супутніми даними (AEAD)) поєднують двоскладовий процес шифрування та автентифікації в режимі блочного шифрування, який також створює тег аутентифікації в процесі. У більшості випадків це призводить до підвищення швидкості.

• CCM - це просте поєднання режиму CTR і CBC-MAC. Використовуючи два шифрування блокових шифрів на блок, це дуже повільно.
• OCB швидше, але обтяжена патентами. Для вільного (як на волі) або невійськового програмного забезпечення власник патенту надав безкоштовну ліцензію .
• GCM - це дуже швидке, але, можливо, складне поєднання режиму CTR і GHASH, MAC над полем Галуа з 2 ^ 128 елементами. Широке його використання у важливих мережевих стандартах, таких як TLS 1.2, відображається спеціальною інструкцією , розробленою Intel для прискорення розрахунку GHASH.

Рекомендація:

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

Офіційний аналіз зробив Філ Рогавей у 2011 році, тут . У розділі 1.6 наведено резюме, яке я перекладаю тут, додаючи власний наголос жирним шрифтом (якщо ви нетерплячі, то його рекомендація - використовувати режим CTR, але я пропоную прочитати мої параграфи про цілісність повідомлення проти шифрування нижче).

Зауважте, що більшість із них вимагає, щоб IV був випадковим, що означає непередбачуваний характер, і тому його слід генерувати з криптографічним захистом. Однак, деякі вимагають лише "ніколи", яке не вимагає цього майна, а вимагає лише його повторного використання. Тому конструкції, які покладаються на ніколи, є менш схильними до помилок, ніж конструкції, які цього не роблять (і повірте, я бачив багато випадків, коли CBC не реалізується при правильному підборі IV). Отже, ви побачите, що я додав сміливий характер, коли Рогавей говорить щось на кшталт "конфіденційність не досягається, коли IV - це нікчемність", це означає, що якщо ви виберете свій IV криптографічно захищений (непередбачуваний), то жодних проблем. Але якщо цього не зробити, ви втрачаєте хороші захисні властивості. Ніколи не використовуйте IV для жодного з цих режимів.

Також важливо зрозуміти різницю між цілісністю повідомлення та шифруванням. Шифрування приховує дані, але зловмисник може змінити зашифровані дані, і результати потенційно можуть бути прийняті вашим програмним забезпеченням, якщо ви не перевірите цілісність повідомлення. Поки розробник скаже «але модифіковані дані повернуться як сміття після розшифровки», хороший інженер з безпеки знайде ймовірність того, що сміття викликає несприятливу поведінку в програмному забезпеченні, і тоді він перетворить цей аналіз у справжню атаку. Я бачив багато випадків, коли шифрування використовувалося, але цілісність повідомлення дійсно була потрібна більше, ніж шифрування. Зрозумійте, що вам потрібно.

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

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

Мені невідомі проблеми ІС.

Тепер до хороших речей професора Рогауей:

Блокуйте режими шифрування, шифрування, але не цілісність повідомлення

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

CBC : схема шифрування на основі IV, режим захищений як імовірнісна схема шифрування, досягаючи нерозрізненості від випадкових бітів, припускаючи випадковий IV. Конфіденційність не досягається, якщо IV - це лише нонсенс , або якщо він не шифрується за тим самим ключем, який використовується у схемі, як неправильно пропонує зробити стандарт. Шифротексти дуже ковкі. Не вибрано захист від шифротекстової атаки (CCA). Конфіденційність втрачається в присутності оракула з правильним набиванням для багатьох методів набивання. Шифрування неефективне від того, що за своєю суттю є послідовним. Широко використовувані властивості безпеки режиму конфіденційності режиму часто призводять до неправильного використання. Може використовуватися як будівельний блок для алгоритмів CBC-MAC. Я не можу визначити жодних важливих переваг перед режимом CTR.

CFB : схема шифрування на основі IV, режим захищений як імовірнісна схема шифрування, досягаючи нерозрізненості від випадкових бітів, припускаючи випадковий IV. Конфіденційність не досягається, якщо IV є передбачуваним , або якщо він зроблений без шифрування, зашифрованого за тим самим ключем, що використовується схемою, як неправильно пропонує зробити стандарт. Шифротексти ковкі. Ніякої CCA-безпеки. Шифрування неефективне від того, що за своєю суттю є послідовним. Схема залежить від параметра s, 1 ≤ s ≤ n, як правило, s = 1 або s = 8. Неефективна потреба в одному виклику блокшифтера для обробки лише s біт. Режим досягає цікавого властивості «самосинхронізації»; вставлення або видалення будь-якої кількості s-бітових символів у шифротекст лише тимчасово порушує правильне розшифрування.

OFB : схема шифрування на основі IV, режим захищений як імовірнісна схема шифрування, досягаючи нерозрізненості від випадкових бітів, припускаючи випадковий IV. Конфіденційність не досягається, якщо IV не має значення, хоча фіксована послідовність IV (наприклад, лічильник) працює нормально. Шифротексти дуже ковкі. Відсутність безпеки CCA. Шифрування та дешифрування неефективні від того, що за своєю суттю є послідовним. Рідно шифрує рядки будь-якої бітової довжини (не потрібні прокладки). Я не можу визначити жодних важливих переваг перед режимом CTR.

CTR : Схема шифрування на основі IV, режим досягає невідрізнення від випадкових бітів, припускаючи відсутність IV. Як безпечна схема, що не базується на даних, режим може також використовуватися як імовірнісна схема шифрування, з випадковим IV. Повний провал конфіденційності, якщо ніколи не буде повторно використане під час шифрування чи розшифрування. Паралелізованість режиму часто робить його швидшим, в деяких настройках набагато швидшим, ніж інші режими конфіденційності. Важливий будівельний блок для схем автентифікованого шифрування. Загалом, як правило, найкращий і найсучасніший спосіб досягти шифрування лише для конфіденційності.

XTS : Схема шифрування на основі IV, режим працює, застосовуючи налаштований блокшифтер (захищений як сильний PRP) до кожного n-бітного блоку. Для повідомлень з довжиною, не поділеною на n, останні два блоки обробляються спеціально. Єдине дозволене використання режиму - це шифрування даних на блоково-накопиченому пристрої зберігання даних. Вузька ширина основного PRP і погана обробка дробових кінцевих блоків є проблемами. Більш ефективний, але менш бажаний, ніж (широкоблочний) PRP-захищений блокшиф.

MAC (цілісність повідомлення, але не шифрування)

ALG1–6 : колекція MAC, всі вони базуються на CBC-MAC. Занадто багато схем. Деякі з них є надійно захищеними як VIL PRF, деякі як FIL PRF, а деякі не мають надійної безпеки. Деякі схеми допускають згубні атаки. Деякі режими датовані. Розмежування ключів недостатньо відвідується для режимів, які його мають. Не слід приймати масово, але можливий вибірковий вибір «найкращих» схем. Також було б непогано приймати жоден із цих режимів на користь CMAC. Деякі з МАС ISO 9797-1 широко стандартизовані та використовуються, особливо в банківській справі. Незабаром буде випущена переглянута версія стандарту (ISO / IEC FDIS 9797-1: 2010) [93].

CMAC : MAC, заснований на CBC-MAC, режим є надійно захищеним (до встановленого дня народження) як (VIL) PRF (якщо вважати, що базовий блокшиффер є хорошим PRP). По суті мінімальні накладні витрати для схеми на основі CBCMAC. По суті, серійний характер є проблемою в деяких областях додатків, а використання 64-бітного блочного коду вимагає періодичної повторної клавіші. Чистіше, ніж колекція MAC ISO 9797-1.

HMAC : MAC, що базується на криптографічній хеш-функції, а не на блокшифрі (хоча більшість криптографічних хеш-функцій самі базуються на blockciphers). Механізм має сильні межі надійної безпеки, хоча і не з переважних припущень. Кілька тісно пов'язаних між собою варіантів літератури ускладнюють розуміння того, що відомо. Жодних згубних атак ніколи не було запропоновано. Широко стандартизовані та використовувані.

GMAC : MAC, що не базується на інформації, що є особливим випадком GCM. Успадковує багато хороших та поганих характеристик GCM. Але жодна вимога не потрібна для MAC, і тут вона купує мало користі. Практичні атаки, якщо теги обрізані до ≤ 64 біт і ступінь розшифровки не контролюється та зменшується. Повний збій при безвідмовному використанні. Використання все одно неявне, якщо прийнято GCM. Не рекомендується для окремої стандартизації.

аутентифіковане шифрування (і шифрування, і цілісність повідомлення)

CCM : схема, що базується на AEAD, яка не базується на даних, що поєднує шифрування режиму CTR та необроблений CBC-MAC. По суті серійний, обмежуючи швидкість у деяких контекстах. Достовірно безпечний, з хорошими межами, якщо припустити, що базовий блокшиф є хорошим PRP. Невдала конструкція, яка наочно виконує роботу. Простіший у застосуванні, ніж GCM. Можна використовувати як MAC на основі бездисперсного використання. Широко стандартизовані та використовувані.

GCM : схема на основі AEAD, що базується на принципах, що поєднує шифрування режиму CTR та універсальну хеш-функцію на основі GF (2128). Хороші характеристики ефективності для деяких середовищ реалізації. Хороші доказово-безпечні результати за умови мінімального усічення тегів. Атаки та погані межі доказувальної безпеки за наявності значних усікань тегів. Може використовуватися як MAC, що не базується на роботі, який потім називається GMAC. Сумнівний вибір, щоб дозволити, крім 96-біт. Рекомендуйте обмежувати значення без 96-біт, а мітки - принаймні 96 бітами. Широко стандартизовані та використовувані.

1. Все, крім ЄЦБ.
2. Якщо ви використовуєте CTR, обов'язково потрібно використовувати інший ІV для кожного повідомлення, інакше ви зловмисником зможете взяти два шифротексти та отримати комбінований незашифрований простий текст. Причина полягає в тому, що режим CTR по суті перетворює блок-шифр в шифр потоку, і перше правило потокових шифрів - ніколи не використовувати один і той же Key + IV двічі.
3. Справді не так вже й велика різниця в тому, наскільки складні режими реалізовані. Деякі режими вимагають, щоб блок-шифр працював лише в напрямку шифрування. Однак більшість блокових шифрів, включаючи AES, не потребують значно більше коду для здійснення дешифрування.
4. Для всіх режимів шифрування важливо використовувати різні ІV для кожного повідомлення, якщо ваші повідомлення можуть бути однаковими в перших кількох байтах, і ви не хочете, щоб зловмисник знав це.

Ви почали з читання інформації про це у Вікіпедії - Блокувати шифрові режими роботи ? Потім перейдіть за посиланням у Вікіпедії на NIST: Рекомендація щодо режимів роботи блокових шифрів .

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

Обмеження обладнання

STM32L (low energy ARM cores) from ST Micro support ECB, CBC,CTR GCM
CC2541 (Bluetooth Low Energy) from TI supports ECB, CBC, CFB, OFB, CTR, and CBC-MAC

Обмеження з відкритим кодом

Original rijndael-api source  - ECB, CBC, CFB1
OpenSSL - command line CBC, CFB, CFB1, CFB8, ECB, OFB
OpenSSL - C/C++ API    CBC, CFB, CFB1, CFB8, ECB, OFB and CTR
EFAES lib [1] - ECB, CBC, PCBC, OFB, CFB, CRT ([sic] CTR mispelled)  
OpenAES [2] - ECB, CBC 

[1] http://www.codeproject.com/Articles/57478/A-Fast-and-Easy-to-Use-AES-Library

[2] https://openaes.googlecode.com/files/OpenAES-0.8.0.zip

Я знаю один аспект: Хоча CBC забезпечує кращу безпеку, змінюючи IV для кожного блоку, він не застосовується до випадкового доступу до зашифрованого вмісту (як-от зашифрований жорсткий диск).

Отже, використовуйте CBC (та інші послідовні режими) для послідовних потоків та ECB для випадкового доступу.