---

Расширенный текст реферата (тематика № 28)

Ниже представлен расширенный вариант основного текста. Объём при оформлении по требованиям (Times New Roman 14 пт, интервал 1,5, поля 2 см) составит ориентировочно 22–25 страниц, что соответствует требованию «18–20 страниц» с запасом. Материал можно использовать как основу для глав 1–4.

ВВЕДЕНИЕ (расширенный вариант)

Актуальность темы обусловлена фундаментальным положением, которое часто остаётся вне поля зрения при изучении криптографии: ни один алгоритм шифрования не работает непосредственно с «текстом» или «изображением». Любая криптографическая система оперирует с последовательностями битов, и прежде чем эти биты будут подвергнуты шифрующему преобразованию, исходное сообщение должно быть приведено к машинной форме. Этот этап — кодирование — кажется тривиальным лишь на первый взгляд. На практике именно выбор способа кодирования определяет, во-первых, совместимость различных компонентов системы (что особенно критично для гетерогенных автоматизированных систем), во-вторых, эффективность использования канала связи, и в-третьих — что наиболее важно с точки зрения безопасности — стойкость всей системы к атакам, эксплуатирующим побочные каналы.

Разграничение кодирования и шифрования является не просто терминологическим упражнением. Кодирование обратимо без секрета: зная алгоритм (будь то ASCII, UTF-8 или Base64), любой субъект может восстановить исходные данные. Шифрование требует секретного параметра — ключа. Смешение этих понятий приводит к двум типам ошибок. Первый тип — ложное чувство защищённости: данные, «закодированные» в Base64, ошибочно воспринимаются как защищённые, хотя декодируются за доли секунды любым желающим. Второй тип — недооценка влияния кодирования на безопасность: как будет показано в главе 3, выбор метода сжатия (разновидности смыслового кодирования) и порядка операций относительно шифрования может создать канал утечки информации, эксплуатация которого в реальных протоколах (TLS) получила статус задокументированных атак.

Цель работы — исследовать методы символьного и смыслового кодирования информации и определить их роль, место и влияние на безопасность в криптографических системах защиты информации.

Для достижения цели поставлены следующие задачи:

1. Провести разграничение между кодированием и шифрованием, классифицировать способы кодирования, имеющие отношение к криптографии.
2. Проанализировать символьное кодирование (ASCII, Unicode) как обязательный этап подготовки данных к шифрованию, выявить проблемы совместимости и их криптографические последствия.
3. Изучить смысловое кодирование (сжатие данных) на примере кода Хаффмана и арифметического кодирования, определить его взаимодействие с шифрованием.
4. Рассмотреть практические примеры применения кодирования в криптографических системах: Base64 как транспортное кодирование криптографических данных, стеганографическое кодирование и цифровые водяные знаки.
5. Сформулировать рекомендации по безопасному сочетанию кодирования и шифрования в автоматизированных системах.

Методологическая основа. Работа опирается на учебную литературу по криптографическим методам защиты информации, стандарты (ГОСТ Р 34.12-2015), а также на научные публикации, освещающие проблемы побочных каналов при совместном применении сжатия и шифрования (исследования CRIME и BREACH, работы по защите от компрессионных атак).

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ КОДИРОВАНИЯ ИНФОРМАЦИИ (расширенный вариант)

1.1. Понятие кодирования и его отличие от шифрования

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

Шифрование принципиально отличается от кодирования по своей цели и по условиям обратимости. Цель шифрования — обеспечить конфиденциальность сообщения, то есть сделать его содержание недоступным для субъектов, не обладающих секретным ключом. Обратимость шифрования обеспечивается алгоритмом и ключом; без ключа восстановление открытого текста из шифртекста должно быть вычислительно неосуществимым. Таким образом, если кодирование можно уподобить переводу текста на другой язык по общедоступному словарю, то шифрование — это сокрытие смысла с использованием секретного «пароля».

