Блочные шифры: ECB, CBC и padding oracle

Блочный шифр сам по себе умеет ровно одно: превратить шестнадцать байт в шестнадцать байт и обратно. Всё остальное — режим работы. Режим решает, как связать блоки, откуда взять случайность и что произойдёт, если противник изменит один байт. Тема показывает, что слабость почти никогда не сидит в AES: она сидит в том, как его вызвали.

Разбор идёт по возрастанию сложности. Сначала ECB, где одинаковые блоки открытого текста дают одинаковые блоки шифртекста, и отсюда сразу следуют две атаки: распознавание структуры данных и перестановка блоков. Потом CBC, где цепочка прячет повторы, но добавляет предсказуемую реакцию на изменение предыдущего блока. Кульминация — оракул дополнения: сервер, который на неверное дополнение отвечает одним битом «ошибка», позволяет расшифровать весь токен без ключа. Это одна из самых разрушительных ошибок проектирования в веб-приложениях, и она до сих пор встречается в самописных форматах.

Что такое режим работы

Блочный шифр как перестановка

AES с ключом K — перестановка на множестве 128-битных блоков: E_K: {0,1}^128 → {0,1}^128. Она детерминирована: один и тот же блок при одном ключе всегда даёт один и тот же результат. Это не недостаток шифра, а его определение, и именно это свойство режимы обязаны нейтрализовать.

Сообщение произвольной длины разбивается на блоки, при необходимости дополняется по схеме PKCS#7 (k байт со значением k, где 1 ≤ k ≤ 16), и каждый блок шифруется. Способ, которым режим связывает блоки и вносит случайность, определяет и стойкость, и цену.

Свойства, которые нужны режиму

Хороший режим даёт три вещи: разные шифртексты для одинаковых сообщений (рандомизация через IV, nonce или счётчик), отсутствие утечки структуры (блоки не должны повторяться там, где повторяется открытый текст) и, в идеале, обнаруживаемую целостность. Последнее режим шифрования сам по себе не даёт: ECB, CBC и CTR конфиденциальны, но не аутентифицированы, и это источник большинства атак темы.

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

ECB: детерминированность и её последствия

Одинаковые блоки видны

В режиме ECB каждый блок шифруется независимо: C_i = E_K(P_i). Одинаковые 16-байтовые фрагменты открытого текста дают одинаковые блоки шифртекста. Если данные имеют структуру — изображение, таблица, повторяющиеся поля, — она проступает сквозь шифрование.

Канонический пример — «ECB-пингвин»: изображение, зашифрованное ECB, сохраняет контуры, потому что области с одинаковым цветом состоят из одинаковых блоков ⁸. На рисунке 1 показано, как повторяющиеся блоки складываются в узнаваемый силуэт.

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

Перестановка блоков

Второе следствие — блоки можно тасовать и склеивать. Если приложение шифрует структуру вида email=<адрес>&uid=10&role=user, противник не знает ключ, но может собрать токен из кусков чужих токенов. Это атака «вырезать и вставить»: подбираются два адреса так, чтобы нужные поля оказались на границах блоков, после чего блок с admin переносится в конец другого токена.

Атака работает без ключа и без оракула, потому что ECB не связывает блоки между собой: каждый блок действителен сам по себе. Пошаговые учебные задачи на эту схему собраны в наборе Cryptopals ⁶. Защита — либо AEAD, либо связывание блоков (CBC с MAC), либо контроль целостности на уровне протокола.

CBC: цепочка и её цена

Как устроена цепочка

В CBC каждый блок открытого текста складывается с предыдущим шифртекстом и только потом шифруется: C_i = E_K(P_i ⊕ C_{i-1}), где C_0 = IV. Одинаковые блоки открытого текста дают разные шифртексты, структура скрыта, а IV должен быть случайным и непредсказуемым ¹.

Обратная операция: P_i = D_K(C_i) ⊕ C_{i-1}. Из этой формулы видно главное свойство: изменение байта в C_{i-1} предсказуемо меняет соответствующий байт P_i, а сам C_i при этом остаётся валидным. Целостности нет — есть предсказуемость.

Бит-флиппинг в CBC

