Стратегия Ра Стратегия Ра Заказать

Технологии шифрования (GPG на базе ECC)

Вы можете работать в сверхсекретном государственном агентстве или быть обычным гражданином. В любом случае у вас есть конфиденциальные данные, которые необходимо защитить от посторонних глаз. Деловые секреты, государственные тайны, личные пароли — не важно. Все требует защиты.

В этой главе мы сосредоточимся на одном из самых мощных инструментов шифрования — GNU Privacy Guard (GPG). В отличие от многих устаревших руководств, мы будем использовать современные и более безопасные алгоритмы эллиптических кривых (ECC).

Почему ECC лучше RSA?

Традиционные алгоритмы, такие как RSA, основаны на сложности разложения больших чисел на простые множители. ECC (Elliptic Curve Cryptography) основан на математике эллиптических кривых. Его главные преимущества:

  1. Большая безопасность при меньшей длине ключа: Ключ ECC длиной 256 бит обеспечивает такую же стойкость, как ключ RSA длиной 3072 бита. Чем короче ключ, тем быстрее выполняются операции шифрования и расшифровки.
  2. Скорость: Генерация ключей, создание подписей и обмен ключами на эллиптических кривых происходит значительно быстрее.
  3. Экономия ресурсов: Меньший размер ключей означает меньшую нагрузку на процессор и батарею, что критично для мобильных устройств и серверов с высокими нагрузками.

В наших примерах мы будем использовать алгоритм Ed25519 для подписи и CV25519 для шифрования — современный стандарт, реализованный в GPG.

Мы рассмотрим следующие темы работы с GPG:

  • Создание ключей ECC
  • Сохранение ключей в безопасном месте
  • Симметричное шифрование / дешифрование
  • Асимметричное шифрование (с передачей через email и Telegram)
  • Подпись файла с шифрованием и проверка подписи
  • Подпись файла без шифрования и проверка подписи
  • Экспорт и импорт ключей
  • Управление доверием к ключам
  • Отзыв ключей
  • Продление срока действия ключей
  • Способы обмена открытыми ключами

1. Создание ключей ECC

Первым делом наши пользователи Игорь (igor) и Ольга (olga) должны сгенерировать свои ключи. Мы создадим пару ключей на базе эллиптических кривых.

Практическое занятие: Игорь создает ключ на Ubuntu

  1. Зайдите под пользователем igor. Запустите мастер создания ключей с расширенными настройками:

    gpg --expert --full-generate-key

  2. Мастер предложит выбрать тип ключа. Нам нужен вариант, который позволит задать современные алгоритмы. Выберите пункт (9) ECC and ECC (Set your own capabilities). Введите 9 и нажмите Enter.

    Please select what kind of key you want:
   (1) RSA and RSA
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC and ECC
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (13) Existing key
Your selection? 9

  3. Затем выберите эллиптическую кривую. Рекомендуется (1) Curve 25519. Это наиболее безопасный и быстрый вариант на сегодняшний день.

    Please select which elliptic curve you want:
   (1) Curve 25519
   (3) NIST P-256
   (4) NIST P-384
   (5) NIST P-521
   (6) Brainpool P-256
   (7) Brainpool P-384
   (8) Brainpool P-512
   (9) secp256k1
Your selection? 1

  4. Укажите срок действия ключа. Для корпоративных нужд часто ставят 1 год или 2 года. Для тренировки оставим значение по умолчанию — ключ не истекает. (В реальной жизни рекомендуется ставить срок действия, например, 1y).

    Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 0

  5. Подтвердите выбор (y).

  6. Введите персональные данные:

    Real name: Igor Petrov
Email address: igor@example.com
Comment: My ECC key

    Проверьте введенные данные и нажмите O (Okay).

  7. Введите надежную парольную фразу для защиты вашего закрытого ключа. Запомните ее! Без нее вы не сможете использовать ключ.

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

Ольга должна проделать точно такую же процедуру на своем компьютере (в нашем примере — Fedora). Команды абсолютно идентичны.

2. Сохранение ключей в безопасном месте

Закрытый ключ — это самое ценное, что есть у пользователя в системе шифрования. Если его украдут, злоумышленник сможет читать всю вашу переписку и подделывать ваши подписи.