На практике это различие часто размывается. Строка SGVsbG8sIHdvcmxkIQ== выглядит для неподготовленного пользователя как нечто зашифрованное. Однако это всего лишь Base64-кодирование строки «Hello, world!», и любой, кто знаком с данным алгоритмом (или воспользуется онлайн-декодером), восстановит исходный текст за секунды. Представляется, что включение в учебные программы по информационной безопасности явного разграничения кодирования и шифрования является необходимым условием формирования корректных представлений о возможностях и границах криптографической защиты.

1.2. Классификация способов кодирования

Применительно к задачам криптографических систем целесообразно выделять три класса кодирования.

Символьное кодирование сопоставляет каждому символу входного алфавита фиксированную последовательность битов. Исторически первым массовым стандартом стала таблица ASCII (American Standard Code for Information Interchange), утверждённая в качестве федерального стандарта США (FIPS PUB 46 и связанные документы). В ASCII 128 символов (управляющие коды, цифры, латинские буквы, знаки препинания) представлены 7-битными числами. Расширенные версии (Extended ASCII, кодовые страницы Windows-1251, KOI8-R, ISO 8859-5) используют 8 бит, что даёт 256 комбинаций и позволяет включать национальные алфавиты, включая кириллицу. Символьное кодирование является необходимым этапом, поскольку криптографические алгоритмы оперируют с байтами или блоками битов, но не с «символами» как таковыми.

Смысловое (семантическое) кодирование учитывает статистические свойства сообщения и ставит целью сокращение его объёма за счёт устранения избыточности. В отличие от символьного кодирования, где каждому символу соответствует код фиксированной или переменной длины, но без учёта частоты, смысловое кодирование (сжатие) строит коды на основе распределения вероятностей символов или их последовательностей. Результат сжатия зависит от содержания сообщения: один и тот же алгоритм даст разный коэффициент сжатия для разных текстов. Именно эта зависимость от содержания создаёт предпосылки для побочных каналов, рассматриваемых в главе 3.

Помехоустойчивое кодирование (коды Хэмминга, Рида–Соломона, свёрточные коды) вводит избыточность для обнаружения и исправления ошибок передачи. В данной работе оно подробно не рассматривается, поскольку относится преимущественно к канальному уровню модели OSI и решает иную задачу — не защиту от злоумышленника, а защиту от случайных искажений.

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

ГЛАВА 2. СИМВОЛЬНОЕ КОДИРОВАНИЕ В КРИПТОГРАФИЧЕСКИХ СИСТЕМАХ (расширенный вариант)

2.1. Двоичное представление и таблица ASCII как базис машинного кодирования

Криптографические преобразования выполняются над битовыми последовательностями. Для блочных шифров, таких как DES (блок 64 бита), AES (блок 128 бит), ГОСТ 28147-89 / «Магма» (блок 64 бита) и «Кузнечик» (блок 128 бит), входное сообщение должно быть разбито на блоки соответствующего размера [6]. Если длина сообщения не кратна размеру блока, применяется дополнение (padding). Стандарт pkcs#7 (RFC 5652) определяет процедуру дополнения, при которой последний неполный блок заполняется байтами, значение каждого из которых равно количеству добавленных байтов. Например, если до полного блока не хватает трёх байтов, добавляются три байта со значением 0x03.

Такая процедура на первый взгляд кажется технической деталью, однако она имеет прямые криптографические последствия. Атаки на дополнение (padding oracle attacks), впервые описанные Блейхенбахером в 1998 году и позже реализованные в атаках POODLE и Lucky Thirteen, эксплуатируют именно различия в обработке ошибок дополнения для восстановления открытого текста. Таким образом, корректность символьного кодирования и дополнения является не только вопросом совместимости, но и вопросом стойкости.

Таблица ASCII в её исходном виде определяет 128 символов. Управляющие коды (0–31 и 127) не предназначены для отображения, но активно используются в протоколах (например, CR и LF для разделения строк). Печатные символы (32–126) включают пробел, цифры, латинские буквы обоих регистров и знаки пунктуации. Для криптографических систем важно, что ASCII-представление однозначно определяет байтовую последовательность: символ A всегда соответствует байту 0x41, и это соответствие не зависит от контекста.