Пусть противник знает открытый текст блока i и хочет заменить role=user на role=admin. Он вычисляет Δ = P_i ⊕ P_i' и накладывает Δ на C_{i-1}. После расшифрования блок i станет желаемым, а блок i-1 превратится в мусор — часто это приемлемая цена, особенно если мусор попадает в поле, которое не проверяется. На рисунке 2 показано, какие блоки портятся.

Для первого блока роль предыдущего играет IV: если IV передан вместе с шифртекстом и не проверяется, его можно менять так же свободно. Отсюда правило: IV аутентифицируется вместе с данными, иначе он не отличается от ещё одного блока шифртекста.

Оракул дополнения

Идея атаки

Сервер, который после расшифрования проверяет дополнение PKCS#7, знает больше, чем говорит: он различает «дополнение верное» и «дополнение неверное». Если эта разница видна снаружи — кодом ответа, текстом ошибки, временем, — возникает оракул. Ваденай доказал, что одного бита достаточно для полного восстановления открытого текста ².

Механика опирается на формулу P_i = D_K(C_i) ⊕ C_{i-1}. Противник не может вычислить D_K(C_i), но может подставлять разные C_{i-1} и спрашивать: «дополнение верное?». Перебирая последний байт предыдущего блока, он находит значение, при котором последний байт открытого текста равен 0x01, — это единственный случай, когда дополнение из одного байта верно. Отсюда D_K(C_i) в последней позиции, а значит, и байт открытого текста.

Дальше — итеративно: зафиксировав последний байт как 0x02, перебирается предпоследний, потом 0x03, и так до начала блока. В среднем около 128 запросов на байт, то есть примерно 2000–4000 на блок; для токена из трёх блоков это несколько тысяч запросов и несколько секунд. На рисунке 3 — схема шага.

Разновидности и реальные инциденты

Оракул не обязан быть явным. POODLE (2014) использовал различие в реакции на дополнение в SSL 3.0 и позволял постепенно раскрывать cookie ³. Lucky13 (2013) эксплуатировал разницу во времени вычисления MAC в TLS ⁴. В ASP.NET ошибка обработки дополнения (CVE-2010-3332) давала оракул через коды ответа и позволяла читать и подделывать аутентификационные cookie ⁵.

Общее у всех случаев: разработчик считал, что «сообщение об ошибке дополнения» — безобидная диагностика, а на деле это канал утечки. Защита: не различать причины отказа, использовать AEAD, проверять MAC до расшифрования (encrypt-then-MAC), а для CBC — константное по времени сравнение и единый ответ на любую ошибку.

Почему оракул так опасен

Стойкость AES здесь ни при чём: ключ не перебирается и не компрометируется. Утекает не ключ, а функция расшифрования, доступная по одному биту за запрос. Это иллюстрация общего принципа: криптографическая система ломается на стыке примитива и протокола, а не в примитиве.

CTR и почему это не выход

CTR превращает блочный шифр в поточный: C_i = P_i ⊕ E_K(T_i), где T_i — счётчик. Он параллелится, не требует дополнения и не распространяет ошибку дальше одного блока. Но у него те же две болезни, что у поточного шифра: изменение бита шифртекста меняет тот же бит открытого текста, а повтор счётчика с тем же ключом даёт повтор потока. Дополнения нет, поэтому оракула дополнения нет, но есть побитовая подмена и повтор nonce.

Именно поэтому CTR и CBC в современном виде почти всегда используются внутри AEAD: сравнение режимов по свойствам, включая изменяемость, есть у Рогавея ⁷: GCM = CTR + GHASH, CCM = CTR + CBC-MAC. Конфиденциальность обеспечивает режим, целостность — отдельная конструкция, и проверка целостности должна происходить до того, как открытый текст попадёт в разбор полей.

Требования к IV и nonce по режимам

Сводка, к которой стоит возвращаться при выборе режима: требования разные, и «случайный IV» — не универсальный ответ.

Ключевая мысль: CBC требует непредсказуемости, CTR и AEAD — уникальности. Это разные свойства, и режим, стойкий при случайном IV, может быть катастрофически нестойким при счётчике, который сбрасывается после перезапуска.

Итоги темы

• Блочный шифр детерминирован; режим обязан добавить рандомизацию и связывание.
• ECB не скрывает структуру и позволяет переставлять блоки; атака «вырезать и вставить» не требует ключа.
• CBC скрывает повторы, но предсказуемо реагирует на изменение предыдущего блока; IV — часть шифртекста и должен аутентифицироваться.
• Один бит информации о дополнении даёт полное восстановление открытого текста; оракул может быть в коде ответа, тексте ошибки или времени.
• CTR наследует свойства поточного шифра: побитовая подмена и повтор счётчика.
• Лечение общее: AEAD, encrypt-then-MAC, единообразные ошибки, константное время.

