Кратко

  • Base64 в MIME — обратимое транспортное представление тела сообщения; оно не добавляет конфиденциальность, целостность, подлинность, полномочия или безопасность запуска.
  • Проверяемая квитанция хранит исходную строку, границы MIME-сущности, профиль, политику декодера, хеш результата и отдельные итоги защитных проверок.

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

Эта разница хорошо видна в истории MIME. Профиль Nathaniel Borenstein в IETF перечисляет пятнадцать RFC, включая RFC 2045, 2046 и 2049. Материал Grinnell College 2013 года описывает его работу над MIME в Bellcore и первое MIME-сообщение 1992 года с фотографией и звуковым файлом. Задача состояла в том, чтобы разные почтовые системы не разрушали новые виды данных при передаче. Ограничение доступа было другой задачей.

Точное обещание транспортного поля

RFC 2045 определяет Content-Transfer-Encoding через два свойства: какое преобразование применено к телу и к какой области относится полученное представление. 7bit, 8bit и binary обозначают отсутствие преобразования. Quoted-printable и Base64 переводят ввод в форму, пригодную для ограниченного семибитного транспорта.

Для допустимой последовательности заявленное преобразование даёт единственный определённый набор байтов либо сообщает о недопустимом вводе. Это важная гарантия совместимости. В то же время разные кодировщики могут создавать эквивалентные представления, а само значение поля ничего не доказывает о медиатипе, кроме алгоритма или требований канала.

Успешная операция подтверждает лишь: данный декодер по данным правилам принял это представление и получил эти байты. Она не подтверждает автора, отсутствие подмены, право чтения, согласие или безопасность выполнения.

Один значок вложения — несколько объектов доказательства

Интерфейс показывает один файл, но MIME содержит вложенные сущности. Поле в заголовке сообщения относится к его телу; поле внутри сущности — только к телу этой сущности. Для составных multipart и message действуют дополнительные ограничения. Без сохранённой границы нельзя доказуемо повторить обработку.

Следователь может вычислить три разных хеша: сырого сообщения, закодированного фрагмента и декодированных байтов. Шлюз способен изменить переносы строк, сохранив итоговый файл. Два разных отправителя могут доставить одинаковые байты. Только итог стирает происхождение; только исходный текст может создать ложное различие содержимого.

Толкование типа — следующий независимый шаг. RFC 2046 рекомендует осторожно обращаться с application/octet-stream: отменить транспортное кодирование, предложить сохранить данные или передать их выбранному пользователем процессу. Декодирование не является разрешением запуска. Имя файла и Content-Type помогают выбрать политику, но не служат криптографической идентификацией.

У Base64 должен быть указан профиль

RFC 4648 разбирает различия, которые не устраняет одно название: переносы строк, заполнение, посторонние символы и выбор алфавита. Профиль MIME допускает определённые игнорируемые символы; другой протокол может требовать отказ. Base64url использует изменённый алфавит и не должен считаться тем же форматом.

Важна и каноничность. Если незначащие биты заполнения не равны нулю, разные строки могут декодироваться в одинаковые байты. Игнорируемые символы способны образовать скрытый канал, обойти строковое сравнение или вызвать ошибку реализации. Хеш только результата не показывает, что было принято; хеш только строки не показывает смысловую эквивалентность.

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

Визуальная непрозрачность не равна секретности

Раздел безопасности RFC 4648 прямо говорит: базовое кодирование может визуально скрыть узнаваемую информацию, но не даёт вычислительной конфиденциальности и не добавляет энтропию открытому тексту. Секретного ключа и решения о доступе нет. Получатель строки может обратить преобразование публичным алгоритмом.

Целостность и подлинность тоже не возникают. Изменённые байты так же легко закодировать снова. Хеш подтверждает совпадение с известным значением, но не личность создателя этого значения. Подпись или MAC связывают байты с ключом по установленным правилам; доверие к владельцу ключа остаётся отдельным решением. Если применено аутентифицированное шифрование, его результат должен иметь собственную запись.

Base64 не провалился как защитный механизм — он никогда им не был. Ошибка появляется, когда модель данных вслед за decoded=true без проверки ставит encrypted, verified или safe.

Шесть частей квитанции декодирования

Сначала сохраняются хеш полученного представления и точные границы MIME. Затем указывается профиль. Третья часть фиксирует декодер, версию и допустимые отклонения. Четвёртая содержит принятие или отказ и хеш полученных байтов. Пятая применяет безопасную политику медиатипа без автоматического запуска. Шестая отдельно связывает подпись, шифрование, транспортную аутентификацию и авторизацию.

Если подпись не проверялась, поле остаётся пустым. Если TLS защищал один участок, записывается только этот участок. Неизвестный тип не угадывается по расширению. Пустота честно показывает предел измерения.

MIME, созданный при участии Borenstein и его соавторов, оказался устойчивым благодаря разделению функций. Такой же подход нужен сейчас: Base64 подтверждает обратимое представление, а доверие подтверждается только реально выполненной проверкой доверия.