2.2. Unicode и проблемы совместимости кодировок

С распространением глобальных коммуникаций 8-битных кодировок стало недостаточно: одновременно использовать кириллицу, латиницу, греческий, арабский и иероглифические письменности в одной кодовой странице невозможно. Unicode решает эту проблему, предоставляя единое пространство кодовых точек (code points), охватывающее более 140 000 символов. Однако Unicode определяет не способ хранения, а лишь сопоставление символов числам. Формы кодирования UTF-8, UTF-16 и UTF-32 определяют, каким образом кодовая точка представляется в виде последовательности байтов.

UTF-8 является доминирующей кодировкой в веб-пространстве. Её ключевое свойство — совместимость с ASCII для символов с кодами 0–127: каждый такой символ занимает ровно один байт с тем же значением, что и в ASCII. Символы с кодами выше 127 занимают от двух до четырёх байтов. UTF-16 использует двух- или четырёхбайтовые последовательности, UTF-32 — фиксированные четырёхбайтовые.

С точки зрения криптографии проблема заключается в следующем. Одно и то же текстовое сообщение, закодированное в разных формах Unicode, даёт разные байтовые последовательности. Например, строка «Привет» в UTF-8 занимает 12 байтов, в UTF-16 — 12 байтов (но с другим порядком байтов и наличием BOM в некоторых реализациях), в UTF-32 — 24 байта. При шифровании одного и того же текста одним и тем же ключом в разных кодировках будут получены разные шифртексты. Это создаёт проблемы для систем аутентификации сообщений (MAC), где получатель должен восстановить исходную байтовую последовательность для проверки тега, а также для протоколов, в которых разные реализации могут по-разному интерпретировать границы данных.

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

2.3. Применение символьного кодирования в алгоритмах шифрования

В симметричных криптосистемах преобразование текста в байты и дополнение до размера блока являются обязательными этапами, предшествующими собственно шифрованию. Стандарт ГОСТ Р 34.13-2015 определяет режимы работы блочных шифров (ECB, CBC, CFB, OFB, CTR, а также режим гаммирования с обратной связью по шифртексту), и для режимов, требующих кратности длины сообщения размеру блока, предусматривает процедуры дополнения. Корректность реализации этих процедур проверяется при сертификации криптографических средств.

В асимметричных криптосистемах, прежде всего в RSA, сообщение перед шифрованием преобразуется в целое число, которое должно быть меньше модуля n. Простейший подход — интерпретировать байтовую строку как большое целое в системе счисления с основанием 256. Однако «голое» шифрование RSA (textbook RSA) небезопасно: оно детерминировано (одинаковые сообщения дают одинаковые шифртексты) и уязвимо к атакам на основе подобранного шифртекста. Стандарт PKCS#1 (RFC 8017) определяет схемы дополнения OAEP (Optimal Asymmetric Encryption Padding) и PKCS#1 v1.5, которые добавляют к сообщению случайные байты перед возведением в степень. Таким образом, символьное кодирование в RSA неразрывно переплетено с обеспечением семантической безопасности: без корректного дополнения даже математически стойкий алгоритм оказывается уязвимым.

В протоколах, использующих текстовые форматы (JSON, XML, HTTP), возникает обратная задача: бинарные криптографические данные (шифртекст, тег аутентификации, подпись) должны быть представлены в виде символов, допустимых в текстовом протоколе. Для этого применяется транспортное кодирование, наиболее распространённым видом которого является Base64, рассматриваемый в главе 4.

ГЛАВА 3. СМЫСЛОВОЕ (СЕМАНТИЧЕСКОЕ) КОДИРОВАНИЕ И СЖАТИЕ ДАННЫХ (расширенный вариант)

3.1. Сущность смыслового кодирования