Литература

1. NIST. SP 800-38A: Recommendation for Block Cipher Modes of Operation. 2001. — режимы ECB, CBC, CFB, OFB, CTR и их тестовые векторы.
2. Vaudenay S. Security Flaws Induced by CBC Padding — Applications to SSL, IPSEC, WTLS. EUROCRYPT 2002. — исходная работа об оракуле дополнения.
3. Möller B., Duong T., Kotowicz A. This POODLE Bites: Exploiting the SSL 3.0 Fallback. 2014. — атака на дополнение в SSL 3.0.
4. AlFardan N., Paterson K. Lucky Thirteen: Breaking the TLS and DTLS Record Protocols. IEEE S&P 2013. — тайминговая атака на CBC-MAC в TLS.
5. Microsoft. MS10-070: Vulnerability in ASP.NET Could Allow Information Disclosure. 2010. — оракул дополнения в ASP.NET.
6. Cryptopals Crypto Challenges. Set 2, challenges 9–16. — учебные задачи на PKCS#7, CBC и cut-and-paste.
7. Rogaway P. Evaluation of Some Blockcipher Modes of Operation. 2011. — сравнение режимов по свойствам, включая malleability.
8. Lucas P. ECB Penguin. 2011. — наглядная демонстрация утечки структуры изображения в ECB.

Дополнительные материалы к апокрифу 5

Вопросы для самопроверки

1. Чем режим работы отличается от самого блочного шифра и кто отвечает за рандомизацию?
2. Почему ECB нарушает семантическую стойкость, даже если AES не взломан?
3. Как из двух токенов ECB собирается третий, валидный для сервиса?
4. Зачем в CBC нужен IV и почему он не может быть предсказуемым?
5. Почему в CBC изменение предыдущего блока портит ровно один блок открытого текста?
6. Что такое оракул дополнения и какие каналы его создают?
7. Почему для оракула достаточно одного бита информации?
8. Как отличить ложное срабатывание при подборе последнего байта?
9. Сколько в среднем запросов нужно на один байт и на блок?
10. Почему CTR не страдает от оракула дополнения, но страдает от повтора счётчика?
11. Что даёт encrypt-then-MAC по сравнению с MAC-then-encrypt?
12. Почему сравнение тега должно быть константным по времени?
13. Какие режимы входят в TLS 1.3 и почему остальные оттуда убраны?
14. Что служило оракулом в POODLE и как откат к SSL 3.0 делал атаку возможной?

Глоссарий темы

Шпаргалка

cp modes_template.py modes.py           && python3 check_modes.py
python3 gen_image.py seif.ppm
python3 encrypt_image.py ecb seif.ppm ecb.ppm && python3 ppm2png.py ecb.ppm ecb.png
python3 encrypt_image.py cbc seif.ppm cbc.ppm && python3 ppm2png.py cbc.ppm cbc.png
cp cutpaste_template.py cutpaste.py     && python3 check_attacks.py
cp oracle_attack_template.py oracle_attack.py && python3 oracle_attack.py
python3 check_oracle.py

Что почитать и посмотреть

• NIST SP 800-38A — режимы и тестовые векторы; лучший источник для проверки реализации.
• NIST SP 800-38D — GCM и требования к nonce; читать вместе с темой 6.
• Vaudenay S. Security Flaws Induced by CBC Padding (EUROCRYPT 2002) — исходная работа об оракуле.
• Möller, Duong, Kotowicz. This POODLE Bites (2014) — как откат версии протокола превращает ошибку в эксплойт.
• AlFardan, Paterson. Lucky Thirteen (2013) — тайминговый оракул в TLS.
• Microsoft MS10-070 — разбор ASP.NET-инцидента и его последствий.
• Rogaway P. Evaluation of Some Blockcipher Modes of Operation (2011) — сравнение режимов по свойствам.
• Cryptopals Set 2 — задачи 9–16; полезно пройти целиком после этой работы.
• Документация cryptography по режимам — https://cryptography.io/en/latest/hazmat/primitives/symmetric-encryption/.