Практическое занятие: Резервное копирование (Ольга на Fedora)

  1. Закрытый ключ Игоря хранится в каталоге ~/.gnupg/private-keys-v1.d/. Просто скопировать эти файлы недостаточно, их нужно экспортировать в защищенный контейнер.

  2. Для экспорта закрытого ключа в файл используется команда:

    gpg --export-secret-keys --armor olga@example.com > olga-secret-key.asc

    Флаг --armor создает текстовый (читаемый) файл, а не бинарный.

  3. Критически важно! Этот файл нельзя хранить на жестком диске компьютера. Идеальные места:

    • Зашифрованный USB-накопитель (например, с LUKS, который мы рассмотрим позже).
    • Оффлайн-носитель, хранящийся в сейфе.
    • Менеджер паролей с поддержкой хранения файлов (например, KeePassXC).

    Ольга копирует файл olga-secret-key.asc на защищенную флешку и удаляет его из домашней папки.

    cp olga-secret-key.asc /run/media/olga/USB_DRIVE/
shred -u -z olga-secret-key.asc

  4. Открытый ключ не является секретным, но его целостность важна. Его можно хранить где угодно.

    gpg --export --armor olga@example.com > olga-public-key.asc

3. Симметричное шифрование / дешифрование

Симметричное шифрование использует один пароль (ключ) для шифровки и расшифровки данных. Это удобно для защиты собственных файлов.

Практическое занятие: Игорь шифрует файл для себя

  1. Игорь создает файл с личными заметками.

    echo "Мои личные заметки: купить молоко, позвонить маме." > my_notes.txt

  2. Он шифрует его симметричным методом. Ключ -c означает симметричное шифрование.

    gpg -c my_notes.txt

  3. GPG запросит парольную фразу. Это пароль для доступа к файлу. Он не связан с закрытым ключом Игоря. Введите его дважды. Будет создан файл my_notes.txt.gpg.

  4. Исходный файл все еще на диске. Игорь уничтожает его.

    shred -u -z my_notes.txt

  5. Чтобы снова прочесть заметки, Игорь расшифровывает файл.

    gpg -o my_notes_decrypted.txt -d my_notes.txt.gpg

    Система запросит ту самую парольную фразу, которую он ввел на шаге 3.

4. Асимметричное шифрование

Это основа PGP. Игорь шифрует сообщение открытым ключом Ольги так, что только Ольга сможет его расшифровать своим закрытым ключом.

4.1 Подготовка: Экспорт и импорт ключей

Прежде чем начать обмен зашифрованными сообщениями, Игорь и Ольга должны обменяться открытыми ключами.

Практическое занятие: Игорь экспортирует, Ольга импортирует

  1. Игорь (Ubuntu) экспортирует свой открытый ключ:

    gpg --export --armor igor@example.com > igor_public.key

  2. Игорь отправляет этот файл Ольге (через мессенджер, email или флешку).

  3. Ольга (Fedora) получает ключ Игоря и импортирует его в свою связку:

    gpg --import igor_public.key

  4. Ольга проверяет, что ключ импортирован:

    gpg --list-keys

  5. Ольга повторяет процедуру: экспортирует свой ключ и отправляет его Игорю. Игорь импортирует его аналогично.

4.2 Шифрование и передача через email

Практическое занятие: Ольга пишет зашифрованное письмо Игорю

  1. Ольга создает текстовый файл с сообщением.

    echo "Игорь, пришли, пожалуйста, отчет за прошлый квартал." > message.txt

  2. Она шифрует его для Игоря. Ключ -e (encrypt), ключ -r (recipient) указывает получателя.

    gpg -e -r igor@example.com -a message.txt

    Флаг -a создает текстовый файл, который удобно вставлять в тело письма.

  3. Будет создан файл message.txt.asc. Его содержимое выглядит как бессмысленный набор символов.

  4. Ольга открывает свой почтовый клиент, создает новое письмо для Игоря и вставляет содержимое файла message.txt.asc в тело письма. Отправляет.

  5. Игорь получает письмо. Он копирует весь блок зашифрованного текста (от -----BEGIN PGP MESSAGE----- до -----END PGP MESSAGE-----) в новый файл, например, letter_from_olga.asc.

  6. Игорь расшифровывает сообщение своим закрытым ключом:

    gpg -d letter_from_olga.asc

    Система запросит парольную фразу Игоря, и на экране появится исходное сообщение от Ольги.

4.3 Шифрование и передача через Telegram

Этот способ абсолютно аналогичен email, но каналом передачи служит мессенджер.

  1. Игорь создает сообщение для Ольги, шифрует его её ключом.

    echo "Пароль от сервера: MyHardPassword123" > secret.txt