Смысловое кодирование, в отличие от символьного, не является простым сопоставлением «символ → код». Оно учитывает статистическую структуру сообщения и ставит целью сокращение объёма данных за счёт устранения избыточности. Клод Шеннон в работе «A Mathematical Theory of Communication» (1948) показал, что минимальное среднее число битов на символ, необходимое для представления сообщения из источника с энтропией H, не может быть меньше H. Смысловое кодирование (сжатие) стремится приблизиться к этому теоретическому пределу.

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

3.2. Методы сжатия без потерь: код Хаффмана и арифметическое кодирование

Код Хаффмана, предложенный Дэвидом Хаффманом в 1952 году, является одним из наиболее известных алгоритмов префиксного сжатия. Алгоритм строит двоичное дерево на основе частот символов: два узла с наименьшими частотами объединяются в новый узел с суммарной частотой; процесс повторяется до тех пор, пока не останется один корневой узел. Коды символов соответствуют путям от корня к листьям (левый потомок — бит 0, правый — 1). Поскольку ни один код не является префиксом другого, декодирование однозначно и не требует разделителей.

Код Хаффмана оптимален среди всех префиксных кодов для заданного распределения частот: он минимизирует среднюю длину кодового слова. Однако он имеет принципиальное ограничение: длина кода каждого символа должна быть целым числом битов. Если вероятность символа равна 0,9, теоретически оптимальная длина кода составляет около 0,15 бита, но код Хаффмана вынужден использовать минимум 1 бит, что даёт избыточность.

Арифметическое кодирование преодолевает это ограничение. Вместо сопоставления каждому символу отдельного кода оно представляет всё сообщение как одно число — дробь в интервале [0, 1). В процессе кодирования интервал последовательно сужается: каждому очередному символу соответствует подинтервал, ширина которого пропорциональна его условной вероятности. По завершении обработки сообщения результат представляется как двоичная дробь, попадающая в финальный интервал. Арифметическое кодирование асимптотически достигает энтропийного предела Шеннона и особенно эффективно для источников с сильно неравномерным распределением вероятностей.

На практике широко применяются также словарные методы (LZ77, LZ78, deflate), которые заменяют повторяющиеся последовательности ссылками на предыдущие вхождения. Алгоритм deflate, комбинирующий LZ77 и код Хаффмана, лежит в основе форматов gzip, zip и используется в HTTP-сжатии.

3.3. Взаимосвязь сжатия и криптографической защиты: атаки CRIME и BREACH

Долгое время парадигма «сжать, затем зашифровать» (compress-then-encrypt) считалась естественной и безопасной: сжатие уменьшает объём данных, снижая нагрузку на канал и вычислительную сложность шифрования, а шифрование обеспечивает конфиденциальность. Однако эта парадигма содержит уязвимость, впервые теоретически описанную Келси в 2002 году и практически продемонстрированную в атаках CRIME (2012) и BREACH (2013).

Суть уязвимости состоит в следующем. Пусть в одном потоке данных сжимаются и шифруются: (а) секрет (например, cookie сессии), который злоумышленник хочет узнать, и (б) данные, контролируемые злоумышленником (например, параметры запроса). Если злоумышленник может внедрить в запрос строку, совпадающую с началом секрета, то при сжатии эта строка будет «поглощена» секретом (совпадающие последовательности сжимаются эффективнее), и длина сжатого текста уменьшится. Наблюдая за длиной шифртекста (которая после шифрования примерно равна длине сжатого текста плюс накладные расходы), злоумышленник может определить, угадал ли он очередной символ секрета. Итеративно перебирая символы, он восстанавливает секрет целиком [1][4].

Атака CRIME (Compression Ratio Info-leak Made Easy) была продемонстрирована на протоколе TLS с включённым сжатием на уровне TLS. Атака BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) эксплуатирует сжатие HTTP-ответов на уровне приложения и оказалась более опасной, поскольку HTTP-сжатие включено на большинстве веб-серверов по умолчанию [7]. Практической реакцией стало отключение сжатия на уровне TLS; в современных версиях TLS (1.3) сжатие не поддерживается. Однако HTTP-сжатие остаётся распространённым, и для защиты от BREACH применяются такие меры, как маскирование секретов (добавление случайных байтов перед секретом в ответе), разделение контекстов сжатия (как в HPACK в HTTP/2, где каждый заголовок сжимается независимо) и ограничение скорости запросов [13].

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

