OpenPGP в 2026 году: RFC 9580, ключи v6 и раскол с GnuPG

Коротко. В RFC 9580 (июль 2024 года) IETF выпустил новую редакцию OpenPGP: ключи v6 с отпечатками SHA-256, обязательные алгоритмы Ed25519 и X25519, подписи с солью, Argon2 и аутентифицированное шифрование. Следом в RFC 9980 (2026 год) появились постквантовые алгоритмы, в основном для ключей v6. GnuPG не перешёл на RFC 9580: он следует LibrePGP — собственному продолжению стандарта с ключами v5 и собственным шифрованием на Kyber, а RFC 9980 он поддерживает лишь частично и только с флагом --allow-9980. Sequoia реализует RFC 9580 и RFC 9980, но по умолчанию всё ещё создаёт ключи v4. На практике для ключей, которые другие должны проверять тем, что у них есть (хостинги Git, менеджеры пакетов, страницы релизов), сегодня используйте ключ v4 Ed25519/Cv25519: он работает везде, где мы проверяли. Ключи v6 и постквантовые ключи используйте только в экосистемах, где каждая проверяющая сторона работает с Sequoia или другой реализацией RFC 9580.

Стенд работал в debian:forky-20261005-slim с пакетами Debian sq 1.4.1 (sequoia-openpgp 2.4.1, бэкенд Nettle) и gnupg 2.4.9. Кроме того, в том же образе мы скомпилировали GnuPG 2.5.24 из tar-архива релиза, после того как gpg --verify сообщил о верной подписи от «Werner Koch (dist signing 2020)». Все ключи сгенерированы специально для этой статьи.

Два стандарта с 2023 года

Предыдущая спецификация OpenPGP, RFC 4880, вышла в 2007 году. Её пересмотр расколол сообщество. Рабочая группа IETF подготовила документ, который стал RFC 9580; разработчики GnuPG, не согласные с частью его положений, продолжили развивать более ранний черновик под новым названием LibrePGP (draft-koch-librepgp, индивидуальный Internet-Draft авторства Werner Koch и Ronald Henry Tse, редакция 06 от сентября 2026 года) с ключами версии 5 и другим режимом аутентифицированного шифрования. В новых форматах ключей и сообщений эти два стандарта несовместимы, в старых — совместимы: все по-прежнему читают и записывают ключи v4 и подписи v4.

RFC 9580 высказывается о старом формате прямо: «Реализациям OpenPGP следует (SHOULD) создавать ключи в формате версии 6. Ключи версии 4 объявлены устаревшими; реализации не следует (SHOULD NOT) генерировать ключ версии 4, но следует (SHOULD) его принимать» (§ 5.5.2). В нём определены версии 2, 3, 4 и 6 пакета ключа; версия 5 есть только в LibrePGP. Другие изменения:

• Ed25519 (алгоритм 27) и X25519 (25) обязательны для реализации; ключи RSA «объявлены устаревшими, и их не следует (SHOULD NOT) генерировать, но можно интерпретировать», а ключи DSA и ElGamal генерировать нельзя (§ 9.1).
• Отпечаток v6 — это «256-битный хеш SHA2-256» ключа (§ 5.5.4.3); отпечаток v4 — 160-битный SHA-1.
• Подписи v6 содержат случайную соль, поэтому подписываемый хеш нельзя предсказать заранее.
• Для зашифрованных данных используется SEIPD версии 2 с AEAD (OCB обязателен), а для парольных фраз можно использовать Argon2.

Sequoia: ключи v6 по запросу

По умолчанию sq key generate создаёт ключ v4. Справка объясняет почему: «Сейчас по умолчанию используется RFC4880. Однако, когда поддержка RFC9580 распространится шире, в одной из будущих версий sq значение по умолчанию изменится». С --profile rfc9580 команда создаёт ключ v6:

sq key generate --own-key --without-password --name "Alice" --email alice@example.org --output alice-v4.pgp --rev-cert alice-v4.rev
sq key generate --own-key --without-password --profile rfc9580 --name "Alice" --email alice@example.org --output alice-v6.pgp --rev-cert alice-v6.rev
sq inspect alice-v4.pgp
sq inspect alice-v6.pgp
sq packet dump alice-v6.pgp