gpg -e -r olga@example.com -a secret.txt

  2. Игорь открывает чат с Ольгой в Telegram и отправляет ей содержимое файла secret.txt.asc как обычное текстовое сообщение.

  3. Ольга получает в Telegram сообщение с бессмысленными символами. Она копирует его и сохраняет в файл telegram_secret.asc.

  4. Ольга расшифровывает:

    gpg -d telegram_secret.asc

    Введя свою парольную фразу, она видит пароль от сервера.

5. Подпись файла с шифрованием

Этот режим гарантирует, что сообщение (1) зашифровано и (2) подписано отправителем, что подтверждает его авторство.

Практическое занятие: Игорь подписывает и шифрует

  1. Игорь создает файл proposal.txt.

  2. Он подписывает (-s) и шифрует (-e) его для Ольги.

    gpg -s -e -r olga@example.com -a proposal.txt

  3. Игорь отправляет Ольге полученный proposal.txt.asc (по email/Telegram).

  4. Ольга сохраняет файл и расшифровывает его как обычно:

    gpg -d proposal.txt.asc

    В выводе команды, помимо текста сообщения, она увидит:

    gpg: Signature made ... using ECDSA key ID ...
gpg: Good signature from "Igor Petrov <igor@example.com>"

    Сообщение Good signature означает, что подпись верна и сообщение действительно от Игоря и не было изменено.

6. Подпись файла без шифрования

Если информация не является секретной, но важно подтвердить авторство, используется только подпись.

Практическое занятие: Ольга подписывает публичное объявление

  1. Ольга создает файл announcement.txt.

    echo "Всем сотрудникам: завтра собрание в 10:00." > announcement.txt

  2. Она создает отдельную подпись в текстовом формате:

    gpg --clearsign announcement.txt

    Создается файл announcement.txt.asc. Его содержимое выглядит так:

    -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Всем сотрудникам: завтра собрание в 10:00.
-----BEGIN PGP SIGNATURE-----
...
-----END PGP SIGNATURE-----

    Текст сообщения остается читаемым, а подпись прилагается отдельно.

  3. Ольга рассылает этот файл коллегам (например, по email).

  4. Игорь хочет убедиться, что объявление действительно от Ольги, а не от злоумышленника. Он скачивает файл и проверяет подпись:

    gpg --verify announcement.txt.asc

    Вывод:

    gpg: Signature made ... using ECDSA key ID ...
gpg: Good signature from "Olga <olga@example.com>"

7. Доверительные ключи (Web of Trust)

Когда Игорь импортировал ключ Ольги, GPG выдал предупреждение: There is no assurance that this key belongs to the named user. Система не знает, действительно ли ключ принадлежит Ольге.

Модель “сети доверия” (Web of Trust) решает эту проблему. Если Игорь лично знает Ольгу и уверен, что ключ принадлежит ей, он может подписать её ключ и присвоить ему уровень доверия.

Практическое занятие: Игорь подписывает ключ Ольги

  1. Игорь начинает редактирование ключа Ольги:

    gpg --edit-key olga@example.com

  2. Он попадает в интерактивную оболочку GPG. Вводит команду fpr (fingerprint), чтобы сверить отпечаток ключа. Он звонит Ольге и просит её продиктовать отпечаток её ключа (который она может посмотреть командой gpg --fingerprint olga@example.com). Если отпечатки совпадают — ключ подлинный.

  3. Для подписи ключа вводится команда sign:

    gpg> sign

  4. GPG спросит, уверены ли вы. Подтвердите. Будет запрошена парольная фраза Игоря.

  5. Выйдите из оболочки:

    gpg> quit

  6. Теперь, если кто-то третий импортирует ключ Игоря и ключ Ольги, и будет доверять Игорю, он сможет автоматически доверять и ключу Ольги, так как он подписан Игорем.

Для настройки уровня доверия к ключу используется команда trust внутри gpg --edit-key. Можно установить доверие от “1 = I don’t know” до “5 = I trust ultimately”.

8. Отзыв ключей

Если закрытый ключ скомпрометирован (украден, потерян) или пользователь увольняется, необходимо создать сертификат отзыва и распространить его, чтобы другие знали, что этому ключу больше нельзя доверять.