Углубление: почему одного бита достаточно

Формально оракул дополнения — это функция O(C), которая возвращает 1, если дополнение расшифрованного C корректно, и 0 иначе. Противник не знает K, но получает адаптивный доступ к O. Атака восстанавливает D_K(C_i) побайтово, потому что условие «дополнение корректно» при известном числе верных байт превращается в проверку одного байта.

Пусть противник уже знает k последних байт открытого текста и хочет узнать (k+1)-й с конца. Он формирует C_(i−1) так, чтобы последние k байт открытого текста были равны k+1, и перебирает очередной байт. Оракул срабатывает, когда дополнение становится корректным, то есть когда (k+1)-й байт открытого текста равен k+1. Это даёт ровно один байт D_K(C_i) за проход по 256 значениям, а значит, и байт открытого текста.

Информационная оценка: каждый запрос даёт не более одного бита, но и не меньше, чем нужно для локализации одного байта при известном контексте. В среднем на байт уходит около 128 запросов; на блок из 16 байт — около 2000. Сложность линейна по длине сообщения, а не экспоненциальна, поэтому даже медленный канал (страница входа, отвечающая за 100 мс) даёт полное восстановление токена за минуты.

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

Углубление: ECB и целостность — разные свойства

Может показаться, что «вырезать и вставить» — это атака на целостность, и достаточно добавить MAC. Это верно, но полезно разделить два свойства. Семантическая стойкость отвечает на вопрос «можно ли отличить шифртексты двух сообщений»; в ECB она нарушена всегда, даже без активных действий противника. Целостность отвечает на вопрос «можно ли незаметно изменить данные»; в ECB и CBC она не обеспечена, и именно поэтому перестановка блоков проходит.

AEAD закрывает оба свойства одновременно: GCM шифрует в CTR и аутентифицирует всё сообщение вместе с заголовком, поэтому ни повторы, ни перестановки не проходят. Encrypt-then-MAC закрывает целостность, но требует дисциплины: MAC считается по IV и шифртексту, проверяется до расшифрования, сравнение — константное. Исторический MAC-then-encrypt (как в TLS до 1.3) оставлял оракул дополнения, и именно это стало источником POODLE и Lucky13.

Правило, которое стоит вынести из темы: криптографическая конструкция оценивается не по примитиву, а по тому, какие ошибки она делает невозможными. AES в ECB — это по-прежнему AES; проблема в том, что режим не мешает разработчику выстрелить себе в ногу.

Лабораторная работа 5. Режим работы решает всё

• Раздел курса: апокриф 5 «Блочные шифры: ECB, CBC и padding oracle»

Введение

В «Сейфе» хранятся профили пользователей, сессии и несколько картинок-вложений. Шифрует их AES — правильный, библиотечный, без самодеятельности. А ломается всё равно: профиль шифруется в ECB, поэтому поле role можно переставить из чужого токена; сессия шифруется в CBC, и сервис отвечает разными сообщениями на «плохое дополнение» и «плохой формат», поэтому токен расшифровывается без ключа.

Работа идёт от примитива к протоколу. Сначала собственные ECB, CBC и CTR по тестовым векторам NIST: пока режим не написан руками, разговор об атаках остаётся абстрактным. Затем ECB-детерминизм и атака «вырезать и вставить», потом оракул дополнения — самая результативная из ошибок этой темы. В продвинутой части — CBC-битфлиппинг на cookie и сборка encrypt-then-MAC как защиты.

Части: PKCS#7 и режимы, ECB и структура данных, «вырезать и вставить», оракул дополнения, CBC-битфлиппинг, продвинутая.

Цель работы

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

После выполнения работы получится:

• реализовывать PKCS#7, ECB, CBC и CTR и сверять их с тестовыми векторами NIST;
• показывать утечку структуры в ECB на реальном изображении;
• собирать валидный токен с role=admin из фрагментов чужих токенов;
• расшифровывать токен с CBC целиком через оракул дополнения;
• предсказуемо менять поле в CBC, зная открытый текст;
• формулировать три разных исправления: AEAD, encrypt-then-MAC и единообразные ошибки.

Теоретический минимум

Разделы «Что такое режим работы», «ECB: детерминированность и её последствия», «CBC: цепочка и её цена», «Оракул дополнения», «CTR и почему это не выход» апокрифа 5. Формулы:

