Перейти к содержимому
ecdsa.com

S/MIME или OpenPGP: сквозная подпись и шифрование почты

Оба стандарта обеспечивают сквозную подпись и шифрование почты. S/MIME опирается на сертификаты от CA и встроен в корпоративные клиенты; OpenPGP опирается на ключи, которые пользователи проверяют сами, и встроен в меньшее число инструментов.
Что сравниваетсяS/MIMEOpenPGP

S/MIME или OpenPGP — это выбор между двумя стандартами сквозной защиты электронной почты. S/MIME (RFC 8551) упаковывает сообщения в формат Cryptographic Message Syntax и идентифицирует людей по сертификатам X.509, выпущенным центрами сертификации (certificate authority, CA). OpenPGP (RFC 9580) использует собственный формат пакетов и ключи, сгенерированные и опубликованные самими владельцами, а доверие к ключу устанавливается сверкой отпечатков, подписями других пользователей или через домен получателя.

Коротко о главном

S/MIMEOpenPGP
СпецификацияRFC 8551 (S/MIME 4.0), CMS (RFC 5652)RFC 9580 (2024); для постквантовых алгоритмов — RFC 9980 (июнь 2026 года); GnuPG следует LibrePGP
Контейнер ключаСертификат X.509, выпущенный CAКлюч OpenPGP с самоподписью; при желании его сертифицируют другие пользователи
Решение о доверииИерархия CA в хранилищах корневых сертификатов операционной системы и почтового клиентаСверка отпечатка, сеть доверия, доверие при первом использовании или Web Key Directory домена
Проверка идентификационных данныхCA проверяет владение почтовым ящиком (а в зависимости от типа сертификата — также организацию или личность)По умолчанию нет; некоторые каталоги проверяют адрес электронной почты
Поиск ключейВнутри подписанных сообщений, в корпоративных каталогах (GAL, LDAP)Web Key Directory, серверы ключей, заголовки Autocrypt, обмен вручную
Размер отделённой подписи (замер ниже)907 байт с сертификатом подписанта, 446 байт без него147 байт (Ed25519)
Срок действияПубличные сертификаты — не более 825 днейВыбирает владелец, срок можно продлить
ОтзывCRL или OCSP, публикуемые CAПодпись отзыва, публикуемая владельцем ключа
Встроенная поддержка в клиентахOutlook, Apple Mail, iOS Mail; Gmail в некоторых редакциях WorkspaceThunderbird (начиная с версии 78), Proton Mail; в остальных — через дополнения
Алгоритмы, допустимые в 2026 годуRSA 2048+, ECDSA P-256/384/521, EdDSA, ML-DSA и ML-KEM по базовым требованиям к S/MIME (S/MIME Baseline Requirements)Ed25519, X25519, Ed448, X448, RSA; составные ML-DSA+Ed25519 и ML-KEM+X25519 (RFC 9980)
Шифрование содержимогоОбязателен AES-GCM (RFC 8551), AES-CBC — для совместимостиAEAD (обязателен OCB) в SEIPD v2 по RFC 9580

Как выглядит подпись

Скрипт ниже подписывает одно и то же короткое сообщение обоими способами с помощью GnuPG 2.5.21 и OpenSSL 3.6.5, а затем проверяет каждую подпись. Ключи и одноразовый CA создаются во временном каталоге и после работы удаляются.

Подпись в OpenPGP и в S/MIME (CMS)
#!/bin/sh
dir=$(mktemp -d)
cd "$dir" || exit 1
export GNUPGHOME="$dir/gnupg"
mkdir -m 700 "$GNUPGHOME"
printf 'Quarterly report attached.\n' > msg.txt

echo "== OpenPGP (GnuPG)"
gpg --batch --quiet --passphrase '' --quick-gen-key "Alice <alice@example.org>" ed25519 sign 1d
gpg --batch --quiet --detach-sign msg.txt
gpg --batch --verify msg.txt.sig msg.txt 2>&1 | grep -E "using|Good"
echo "signature bytes: $(wc -c < msg.txt.sig)"
gpgconf --kill gpg-agent

echo "== S/MIME (OpenSSL CMS)"
EC="-newkey ec -pkeyopt ec_paramgen_curve:P-256 -noenc"
openssl req -x509 $EC -keyout ca.key -out ca.pem -days 30 -subj "/CN=Example Mail CA" \
  -addext "keyUsage=critical,keyCertSign" 2>/dev/null
openssl req -x509 $EC -CA ca.pem -CAkey ca.key -keyout alice.key -out alice.pem -days 30 \
  -subj "/CN=Alice" -addext "subjectAltName=email:alice@example.org" \
  -addext "keyUsage=critical,digitalSignature" \
  -addext "extendedKeyUsage=emailProtection" 2>/dev/null
openssl cms -sign -binary -in msg.txt -signer alice.pem -inkey alice.key -outform DER -out msg.p7s
openssl cms -verify -binary -in msg.p7s -inform DER -content msg.txt -CAfile ca.pem -out /dev/null
echo "signature bytes: $(wc -c < msg.p7s)"
openssl cms -sign -binary -nocerts -in msg.txt -signer alice.pem -inkey alice.key -outform DER -out bare.p7s
echo "without the embedded certificate: $(wc -c < bare.p7s)"
cd / && rm -rf "$dir"
Результат
== OpenPGP (GnuPG)
gpg:                using EDDSA key 57AE27428681EABC417A15B7DDA5B1FF5FAE8694
gpg: Good signature from "Alice <alice@example.org>" [ultimate]
signature bytes:      147
== S/MIME (OpenSSL CMS)
CMS Verification successful
signature bytes:      907
without the embedded certificate:      446