Практическое занятие: Игорь создает сертификат отзыва (заранее)

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

  1. Игорь создает сертификат отзыва для своего ключа:

    gpg --output revoke_igor.asc --gen-revoke igor@example.com

  2. GPG спросит причину отзыва. Можно выбрать 0 = No reason specified. Будет запрошена парольная фраза Игоря.

  3. Созданный файл revoke_igor.asc Игорь сохраняет на защищенную флешку и (в идеале) распечатывает и кладет в сейф. Удаляет его с жесткого диска.

Если ключ скомпрометирован:

  1. Игорь берет сертификат отзыва из безопасного места.
  2. Импортирует его в свою связку ключей:
    gpg --import revoke_igor.asc
  3. Теперь, если кто-то экспортирует публичный ключ Игоря, он будет содержать информацию об отзыве.
  4. Игорь отправляет свой отозванный публичный ключ на серверы ключей или коллегам, чтобы они обновили информацию.

9. Продление срока действия ключей

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

Практическое занятие: Игорь меняет срок действия ключа

  1. Игорь решает, что его ключ должен истечь через год.

    gpg --edit-key igor@example.com

  2. В интерактивной оболочке выбирает команду для смены срока действия ключа:

    gpg> expire

  3. Указывает новый срок, например, 1y (один год).

  4. Затем необходимо также изменить срок действия подчиненного ключа (ключа шифрования), если он есть. Команда key выбирает подчиненный ключ, затем expire для него.

    gpg> key 1
gpg> expire

  5. Выходит и сохраняет изменения:

    gpg> save

  6. Теперь Игорь должен экспортировать свой новый обновленный публичный ключ и разослать его всем, с кем общается, чтобы они обновили его у себя.

    gpg --export --armor igor@example.com > igor_public_updated.key

10. Способы обмена открытыми ключами

Как Игорь и Ольга могут безопасно обменяться ключами? Передача ключа по незащищенному каналу (email, Telegram) сама по себе не является катастрофой, так как ключ публичный. Но как убедиться, что этот ключ принадлежит именно Ольге, а не злоумышленнику? Вот несколько способов:

  1. Личная встреча (самый надежный): Игорь и Ольга встречаются лично. Игорь приносит свою флешку с ключом. Ольга — свою. Они обмениваются. Дома они импортируют ключи и подписывают их, проверив отпечатки.
  2. Проверка отпечатка по другому каналу: Игорь отправляет Ольге ключ по email. Затем он звонит ей по телефону (или в защищенном мессенджере с включенной проверкой) и диктует отпечаток ключа (gpg --fingerprint igor@example.com). Ольга сверяет этот отпечаток с тем, что показывает gpg --fingerprint для импортированного ключа. Если они совпадают — ключ подлинный.
  3. Серверы ключей: Ключи можно загрузить на специализированные серверы (например, keys.openpgp.org). Это удобно, но не гарантирует подлинность. Вы можете найти много ключей, но не можете быть уверены, кому они принадлежат. Подлинность в этой модели также устанавливается через подписи других людей или проверку отпечатков.
  4. DNS (OPENPGPKEY запись): Администратор домена может разместить публичный ключ сотрудника в DNS-зоне. Почтовые клиенты, поддерживающие этот стандарт (например, Thunderbird с плагином), могут автоматически находить ключ для адресата, и доверие обеспечивается защищенностью DNS (DNSSEC).

На этом мы завершаем обзор ключевых возможностей GPG с использованием современных алгоритмов ECC. Эти навыки позволят Игорю, Ольге и Алексею надежно защищать свою переписку и файлы.

11. Субключи (Subkeys) — разделение обязанностей

При генерации ключа в предыдущих разделах мы создавали “основной” ключ (master key) и один “подчиненный” ключ (subkey). В GPG это происходит автоматически. Но почему система создает два ключа вместо одного? И как этим управлять?

Что такое субключи?

Субключи (subkeys) — это дополнительные пары ключей, привязанные к вашему основному ключу. Основной ключ (master key) используется только для:

  • Создания новых субключей
  • Подписи других ключей (в модели Web of Trust)
  • Изменения атрибутов (например, срока действия)
  • Отзыва всего набора ключей

Субключи используются для повседневных операций:

  • Шифрования файлов и сообщений
  • Создания цифровых подписей (опционально)