ECB:  C_i = E_K(P_i)
CBC:  C_i = E_K(P_i ⊕ C_(i−1)),  P_i = D_K(C_i) ⊕ C_(i−1)
CTR:  C_i = P_i ⊕ E_K(T_i)
PKCS#7: дописать k байт со значением k, 1 ≤ k ≤ 16

Перечень оснащения

Ubuntu 24.04, Python 3.10+, cryptography, openssl. Права root не нужны. Архив lr-env.

mkdir -p ~/lab-apocrypha-05 && cd ~/lab-apocrypha-05
unzip ~/lr-env.zip
cp modes_template.py modes.py
python3 check_modes.py

Заготовки копируются в файлы без суффикса _template: modes.py, cutpaste.py, oracle_attack.py. Проверки ищут именно эти имена.

Порядок выполнения работы

В журнал записывайте: номер блока, который менялся, найденный байт (для оракула — номер запроса, на котором сработало), число запросов и итоговое поле профиля. Для каждой атаки — что именно утекло: структура, целостность или открытый текст.

Часть 1. PKCS#7 и режимы

Задание

1. Реализуйте pkcs7_pad, pkcs7_unpad с проверкой всех условий: длина кратна блоку, k в диапазоне 1…16, все последние k байт равны k.
2. Реализуйте ecb_encrypt, ecb_decrypt, cbc_encrypt, cbc_decrypt, ctr_crypt через aes_block_encrypt и aes_block_decrypt.
3. Запустите python3 check_modes.py: девять тестов на векторах NIST SP 800-38A и сравнение с библиотекой.
4. Проверьте CTR на данных, длина которых не кратна 16: последний блок ключевого потока должен усекаться.
5. Ответьте: почему в CTR счётчик обязан быть уникальным для каждого сообщения, а в CBC достаточно случайного IV?
6. Объясните, почему pkcs7_unpad не должен сообщать наружу, какое именно условие нарушено.

Что должно получиться

Девять пройденных тестов, совпадение с NIST, объяснение разницы между требованиями к IV и к счётчику и вывод о том, что детали ошибки дополнения — это канал утечки.

Часть 2. ECB и структура данных

Задание

1. Сгенерируйте изображение: python3 gen_image.py seif.ppm. Оно содержит области одного цвета и текст.
2. Зашифруйте тело тремя режимами: python3 encrypt_image.py ecb seif.ppm ecb.ppm, затем cbc, затем ctr.
3. Конвертируйте результаты в PNG: python3 ppm2png.py ecb.ppm ecb.png и так далее.
4. Сравните картинки. В ECB контуры и заливки видны, в CBC и CTR — нет.
5. Запустите python3 check_attacks.py и посмотрите раздел «часть 2»: проверка подтверждает, что ECB даёт повтор блока, а CBC — нет.
6. Объясните, почему утечка структуры — это нарушение семантической стойкости, даже если ключ не скомпрометирован.

Что должно получиться

Три PNG, на которых видно разницу, и вывод: ECB шифрует блоки, а не сообщение, поэтому равенство блоков открытого текста становится видимым.

Часть 3. Вырезать и вставить

Задание

1. Изучите token_service.py: профиль кодируется как email=<адрес>&uid=10&role=user, дополняется и шифруется в ECB. Сервис доверяет полю role.
2. Реализуйте forge_admin_token(profile_for) в cutpaste.py. Разрешено вызывать только profile_for и encode_profile.
3. Подберите первый адрес так, чтобы второй блок открытого текста был ровно admin + дополнение 0x0b × 11. Символы & и = из адреса удаляются, но управляющие байты проходят.
4. Подберите второй адрес так, чтобы &uid=10&role= заканчивалось ровно на границе блока. Склейте начало второго токена с блоком из первого.
5. Запустите python3 check_attacks.py: сервис должен увидеть role=admin и uid=10.
6. Ответьте: почему атака не требует ни ключа, ни оракула и почему CBC её усложняет, но не отменяет.

Что должно получиться

Поддельный токен, который сервис принимает как администраторский, и понимание, что ECB позволяет переставлять блоки, потому что не связывает их.

Часть 4. Оракул дополнения

Задание