### default profile (RFC 4880)
      Fingerprint: D3AE271931915949BEC2B3EBE329E5163B93B0F5
  Public-key algo: EdDSA
           Subkey: 0C7A47DD70202F80B0FA90B4E5C2206CA540055E
  Public-key algo: EdDSA
           Subkey: 8E35A51EC584304842AD4D13528B152570EC6FAC
  Public-key algo: EdDSA
### --profile rfc9580
      Fingerprint: 01117FE27C0ACB8EEBCE0D6FE03730724C57DA9E25D0963276EAB7A9F7EE2FB3
  Public-key algo: Ed25519
           Subkey: 23542B454F5CEDE06B81D42A874CFCF5CAB1E1D59E905CF0FC11AC21DE44A9F0
  Public-key algo: X25519
Secret-Key Packet, new CTB, 75 bytes
    Version: 6
    Pk algo: Ed25519

Разница видна по отпечаткам: 40 шестнадцатеричных цифр (SHA-1) у v4 и 64 (SHA-256) у v6. Ключ v4 использует старый идентификатор алгоритма EdDSA (22, в RFC 9580 он называется «EdDSALegacy»), а ключ v6 — новые отдельные идентификаторы Ed25519 (27) и X25519 (25). В отделённой подписи, созданной ключом v6, видна соль:

Signature Packet, new CTB, 152 bytes
    Version: 6
    Pk algo: Ed25519
    Hash algo: SHA512
      Issuer Fingerprint: A3B490FC8C54F12C1E4955E520071CDC4ECA7F76BC87729C2F7BA5305EAC6FC7
    Salt: 62A29ACDACACD8ACF2D7ECDAAF3A10A6F577EDA3338E349D537190C437875B0F
Authenticated signature made by 01117FE27C0ACB8EEBCE0D6FE03730724C57DA9E25D0963276EAB7A9F7EE2FB3 (Alice)
1 authenticated signature.

Постквантовые ключи в библиотеке уже есть: sequoia-openpgp 2.4.0 «добавляет поддержку постквантовой криптографии, определённой в RFC 9980», а sq перечисляет наборы шифров mldsa65-ed25519 и mldsa87-ed448. Но код PQC есть только в бэкендах OpenSSL и RustCrypto, а в Debian Sequoia собирают с Nettle:

  Error: Unsupported public key algorithm: ML-DSA-65+Ed25519

Есть ли у вас постквантовый OpenPGP вообще, зависит от того, какой криптографический бэкенд выбран в вашем дистрибутиве; узнать его можно командой sq version.

GnuPG: LibrePGP, Kyber и переход с 2.4 на 2.5

Ветка GnuPG 2.5 стала стабильной 30 декабря 2025 года, когда проект объявил, что «у ветки oldstable 2.4 всего через 6 месяцев закончится срок поддержки» (gnupg.org); текущий релиз — 2.5.24 (23 сентября 2026 года). Дистрибутивы обновляются медленно: в ветке testing дистрибутива Debian по-прежнему версия 2.4.9. По умолчанию эта версия создаёт ключ v4 Ed25519 с подключом Cv25519:

pub   ed25519 2026-10-22 [SC] [expires: 2027-10-22]
sub   cv25519 2026-10-22 [E]
	version 4, algo 22, created 1792651599, expires 0
	version 4, algo 18, created 1792651599, expires 0

В версии 2.5 в GnuPG появилось постквантовое шифрование: составная схема из ML-KEM (Kyber) и классической кривой в формате LibrePGP. Пока постквантовые доработки GnuPG касаются шифрования; в примечаниях к релизам постквантовых ключей подписи нет. Поддержку RFC 9980, добавленную в 2.5.23 и доступную только с флагом --allow-9980, документация GnuPG описывает с необычной откровенностью: «Из-за раздутой спецификации использовать этот параметр не рекомендуется. Стандартный режим GnuPG больше ориентирован на классический PGP и, следовательно, на спецификацию LibrePGP, которая тоже поддерживает PQC, но более экономно и в стиле PGP».

Проверка совместимости

Каждый ключ мы загрузили в две другие реализации. Сначала GnuPG 2.4.9 читает ключи и подписи Sequoia:

gpg: key E329E5163B93B0F5: public key "Alice" imported
gpg:               imported: 1
gpg: packet(6) with unknown version 6
gpg: read_block: read error: Invalid packet
--- gpg --verify of a v4 signature made by sq
gpg:                using EDDSA key 0C7A47DD70202F80B0FA90B4E5C2206CA540055E
gpg: Good signature from "Alice" [unknown]
--- gpg --verify of the v6 signature
gpg: packet(2) with unknown version 6
gpg: no signature found