Зачем это нужно?

  1. Безопасность: Представьте, что ваш ноутбук украли вместе с ключами. Если на ноутбуке хранился основной ключ, злоумышленник может не только читать вашу почту, но и создавать новые ключи от вашего имени, подписывать документы и отозвать ваш оригинальный ключ, заблокировав вам доступ. Если же на ноутбуке хранится только субключ, а основной ключ лежит в сейфе на зашифрованной флешке, то при краже вы просто отзываете скомпрометированный субключ и создаете новый, не теряя при этом доверия к своей личности.

  2. Разделение ролей: Вы можете создать отдельный субключ для подписи кода (например, для Git-коммитов) и отдельный — для шифрования почты. При необходимости один из них можно отозвать, не затрагивая другой.

  3. Удобство ротации: Субключи можно менять (например, каждый год), оставаясь при том же основном ключе, который удостоверяет вашу личность.

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

11.1 Просмотр структуры ключей

Посмотрим, как выглядят ключи, созданные нами ранее.

Практическое занятие: Игорь анализирует свой ключ

  1. Игорь просматривает детальную информацию о своем ключе:

    gpg --list-secret-keys --keyid-format LONG igor@example.com

    Вывод будет похож на:

    sec   ed25519/AAAAAAAAAAAAAAAA 2026-03-06 [SC]
      ABCDEF1234567890ABCDEF1234567890ABCDEF12
uid                 [ultimate] Igor Petrov <igor@example.com>
ssb   cv25519/BBBBBBBBBBBBBBBB 2026-03-06 [E]

    Расшифровка:

    • sec (secret) — строка, начинающаяся с sec, обозначает основной закрытый ключ. Рядом с ним вы видите [SC] — это означает, что ключ предназначен для Signing (подписи) и Certification (сертификации других ключей).
    • ssb (secret subkey) — строка, начинающаяся с ssb, обозначает закрытый субключ. Маркер [E] означает, что он предназначен для Encryption (шифрования).

    В нашем случае при создании ключа ECC GPG автоматически создал субключ для шифрования (cv25519), так как алгоритм Ed25519 (основной ключ) не поддерживает шифрование, только подпись.

11.2 Создание дополнительных субключей

Что, если Игорю нужен отдельный ключ для подписи Git-коммитов, которым он хочет пользоваться на рабочем ноутбуке, оставив основной ключ дома?

Практическое занятие: Игорь создает новый субключ для подписи

  1. Игорь вставляет флешку с резервной копией основного ключа (или работает на доверенном компьютере, где есть доступ к основному ключу).

  2. Он запускает редактирование ключа:

    gpg --expert --edit-key igor@example.com

  3. В интерактивной оболочке вводит команду для создания нового субключа:

    gpg> addkey

  4. GPG спросит, какой тип ключа создать. Нам нужен ключ для подписи. Выбираем (11) ECC (set your own capabilities).

    Your selection? 11

  5. Настраиваем возможности ключа. По умолчанию включено всё. Нам нужна только подпись, поэтому отключаем шифрование и аутентификацию. Вводим s (toggle sign), e (toggle encrypt), a (toggle authenticate), пока не останется только S.

    Possible actions for this ECC key: Sign Authenticate 
Current allowed actions: Sign 
(S) Toggle sign
(A) Toggle authenticate
(Q) Finished

Your selection? q

  6. Выбираем кривую. Снова выбираем (1) Curve 25519.

  7. Задаем срок действия. Для рабочего ключа можно поставить, например, 1y (один год).

  8. Подтверждаем создание (y).

  9. Сохраняем изменения:

    gpg> save

Теперь у Игоря есть три ключа: основной (SC) и два субключа — один для шифрования [E] и новый для подписи [S].

11.3 Экспорт и использование субключей

Самое важное отличие при работе с субключами — это то, какие ключи экспортировать и где хранить.

  • Полный экспорт (основной ключ + субключи): Используется только для резервного копирования. Этот файл должен храниться оффлайн, в сейфе.

    gpg --export-secret-keys --armor igor@example.com > igor_master_backup.asc
gpg --export-secret-subkeys --armor igor@example.com > igor_subkeys_backup.asc

  • Экспорт только субключей для повседневного использования: Это то, что Игорь скопирует на свой рабочий ноутбук. Основной ключ при этом НЕ экспортируется.

    gpg --export-secret-subkeys --armor igor@example.com > igor_stubs.asc

    На самом деле эта команда экспортирует субключи и так называемые “заглушки” (stubs) для основного ключа — информацию о том, что основной ключ существует, но самого секретного ключа в файле нет.