ГЛАВА 4. ПРАКТИЧЕСКИЕ АСПЕКТЫ ВЗАИМОДЕЙСТВИЯ КОДИРОВАНИЯ И КРИПТОГРАФИИ (расширенный вариант)

4.1. Base64 как транспортное кодирование криптографических данных

Base64 определён в RFC 4648 и ряде связанных документов, включая FIPS PUB 81 и более поздние стандарты. Алгоритм обрабатывает входные данные группами по 3 байта (24 бита). Каждая группа разбивается на четыре 6-битных фрагмента; каждый фрагмент используется как индекс в таблице из 64 символов (A–Z, a–z, 0–9, +, /). Если длина входных данных не кратна 3, применяется дополнение нулевыми битами и символом = для обозначения неполных групп [2].

Base64 не является шифрованием и не обеспечивает никакой конфиденциальности. Его единственная функция — представление произвольных двоичных данных в виде символов, допустимых в текстовых протоколах. В криптографических системах Base64 применяется в нескольких типичных сценариях.

Во-первых, для кодирования сертификатов X.509 в формате PEM (Privacy-Enhanced Mail). Сертификат в DER-кодировке (двоичный) преобразуется в Base64 и заключается между строками -----BEGIN CERTIFICATE----- и -----END CERTIFICATE-----. Это позволяет передавать сертификаты в текстовых сообщениях электронной почты и включать их в конфигурационные файлы.

Во-вторых, для представления компонентов JWT (JSON Web Tokens). Заголовок, полезная нагрузка и подпись JWT кодируются в Base64URL (разновидность Base64 с заменой + на - и / на _ для безопасного использования в URL). Подпись, представляющая собой результат криптографического преобразования, также кодируется в Base64URL для включения в токен.

В-третьих, для кодирования бинарных данных в HTTP-заголовках, например в схеме Basic Authentication (RFC 7617), где пара «логин:пароль» кодируется в Base64 перед передачей. Важно понимать, что Basic Authentication не обеспечивает защиты без использования TLS: Base64-строка легко декодируется, и учётные данные оказываются доступны любому, кто перехватил соединение.

Исследования показывают, что комбинация Base64 с криптографическими алгоритмами (например, ГОСТ) позволяет унифицировать обработку текстовых и бинарных данных: Base64 приводит любые данные к текстовой форме, после чего они могут быть зашифрованы алгоритмом, ориентированным на текстовые входы, или переданы по текстовому протоколу [8]. Однако при этом необходимо помнить, что Base64 увеличивает объём данных примерно на 33% (каждые 3 байта превращаются в 4 символа), что может быть существенно для систем с ограниченной пропускной способностью.

4.2. Стеганографическое кодирование и цифровые водяные знаки

Стеганография решает задачу, отличную от шифрования: она скрывает не содержание сообщения, а сам факт его передачи. В компьютерной стеганографии информация встраивается в безобидные на вид контейнеры — изображения, аудиофайлы, видео. Наиболее распространённым методом пространственной области является модификация младших значащих битов (Least Significant Bit, LSB). В 24-битном RGB-изображении каждый пиксель представлен тремя байтами (по одному на каналы красного, зелёного и синего). Изменение младшего бита каждого байта изменяет значение цвета на единицу, что визуально неразличимо для человеческого глаза, но может быть восстановлено при извлечении. Два пикселя RGB-изображения обеспечивают шесть битов для встраивания данных [3].

Стеганографическое кодирование часто комбинируется с шифрованием: встраиваемое сообщение предварительно шифруется, чтобы даже при обнаружении факта стеганографии злоумышленник не мог прочитать его содержание. Кроме того, перед встраиванием применяется сжатие (смысловое кодирование), поскольку чем меньше объём встраиваемых данных, тем меньше изменений вносится в контейнер и тем ниже риск обнаружения.

