Кратко

  • Обычный порядок RFC 1991: подписать буквальные данные, сжать их вместе с подписью, зашифровать сеансовым ключом, добавить для каждого получателя пакет с этим ключом и при необходимости обернуть бинарный объект в ASCII Armor.
  • CTB и длины описывали структуру; CRC и проверки ключа обнаруживали отдельные ошибки. Ни один из этих результатов сам по себе не удостоверял отправителя, разрешение на действие или получение сообщения.
  • Подпись документа охватывала определённые байты, но не все видимые метаданные. Имя файла, доверенное время, связь ключа с человеком и организационные полномочия требовали иной доказательной цепочки.

Конструкция начинается изнутри

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

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

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

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

CTB размечает синтаксис

Cipher Type Byte, CTB, открывает пакет и кодирует его тип вместе с формой поля длины. Анализатор различает подпись, сжатые, симметрично зашифрованные или буквальные данные и находит следующую границу. Для сжатых данных предусмотрена форма без явной длины — до конца объемлющей структуры.

Это важный механизм совместимости: составной файл можно проходить пакет за пакетом. Но правильный тип подтверждает только соответствие грамматике. Совпавшая длина подтверждает достижение объявленной границы. Они не доказывают происхождение тела, полноту внешнего объекта, безопасность алгоритма или право приложения исполнить содержимое.

Неопределённая длина особенно хорошо показывает зависимость уровней. Её конец известен только при известной внешней границе. Локально безошибочный разбор может соседствовать с неверным предположением о целом файле.

ASCII Armor отвечал за проходимость

Почтовые тракты того времени не всегда сохраняли бинарные данные. ASCII Armor представлял каждые три байта четырьмя печатными символами, добавляя заголовок, необязательные поля, тело, 24-битный CRC и окончание. CRC вычислялся по бинарным данным до radix-64-преобразования.

Завершённый блок напоминает печать, однако RFC отделяет заголовки оболочки от сообщения. Они могут меняться в пути и не должны содержать важную информацию. Неизвестный, но корректно оформленный ключ заголовка сообщается пользователю, после чего обработка продолжается.

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

У ключевого идентификатора нет биографии

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

64-битный Key ID служит подсказкой при поиске кандидатов. RFC прямо допускает случайные и злонамеренные совпадения. Для доказательства нужны фактический ключ, множество кандидатов, правило разрешения, состояние отзыва или компрометации и политика, связывавшая ключ с субъектом.

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

Историческое значение узких утверждений

RFC Editor указывает, что RFC 1991 был опубликован как Informational в августе 1996 года и позднее объявлен устаревшим RFC 4880. Канонические версии в тексте, HTML и карточка IETF подтверждают содержание спецификации, но не одинаковое поведение всех исторических реализаций.

Связанная запись IETF в справочнике нужна только для институциональной навигации; она не доказывает одобрение этой интерпретации организацией.

Эссе Lu Heng о приоритете работающего кода, минимальной исходной спецификации и локальном решении и слоях реальности здесь выступают редакционным методом, а не историческим источником о PGP. Метод запрещает технической записи присваивать авторитет факта, которого она не наблюдала.

Наследие RFC 1991 — не обещание абсолютного доказательства. Это дисциплина составного объекта: каждый обратимый шаг имеет собственную квитанцию и собственный предел.