В криптографии существует строгая терминология, разделяющая данные до и после обработки алгоритмом. Сообщение, полученное после преобразования с использованием любого шифра, называется шифротекстом (или ciphertext в англоязычной литературе). Это базовое понятие, без которого невозможно понять принципы работы современных систем защиты информации.
Шифротекст представляет собой результат применения шифрующего алгоритма к исходному открытому тексту (plaintext) с использованием секретного ключа. В идеале он должен выглядеть как случайная последовательность символов, не несущая никакой смысловой нагрузки для постороннего наблюдателя. Только обладатель соответствующего ключа может обратить преобразование и восстановить исходное сообщение.
Основные определения и терминология
Термин шифротекст закрепился в профессиональной среде еще в середине XX века, когда криптография перешла из разряда военных тайн в область академической науки. В российской нормативной документации (например, ГОСТ 28147-89) используется термин «закрытый текст», но суть остается неизменной — это данные в зашифрованном виде.
Важно отличать шифротекст от других промежуточных форм данных. При кодировании (например, Base64) информация не становится секретной — меняется только формат представления. При хешировании получается отпечаток фиксированной длины, из которого невозможно восстановить исходное сообщение. Только шифрование подразумевает обратимое преобразование с использованием ключа.
- 🔐 Шифротекст (ciphertext) — результат обратимого шифрования с ключом
- 📄 Открытый текст (plaintext) — исходные данные до шифрования
- 🔑 Ключ — секретный параметр, управляющий преобразованием
- 🧮 Алгоритм шифрования — математическая функция преобразования
⚠️ Внимание: Не путайте шифротекст с результатом хеширования. Хеш-функция (SHA-256, MD5) создает необратимый отпечаток данных, а шифрование всегда подразумевает возможность расшифровки при наличии ключа.
Исторический контекст: от Цезаря до Энигмы
Концепция шифротекста существовала задолго до появления термина. Юлий Цезарь использовал простую подстановку, сдвигая буквы алфавита на фиксированное число позиций. Результат — бессмыслица вроде «KHOOR» вместо «HELLO» — и есть исторический пример шифротекста. Главное отличие от современных методов: алгоритм был секретным, а не ключ.
В XX веке машина Энигма порождала шифротекст невиданной сложности для того времени. Немцы верили в её неуязвимость, но команда Алана Тьюринга в Блетчли-Парке доказала обратное. Ключевым фактором стал не идеальный алгоритм, а ошибки операторов: повторение ключей, стандартные фразы в сообщениях, предсказуемые форматы. Это урок актуален и сегодня — слабое звено часто не в математике, а в реализации.
С появлением компьютеров шифротекст перестал быть последовательностью букв. Современные алгоритмы (AES, ChaCha20) работают с битами, преобразуя блоки фиксированного размера (128 или 256 бит) в неразличимый от случайного шум набор байтов. Визуально это часто представляют в hex или Base64 для удобства передачи по текстовым каналам.
Пример работы цезаря
Сдвиг на 3 позиции: A→D, B→E, C→F... Открытый текст: "СЕКРЕТ" → Шифротекст: "ФХНУХВ". Восстановление: обратный сдвиг на 3. Ключ — число 3. Алгоритм — циклический сдвиг алфавита.
Симметричное и асимметричное шифрование: различия в шифротексте
При симметричном шифровании (AES, ГОСТ 28147-89, Кузнечик) один и тот же ключ используется для шифрования и расшифровки. Шифротекст обычно имеет длину, близкую к открытому тексту (с учетом дополнения до блока и вектора инициализации). Скорость обработки высока — гигабайты в секунду на современных процессорах.
В асимметричных системах (RSA, ECC, Эль-Гамаль) применяется пара ключей: открытый для шифрования, закрытый — для расшифровки. Шифротекст здесь значительно длиннее исходных данных из-за математической структуры. Например, RSA-2048 шифрует блоки до 245 байт, выдавая всегда 256 байт шифротекста. Поэтому на практике используют гибридные схемы: асимметричное шифрование защищает симметричный сессионный ключ, а тот — уже сами данные.
| Характеристика | Симметричное (AES-256-GCM) | Асимметричное (RSA-2048/OAEP) | Гибридное (TLS 1.3) |
|---|---|---|---|
| Длина шифротекста | Данные + 16 байт тег + 12 байт IV | Фиксированно 256 байт на блок | Ключ (RSA) + данные (AES) |
| Скорость | ~2-5 ГБ/с (CPU с AES-NI) | ~500-2000 операций/с | Близко к симметричному |
| Распределение ключей | Требует защищенного канала | Открытый ключ — публично | Обмен ключами через DH/ECDH |
| Квантовая устойчивость | Атака Гровина (усиление в 2 раза) | Атака Шора (полный взлом) | Зависит от KEM-алгоритма |
⚠️ Внимание: Никогда не используйте один и тот же ключ и вектор инициализации (IV) для шифрования двух разных сообщений в режимах CTR, GCM, OFB, CFB. Это приводит к катастрофической утечке информации через XOR шифротекстов.
Гибридное шифрование — стандарт де-факто: асимметричная криптография решает проблему обмена ключами, симметричная — обеспечивает производительность при шифровании больших объемов данных.
Режимы работы блочных шифров и структура шифротекста
Блочные шифры (AES, Кузнечик) обрабатывают данные фиксированными блоками — 128 или 256 бит. Но реальные сообщения произвольной длины. Режим работы определяет, как блоки связываются между собой и как формируется итоговый шифротекст. Выбор режима критически влияет на безопасность.
Режим ECB (Electronic Codebook) шифрует каждый блок независимо. Одинаковые блоки открытого текста дают одинаковые блоки шифротекста — это сохраняет паттерны (знаменитый пример: зашифрованный логотип пингвина Tux в ECB все еще узнаваем). Режимы CBC, CTR, GCM вводят зависимость между блоками через вектор инициализации (IV) или счетчик.
Современный стандарт — аутентифицированное шифрование (AEAD: AES-GCM, ChaCha20-Poly1305). Шифротекст здесь включает не только зашифрованные данные, но и тег аутентификации (обычно 128 бит). Любое изменение бита в шифротексте приведет к ошибке верификации при расшифровке. Это защищает от атак с выбранным шифротекстом (CCA).
- 📦 IV/Nonce — уникальный для каждого шифрования вектор инициализации (публичный)
- 🔒 Зашифрованные данные — основная полезная нагрузка шифротекста
- 🏷️ Тег аутентификации — гарантия целостности и подлинности (в AEAD режимах)
- 📎 AAD — ассоциированные аутентифицированные данные (заголовки, не шифруются, но защищаются)
☑️ Проверка корректности шифротекста перед расшифровкой
Практический пример: структура шифротекста в TLS 1.3
Протокол TLS 1.3, защищающий HTTPS, использует формат записи (record), где шифротекст имеет четкую структуру. Понимание этого формата помогает при анализе трафика, отладке и разработке криптографических библиотек.
Запись TLS 1.3 после рукопожатия (handshake) выглядит так: ContentType (1 байт) || LegacyVersion (2 байта) || Length (2 байта) || EncryptedData || AuthTag. Поле EncryptedData содержит зашифрованное приложение (HTTP) с добавленным внутренним типом контента и padding. AuthTag — 16 байт полиномиального MAC (Poly1305) или GCM-тега.
Важно: в TLS 1.3 заголовок записи не шифруется (кроме версии), но защищается аутентификацией. Это позволяет промежуточным узлам (балансировщикам, файрволам) маршрутизировать трафик без расшифровки. Внутренний тип контента (application_data, alert, handshake) скрыт внутри зашифрованной части.
Пример TLS 1.3 record (hex):
17 03 03 00 2a [заголовок: application_data, TLS 1.2, длина 42]
a1 b2 c3 ... [зашифрованные данные: 26 байт]
d4 e5 f6 ... [тег аутентификации: 16 байт]
При анализе TLS-трафика в Wireshark включите расшифровку через Session Key Log (переменная SSLKEYLOGFILE в браузере). Тогда вы увидите и открытый текст, и структуру шифротекста одновременно.
Атаки на шифротекст: что может злоумышленник без ключа
Даже идеальный шифротекст не дает абсолютных гарантий. Существует целый класс атак, работающих только с зашифрованными данными. Атака только по шифротексту (ciphertext-only attack) — базовая модель угрозы: противник видит перехваченные сообщения, но не знает открытого текста ни для одного из них.
Более мощные модели: известный открытый текст (known-plaintext) — у атакующего есть пары «открытый-шифротекст»; выбранный открытый текст (chosen-plaintext) — он может зашифровать произвольные данные; выбранный шифротекст (chosen-ciphertext, CCA) — он может расшифровывать любые сообщения, кроме целевого. Современные стандарты (AES-GCM, ChaCha20-Poly1305) проектируются устойчивыми к CCA.
Побочные каналы (side channels) — отдельная история. Длина шифротекста часто раскрывает длину открытого текста (с точностью до блока). Время выполнения операций, потребление энергии, электромагнитное излучение — всё это может утекать информацию о ключе или данных. Постоянное время выполнения (constant-time) — обязательное требование к реализации криптографических примитивов.
⚠️ Внимание: Сжатие перед шифрованием (как в старых версиях TLS) создает уязвимость CRIME/BREACH: длина шифротекста зависит от содержания, что позволяет угадывать секреты (cookies, токены) посимвольно. TLS 1.3 запрещает сжатие на уровне записи.
Частые ошибки разработчиков при работе с шифротекстом
Самая распространенная ошибка — «своя криптография». Использование AES-ECB для структурированных данных, хранение IV вместе с ключом, повторное использование nonce в GCM/ChaCha20, отсутствие аутентификации шифротекста (режим CBC без HMAC) — всё это приводит к компрометации.
Проблема padding oracle (атака на дополнение) до сих пор встречается в legacy-системах. Если сервер возвращает разные ошибки для «неверный padding» и «неверный MAC», атакующий может восстановить открытый текст за ~128 запросов на байт. Решение: всегда используйте AEAD (AES-GCM, ChaCha20-Poly1305) или Encrypt-then-MAC с константным временем сравнения тегов.
Еще одна ловушка — кодирование шифротекста. Двоичные данные нельзя передавать в JSON, URL, XML напрямую. Стандарт де-факто — Base64 (или Base64URL для URL-safe). Но Base64 увеличивает размер на ~33%. Для встраивания в текстовые протоколы иногда используют hex (удвоение размера) или бинарные форматы (CBOR, Protocol Buffers).
- 🛑 Никогда не используйте ECB для данных длиннее одного блока
- 🔄 Всегда генерируйте уникальный nonce/IV для каждого шифрования под одним ключом
- ✅ Обязательно аутентифицируйте шифротекст (AEAD или Encrypt-then-MAC)
- ⏱️ Сравнивайте теги и HMAC в константном времени
- 🗑️ Уничтожайте ключи в памяти после использования (zeroize)
Почему нельзя повторять nonce в GCM
Повтор nonce в AES-GCM позволяет извлечь аутентификационный подключ H = E(K, 0). Зная H, атакующий может подделать тег для любого шифротекста и расшифровывать сообщения (не восстанавливая ключ, но ломая конфиденциальность и целостность). Это фатальная ошибка.
Квантовая эра и будущее шифротекста
Квантовые компьютеры меняют ландшафт. Алгоритм Шора ломает RSA, ECC, Диффи-Хеллман за полиномиальное время. Алгоритм Гровина ускоряет перебор симметричных ключей в √N раз — AES-128 дает 64 бита квантовой безопасности, AES-256 — 128 бит. NIST уже стандартизировал постквантовую криптографию (PQC): ML-KEM (Kyber) для обмена ключами, ML-DSA (Dilithium), SLH-DSA (SPHINCS+) для подписей.
Шифротекст в постквантовом мире станет больше. Публичный ключ ML-KEM-768 — 1184 байта, шифротекст (kem ciphertext) — 1088 байт, подпись ML-DSA-65 — 3309 байт. Это создает нагрузку на каналы связи, MTU, производительность. Гибридные схемы (классическая + PQC) будут стандартом переходного периода — например, X25519+ML-KEM для TLS 1.3.
Интересный факт: одноразовый блокнот (One-Time Pad) дает информационно-теоретическую безопасность — шифротекст не выдает ни бита информации об открытом тексте без ключа. Но ключ должен быть по длине равен сообщению, абсолютно случайным и использованным один раз. На практике это неприменимо для массовых коммуникаций, но используется в дипломатической связи и квантовом распределении ключей (QKD).
Переход на постквантовую криптографию уже начался: Chrome, Firefox, Cloudflare, AWS поддерживают гибридные KEM (X25519+Kyber) в TLS 1.3. Шифротекст станет больше, но устойчив к квантовым атакам.
Заключение: почему понимание шифротекста важно каждому разработчику
Шифротекст — не просто «зашифрованные данные». Это структурированный объект с полями, семантикой и требованиями к обработке. Ошибки в работе с IV, тегами, кодированием, режимами приводят к уязвимостям, которые эксплуатируются автоматизированно. Современные библиотеки (libsodium, OpenSSL 3.0, Go crypto, Rust ring) предоставляют высокоуровневые API (например, crypto_secretbox), скрывающие детали.
Правило простое: не изобретайте криптографию, используйте проверенные конструкции. Если вам нужно зашифровать данные — возьмите AEAD-шифр с 256-битным ключом, случайным nonce и аутентификацией ассоциированных данных. Храните шифротекст как opaque blob (Base64/hex), передавайте по защищенным каналам, вращайте ключи. И помните: безопасность системы определяется не силой алгоритма, а качеством реализации и управления ключами.
❓ FAQ: Частые вопросы о шифротексте
Можно ли определить алгоритм шифрования по виду шифротекста?
Обычно нет. Качественный шифротекст неразлидим от случайных данных. Однако формат контейнера (заголовки, длина, наличие IV/тега) может выдать используемую библиотеку или протокол. Например, длина 16-байтового тега и 12-байтовый nonce характерны для AES-GCM.
Почему шифротекст длиннее открытого текста?
Накладные расходы: вектор инициализации (IV/nonce) — 8-16 байт, тег аутентификации — 16 байт, дополнение до блока (padding) в режимах без потокового шифрования — до 15 байт. В асимметричном шифровании накладные расходы гораздо больше из-за математической структуры.
Безопасно ли хранить шифротекст в открытом доступе?
Да, если ключ надежно защищен и алгоритм устойчив. Шифротекст не должен раскрывать информации об открытом тексте (кроме длины). Но метаданные (кто, когда, с кем, сколько) могут быть чувствительны — их тоже стоит защищать.
Что такое «формат шифротекста» в библиотеках вроде libsodium?
Это стандартная упаковка: nonce || ciphertext || tag (для crypto_secretbox) или ephemeral_public_key || ciphertext || tag (для crypto_box). Библиотека сама собирает и разбирает этот формат, разработчик работает только с ключами и данными.
Можно ли сжимать шифротекст?
Бесполезно. Качественный шифротекст имеет энтропию, близкую к максимальной (1 бит на бит). Сжатие не уменьшит размер, а добавит накладные расходы. Сжимайте до шифрования, но помните об атаках CRIME/BREACH при сжатии секретных данных вместе с управляемыми атакующим данными.