1. Изучите padding_service.py: encrypt возвращает iv || ciphertext, decrypt_oracle отвечает одним битом — верно ли дополнение.
2. Реализуйте split_token, xor_bytes, recover_block, decrypt в oracle_attack.py.
3. В recover_block идите с последнего байта: для позиции j подставляйте кандидаты в предыдущий блок, пока оракул не скажет «верно». Для последнего байта разберите ложное срабатывание: измените байт слева — при настоящем дополнении 0x01 оракул останется доволен.
4. Зафиксировав байт, переходите к следующему: mod[k] = D[k] ⊕ (pad + 1).
5. Запустите python3 oracle_attack.py, затем python3 check_oracle.py. Проверка шифрует три случайных сообщения и требует точного совпадения.
6. Запишите число запросов на блок. Оцените, сколько времени займёт атака на токен из десяти блоков при 100 запросах в секунду.
7. Ответьте: что именно утекло — ключ, открытый текст или функция? Почему единый текст ошибки закрывает атаку, а «правильный» AES не помогает?

Что должно получиться

Расшифрованный токен, совпадающий с исходным, число запросов (порядка двух-четырёх тысяч на блок) и вывод: утекает не ключ, а оракул.

Часть 5. CBC-битфлиппинг

Задание

1. Сервис token_service.py работает в ECB; соберите рядом маленький CBC-сервис: encrypt(profile) с случайным IV и parse(token), который проверяет только дополнение и формат.
2. Зная открытый текст role=user и его позицию, вычислите Δ = role=user ⊕ role=admin и наложите на предыдущий блок шифртекста.
3. Проверьте: сервис видит role=admin, хотя ключ не менялся. Зафиксируйте, какой блок при этом разрушился.
4. Повторите для первого блока: измените IV. Объясните, почему IV нельзя считать «просто числом» и почему его аутентифицируют вместе с данными.
5. Сравните: в ECB перестановка блоков, в CBC — правка предыдущего блока. Что общего у обеих атак?

Что должно получиться

Работающая подмена поля в CBC, описание разрушенного блока и вывод о том, что CBC скрывает структуру, но не защищает целостность.

Часть 6. Продвинутая: как это лечат

Задание

1. Соберите схему encrypt-then-MAC: ct = CBC(K1, pt), tag = HMAC(K2, iv || ct), проверка тега до расшифрования. Покажите, что подделка из части 5 отвергается.
2. Соберите то же на AES-GCM и сравните размер кода и число мест, где можно ошибиться.
3. Измените padding_service.py так, чтобы он возвращал один и тот же ответ на любую ошибку и работал за одинаковое время. Убедитесь, что check_oracle.py перестаёт давать результат (это ожидаемо: оракула больше нет).
4. Разберите один реальный инцидент: POODLE, Lucky13 или CVE-2010-3332. Выпишите, что именно служило оракулом и какое изменение протокола его закрыло.
5. Сформулируйте чек-лист из пяти пунктов для ревью кода, который шифрует данные: что проверять в режиме, в IV, в обработке ошибок, в порядке MAC и в способе сравнения тега.

Что должно получиться

Работающая encrypt-then-MAC схема, отвергающая подделку, сравнение с GCM, нейтрализованный оракул и чек-лист, пригодный для реального ревью.

Журнал работы

Фиксируйте: какой блок менялся, какое значение подбиралось, сколько запросов понадобилось, что увидел сервис. Провал проверки записывайте причиной — неверная граница блока, перепутан порядок D(C) ⊕ prev, не учтено ложное срабатывание дополнения, — а не отметкой «не вышло».

Контрольные вопросы

1. Почему блочный шифр нуждается в режиме работы?
2. Что именно утекает в ECB и почему это нарушает семантическую стойкость?
3. Как атака «вырезать и вставить» обходится без ключа?
4. Зачем в CBC нужен случайный IV и почему он должен аутентифицироваться?
5. Почему изменение C_(i−1) предсказуемо меняет P_i?
6. Что такое оракул дополнения и почему одного бита достаточно?
7. Как отличить настоящее дополнение 0x01 от ложного 0x02?
8. Почему CTR не даёт оракула дополнения, но не решает проблему целостности?
9. Чем encrypt-then-MAC лучше MAC-then-encrypt?
10. Почему GCM закрывает обе атаки темы сразу?
11. Что общего у POODLE, Lucky13 и CVE-2010-3332?
12. Какое минимальное изменение протокола закрывает атаку из части 3?