Практическое занятие: Игорь настраивает рабочий ноутбук

  1. На защищенном компьютере (дома) Игорь создает файл с субключами: gpg --export-secret-subkeys --armor igor@example.com > igor_work_subkeys.asc.

  2. Он переносит этот файл на рабочий ноутбук (по защищенному каналу или на зашифрованной флешке).

  3. На рабочем ноутбуке Игорь импортирует этот файл:

    gpg --import igor_work_subkeys.asc

  4. Теперь Игорь проверяет свои ключи на рабочем ноутбуке:

    gpg --list-secret-keys --keyid-format LONG igor@example.com

    Он увидит:

    sec#  ed25519/AAAAAAAAAAAAAAAA 2026-03-06 [SC]
      ABCDEF1234567890ABCDEF1234567890ABCDEF12
uid                 [unknown] Igor Petrov <igor@example.com>
ssb   cv25519/BBBBBBBBBBBBBBBB 2026-03-06 [E]
ssb   ed25519/CCCCCCCCCCCCCCCC 2026-03-06 [S]

    Обратите внимание на символ # после sec! Он означает, что в связке есть только “заглушка” (stub) основного ключа, но сам секретный ключ отсутствует. Это идеальный режим для повседневной работы.

11.4 Отзыв и замена субключей

Если рабочий ноутбук Игоря украли, он должен отозвать скомпрометированный субключ, но его основной ключ и личность остаются нетронутыми.

Практическое занятие: Игорь отзывает украденный субключ

  1. На защищенном (домашнем) компьютере, где есть доступ к полному основному ключу, Игорь запускает редактирование:

    gpg --expert --edit-key igor@example.com

  2. Он видит список всех ключей. Ему нужно выбрать скомпрометированный субключ. Допустим, это ключ подписи (третий в списке). Он вводит:

    gpg> key 2

    (Нумерация начинается с 0, первый субключ — key 1, второй — key 2). Выбранный ключ пометится звездочкой *.

  3. Затем вводит команду отзыва:

    gpg> revkey

  4. Выбирает причину отзыва, например, 1 = Key has been compromised (ключ скомпрометирован).

  5. Подтверждает действие и вводит парольную фразу.

  6. Сохраняет изменения:

    gpg> save

  7. Игорь экспортирует обновленный публичный ключ и рассылает его коллегам или загружает на сервер ключей:

    gpg --export --armor igor@example.com > igor_public_revoked.asc

Теперь, когда Ольга получит обновленный ключ Игоря и импортирует его, она увидит, что один из субключей отозван. Сообщения, зашифрованные на старый (скомпрометированный) ключ, она все еще сможет прочитать (так как у нее, возможно, есть копия), но новые сообщения она будет шифровать только на действующие субключи.

Создание нового субключа взамен отозванного:

Процедура аналогична созданию нового субключа (как в разделе 11.2). Игорь просто добавляет новый субключ для подписи. Старый, отозванный, остается в связке как историческая запись, но больше не используется.

11.5 Особенности работы с субключами

  1. Публичный ключ един: Все субключи привязаны к одному основному ключу. Поэтому, когда вы экспортируете публичный ключ командой gpg --export, он автоматически включает в себя все субключи и всю информацию об отзывах.
  2. Обновление ключей у контрагентов: После изменения субключей (добавления, отзыва, продления срока) вы должны передать обновленный публичный ключ всем, с кем переписываетесь. Иначе они будут пытаться шифровать сообщения для вас на старый (возможно, отозванный) ключ.
  3. Срок действия: Срок действия основного ключа и субключей может быть разным. Обычно основной ключ делают с очень долгим сроком (5-10 лет) или бессрочным, а субключи регулярно обновляют (раз в год).
  4. Подпись ключей контрагентов: Для подписи чужих ключей (в модели Web of Trust) требуется основной ключ. Если вы используете только субключи на рабочей машине, вы не сможете подписать ключ коллеги. Для этой операции вам потребуется доступ к основному ключу (например, временно подключить флешку с ним).

Использование субключей с хранением основного ключа оффлайн — это стандарт промышленной безопасности при работе с GPG. Это позволяет минимизировать ущерб от компрометации рабочей станции и сохранить контроль над своей криптографической личностью.

CVSS: анализ векторов атак. Мини-курс по оценке уязвимостей
Шифрование разделов и каталогов (LUKS2, fscrypt, systemd-homed)