Цифровые водяные знаки (ЦВЗ) представляют собой разновидность стеганографии, ориентированную на защиту авторских прав. В отличие от «классической» стеганографии, где главным требованием является незаметность, ЦВЗ должны обладать устойчивостью (robustness) к определённым преобразованиям: сжатию с потерями (JPEG), кадрированию, изменению масштаба, фильтрации. Для достижения устойчивости применяются методы частотной области (дискретное косинусное преобразование, DCT; дискретное вейвлет-преобразование, DWT; дискретное преобразование Фурье, DFT), при которых водяной знак встраивается в коэффициенты преобразования, а не в пространственные пиксели.

В системах ЦВЗ кодирование и криптография образуют единый комплекс. Сам водяной знак может быть зашифрован (чтобы злоумышленник не мог извлечь его и использовать для ложного подтверждения авторства), а для повышения устойчивости к искажениям применяется помехоустойчивое кодирование (коды Рида–Соломона, свёрточные коды). Таким образом, практическая реализация ЦВЗ требует совместного применения символьного, смыслового и помехоустойчивого кодирования вместе с криптографическими примитивами [3][6].

ЗАКЛЮЧЕНИЕ (расширенный вариант)

Проведённое исследование позволяет сформулировать следующие выводы, соответствующие поставленным задачам.

Разграничение кодирования и шифрования имеет не только терминологическое, но и практическое значение. Кодирование обратимо без секрета и решает задачу представления информации в форме, пригодной для обработки; шифрование требует ключа и решает задачу обеспечения конфиденциальности. Смешение этих понятий порождает как ложное чувство защищённости (в случае Base64), так и недооценку влияния кодирования на безопасность системы.

Символьное кодирование (ASCII, Unicode) является необходимым этапом подготовки данных к шифрованию. Выбор кодировки и корректность процедур дополнения (padding) влияют на совместимость реализаций и на стойкость системы. Атаки на дополнение (padding oracle) демонстрируют, что технические детали кодирования могут иметь прямые криптографические последствия. В защищённых системах кодировка должна быть зафиксирована на уровне спецификации, а обработка ошибок дополнения — унифицирована, чтобы не создавать оракулов.

Смысловое кодирование (сжатие) не является нейтральным по отношению к безопасности. Парадигма compress-then-encrypt, долгое время считавшаяся безопасной, порождает побочный канал, эксплуатация которого в атаках CRIME и BREACH привела к восстановлению секретов (cookie сессий) в реальных веб-приложениях. Практические меры противодействия включают отказ от сжатия на уровне TLS, разделение контекстов сжатия (HPACK в HTTP/2), маскирование секретов и ограничение скорости запросов. Проектировщик защищённой системы обязан анализировать весь конвейер обработки данных, а не только криптографические примитивы.

Практическое применение кодирования в криптографических системах многообразно. Base64 обеспечивает транспортное кодирование бинарных криптографических данных (сертификаты, JWT, Basic Auth), но не защищает их. Стеганографическое кодирование (LSB-метод, частотные методы) в сочетании с шифрованием и помехоустойчивым кодированием позволяет скрывать факт передачи информации и защищать авторские права (цифровые водяные знаки).

Автор полагает, что грамотное сочетание методов кодирования и шифрования, основанное на понимании различий между ними и осознании возможных побочных эффектов, является необходимым условием построения надёжных систем защиты информации в автоматизированных системах. Дальнейшее направление исследований может быть связано с анализом влияния современных форматов сжатия (Brotli, Zstandard) на безопасность протоколов и с разработкой методов сжатия, устойчивых к компрессионным атакам.

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

· Alawatugoda J., Stebila D., Boyd C. Protecting Encrypted Cookies from Compression Side-Channel Attacks // Financial Cryptography and Data Security. — 2015. — (IACR ePrint 2014/724) [1][4].
· OWASP. BREACH Attack. — URL: https://owasp.org/www-community/attacks/BREACH (дата обращения: 19.10.2026) [7].