Разница в размере заложена в самой структуре. Подпись CMS обычно содержит сертификат подписанта, поэтому любой получатель может проверить её по доверенному корневому сертификату и сохранить сертификат, чтобы шифровать ответы; даже без сертификата структуру увеличивают подписанные атрибуты, такие как время подписания и тип содержимого. Отделённая подпись OpenPGP указывает ключ по отпечатку, поэтому получатель должен уже иметь этот ключ или загрузить его. Отпечаток из 40 символов показывает, что GnuPG создал ключ версии 4; у ключей версии 6 из RFC 9580 отпечатки SHA-256 длиной 64 символа.

Как каждый стандарт решает, кому доверять

S/MIME передаёт решение центрам сертификации. С 1 сентября 2023 года публично доверенные сертификаты S/MIME подчиняются базовым требованиям CA/Browser Forum к S/MIME: CA обязан проверить, что заявитель контролирует каждый адрес электронной почты; типы сертификатов варьируются от проверенных по почтовому ящику (mailbox-validated) до проверенных по личности владельца (individual-validated); нестрогие профили «legacy» с 15 июля 2025 года выпускать больше нельзя, а сертификаты абонентов действуют не более 825 дней. Предприятия также могут развернуть собственный CA и распространять сертификаты через системы управления устройствами — именно так устроено большинство крупных внедрений S/MIME.

OpenPGP оставляет решение пользователям. Изначальная сеть доверия (web of trust), в которой пользователи подписывают ключи друг друга, так и не вышла за пределы небольших сообществ, а публичные серверы ключей, принимавшие любые загрузки, стали непригодны для работы с непроверенными идентификаторами пользователей. Сейчас принято сверять отпечатки по независимому каналу, принимать ключ при первом использовании или искать его через Web Key Directory, где сам домен получателя отдаёт ключ по HTTPS. keys.openpgp.org публикует идентификаторы пользователей только после проверки адреса.

Клиенты, совместимость и раскол OpenPGP

Сильная сторона S/MIME — интеграция: Outlook, Apple Mail и iOS Mail подписывают и шифруют письма штатными средствами, как только установлен сертификат, а Gmail в некоторых редакциях Google Workspace предлагает S/MIME на стороне сервера. OpenPGP встроен в Thunderbird и Proton Mail, а в других клиентах доступен через дополнения.

Кроме того, у OpenPGP раскололись стандарты. IETF опубликовал RFC 9580 в июле 2024 года — с ключами версии 6, обязательным шифрованием AEAD и защитой парольной фразы с помощью Argon2 — и RFC 9980 в июне 2026 года для постквантовых ключей. GnuPG же реализует LibrePGP, у которого ключи версии 5 и формат пакета OCB отличаются от RFC 9580. Ключи версии 4 с классическим пакетом зашифрованных данных работают во всех реализациях; GnuPG может перейти на свой пакет OCB для получателей, чьи ключи объявляют о его поддержке, а возможности RFC 9580, такие как ключи версии 6, нужно проверять с программами ваших корреспондентов.

Оба стандарта были уязвимы для EFAIL (2018): специально сформированный шифртекст заставлял почтовые клиенты раскрывать расшифрованный текст через HTML. Надёжно проблему решают аутентифицированное шифрование (AES-GCM в S/MIME 4.0, код обнаружения изменений, а теперь и AEAD в OpenPGP) и клиенты, которые отказываются показывать открытый текст, не прошедший аутентификацию.

Что когда выбирать

  • Корпоративная почта на управляемых устройствах: S/MIME с сертификатами, развёрнутыми через MDM; ключи шифрования депонируйте, ключи подписи — никогда.
  • Внешние партнёры, у которых уже есть сертификаты S/MIME (госсектор, банки, здравоохранение): S/MIME.
  • Частные лица, журналисты, мейнтейнеры проектов с открытым исходным кодом: OpenPGP с ключами, опубликованными через WKD или keys.openpgp.org.
  • Шифрование файлов, резервных копий или секретов, а не почты: ни то ни другое; используйте age (см. age или GPG).
  • Подпись релизов ПО и коммитов: OpenPGP по-прежнему подходит, но подписи Sigstore и SSH часто проще (см. Sigstore или GPG для подписи).
  • Защита темы письма: что бы вы ни выбрали, используйте клиент с поддержкой защиты заголовков (RFC 9788); иначе тема передаётся в открытом виде.

Заметки о миграции

  1. Новые внедрения S/MIME: запрашивайте сертификаты профиля strict или multipurpose с адресом в альтернативном имени субъекта (Subject Alternative Name) и разделяйте ключи подписи и шифрования, чтобы депонировать только ключи шифрования.
  2. Текущие пользователи S/MIME: сертификаты, выпущенные по профилю legacy, при продлении заменяются; до того как истечёт срок действия ваших старых сертификатов, убедитесь, что клиенты партнёров принимают новые профили.
  3. Ключи OpenPGP: генерируйте ключи Ed25519 и X25519 (или ключи версии 6, если их поддерживают программы всех ваших корреспондентов), задайте срок действия от одного года до двух лет и продлевайте его, храните сертификат отзыва офлайн и публикуйте ключи через WKD.
  4. Архивы: храните старые ключи расшифрования или сертификаты, пока вам нужно читать старую почту; единственный способ вывести их из употребления — перешифровать архивы.
  5. План перехода на постквантовые алгоритмы: зашифрованная почта уязвима для стратегии «собери сейчас, расшифруй потом». ML-KEM определён для CMS (RFC 9936) и в сочетании с X25519 — для OpenPGP (RFC 9980); сначала переводите ключи шифрования, подписи — позже. Инспектор OpenPGP и инструмент проверки подписей S/MIME показывают, какие алгоритмы используются в ключе, сертификате или сообщении.

Источники

Все сравнения