Затем — постквантовые ключи GnuPG 2.5.24, прочитанные в GnuPG 2.4.9 и в sq 1.4.1:

### gpg --quick-gen-key ... pqc
pub   brainpoolP384r1 2026-10-22 [SC] [expires: 2027-10-22]
sub   ky768_bp256 2026-10-22 [E]
version 4, algo 19, created 1792651785, expires 0
version 5, algo 8, created 1792651785, expires 0, pkbytes 1265
  gpg 2.4.9 --import, then --list-keys:
    gpg:               imported: 1
    pub   brainpoolP384r1 2026-10-22 [SC] [expires: 2027-10-22]
    sub   unknown_8 2026-10-22 [E]
  sq 1.4.1 inspect:
    Public-key algo: ECDSA
    Unknown component: ... tag: PublicSubkey, error: Malformed packet: unknown version ...
### gpg --allow-9980 --quick-gen-key ... pqc9980
pub   ietf27 2026-10-22 [SC] [expires: 2027-10-22]
sub   mlk768_bp384 2026-10-22 [E]
version 6, algo 27, created 1792651785, expires 0, pkbytes 32
version 5, algo 39, created 1792651785, expires 0, pkbytes 1281
  gpg 2.4.9 --import, then --list-keys:
    gpg: packet(6) with unknown version 6
    gpg: import from 'frank.pgp' failed: Invalid keyring
  sq 1.4.1 inspect:
    Public-key algo: Ed25519
    Unknown component: ... tag: PublicSubkey, error: Malformed packet: unknown version ...
### gpg --allow-9980: v6 Ed25519 primary + mlk768 and mlk768_bp384 subkeys
version 6, algo 27, created 1792651848, expires 0, pkbytes 32
version 5, algo 35, created 1792651848, expires 0, pkbytes 1216
version 5, algo 39, created 1792651848, expires 0, pkbytes 1281

Что это показывает:

• Ключи и подписи v4 работают везде. Ключ, который sq создаёт по умолчанию, и его подписи прошли проверку в GnuPG 2.4.9.
• Ключи v6 не читаются в GnuPG 2.4: импорт обрывается сообщением packet(6) with unknown version 6. Тот, кто импортирует ваш ключ v6 в связку ключей GnuPG 2.4, не получит ничего; для подписи v6 gpg сообщает «no signature found».
• PQC-ключ GnuPG по умолчанию работает только в LibrePGP. С pqc GnuPG создал основной ключ brainpoolP384r1 с подключом из Kyber-768 и brainpoolP256r1 (алгоритм 8) в пакете v5. GnuPG 2.4.9 импортирует такой ключ, но показывает подключ как unknown_8 и поэтому не может шифровать для него; Sequoia отклоняет пакет v5.
• Даже «режим 9980» не дал ничего, что Sequoia может прочитать. С --allow-9980 GnuPG 2.5.24 создал основной ключ v6, но записал его подключи ML-KEM, в том числе mlk768 (алгоритм 35, ML-KEM-768+X25519 из RFC 9980), как пакеты версии 5, которых RFC 9580 не определяет и которые Sequoia отвергает. Кроме того, pqc9980 по умолчанию выбирает алгоритм 39 (ML-KEM-768 с brainpoolP384r1), которого нет среди собственных алгоритмов RFC 9980. По состоянию на GnuPG 2.5.24 ключ RFC 9980 из GnuPG и реализация RFC 9980 несовместимы друг с другом.

Внутри GnuPG 2.5 шифрование и расшифрование со всеми этими ключами работали; проблема возникает только между реализациями.

Постквантовый OpenPGP: что определяет RFC 9980

RFC 9980 (предлагаемый стандарт, 2026 год) добавляет составные и самостоятельные алгоритмы:

Составная схема означает, что успешно должны отработать обе части: атакующему нужно взломать ML-KEM вместе с X25519 или ML-DSA вместе с Ed25519. Срочнее защищать шифрование, потому что зашифрованные сообщения можно сохранить сейчас и расшифровать позже (собери сейчас, расшифруй потом). Подписи могут подождать, пока их не поддержат проверяющие стороны, а долгоживущие подписи позже можно создать заново. Поскольку ID 35 разрешён и для подключей v4, к существующему ключу v4 можно добавить постквантовый подключ для шифрования, не заменяя основной ключ.

Практические рекомендации

1. Ключи подписи для релизов, коммитов Git и пакетов: v4 Ed25519, созданные в GnuPG 2.4/2.5 (default) или в sq (профиль по умолчанию). Их принимают все реализации, которые мы тестировали. APT в Debian теперь по умолчанию проверяет подписи архивов с помощью sqv из Sequoia (APT 3.0, Debian 13), а с 1 февраля 2026 года отклоняет подписи, привязанные к SHA-1, и подписи v3, поэтому всё старое переподпишите (LWN об APT 3.0).
2. Не публикуйте ключи v6 для аудитории, которую вы не контролируете, пока её инструменты не перейдут на Sequoia, OpenPGP.js 6 (в нём реализован RFC 9580) или другую реализацию RFC 9580: пользователи GnuPG 2.4 не смогут их импортировать.
3. Шифрование с постквантовой защитой сегодня работает только внутри одного диалекта: от GnuPG к GnuPG с Kyber из LibrePGP или в Sequoia с бэкендом OpenSSL либо RustCrypto для RFC 9980. Выбирайте по тому, кто будет расшифровывать.
4. Проверьте бэкенд и версии (gpg --version, sq version): пакеты дистрибутивов отстают от исходных проектов на год и больше.
5. Предпочитайте инструменты попроще там, где гибкость OpenPGP не нужна: подписи SSH для коммитов Git, Sigstore для сведений о происхождении релизов, age для шифрования файлов. Компромиссы разобраны в сравнениях SSH или GPG для подписи коммитов, Sigstore или GPG и age или GPG, а сторону SSH описывает статья ssh-keygen в 2026 году.
6. Публикуйте полный отпечаток там, где его могут сверить (на своём сайте, в примечаниях к релизу), а ключ распространяйте через WKD или keys.openpgp.org. Сервер ключей доставляет ключи, но не ручается за них.

Проверка скачанного файла: как это делать правильно

F-Droid публикует рядом со своим APK отделённую подпись, а на своём сайте — отпечаток ключа подписи. Проверка сводится к трём командам:

gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 37D2C98789D8311948394E3E41E7044E1DBA2E89
gpg --verify F-Droid.apk.asc F-Droid.apk
gpg --list-packets F-Droid.apk.asc

gpg: key 41E7044E1DBA2E89: public key "F-Droid <admin@f-droid.org>" imported
gpg: Signature made Mon Oct 12 12:58:48 2026 UTC
gpg:                using RSA key 802A9799016112346E1FEFF47A029E54DD5DCE7A
gpg: Good signature from "F-Droid <admin@f-droid.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
Primary key fingerprint: 37D2 C987 89D8 3119 4839  4E3E 41E7 044E 1DBA 2E89
     Subkey fingerprint: 802A 9799 0161 1234 6E1F  EFF4 7A02 9E54 DD5D CE7A
:signature packet: algo 1, keyid 7A029E54DD5DCE7A
	version 4, created 1791809928, md5len 0, sigclass 0x00
	digest algo 10, begin of digest 4b be

Строка «WARNING: This key is not certified» здесь ожидаема: в сети доверия GnuPG нет пути к этому ключу. Смысл проверке придаёт другое: сравнение отпечатка основного ключа с отпечатком на странице F-Droid о проверке (они совпадают) и то, что ключ запрашивается по полному отпечатку, ведь сервер ключей отдаёт всё, что подходит под запрос. Сама подпись — подпись RSA v4 (алгоритм 1) над SHA-512 (алгоритм дайджеста 10): старый формат, современный хеш, её читает любая реализация. Если ключа нет, вы получите Can't check signature: No public key, а если файл изменился — BAD signature.

Источники

• RFC 9580: OpenPGP (июль 2024 года): § 5.5.2 (версии ключей), § 5.5.4 (отпечатки), § 9.1 (алгоритмы), таблица 27
• RFC 9980: постквантовая криптография в OpenPGP (2026 год) и его страница в IETF Datatracker
• GnuPG: новости, файл NEWS (Kyber в 2.5.0, --allow-9980 в 2.5.23), doc/gpg.texi из релиза 2.5.24
• Sequoia: файл NEWS sequoia-openpgp (RFC 9580 в 2.0.0, RFC 9980 в 2.4.0), sq key generate --help (1.4.1)
• LWN: что нового в APT 3.0; F-Droid: проверка скачанных APK