Какова связь между ключом OpenPGP и его подразделом?
Я исхожу из использования старого доброго RSA с OpenSSL для всех моих асимметричных потребностей в шифровании, что я довольно хорошо усвоил, но мне тяжело обдумывать протокол OpenPGP. Таким образом, это будет несколько вопросов.
В моем окне Debian, используя GnuPG, при создании мастер-ключа в текущей цепочке для ключей я заметил создание подключа по умолчанию. После небольшого прочтения я узнал, что GnuPG автоматически управляет ключами; мастер-ключ используется исключительно для подписи, а подключ - исключительно для шифрования. Это заставило меня поверить в то, что у них просто были разные имена для закрытого и открытого ключа: главный ключ (например, закрытый ключ) использовался для подписи данных, которые может расшифровать только подраздел (открытый ключ), но подраздел (ключ) открытый ключ) может шифровать только данные, которые затем могут быть расшифрованы только главным ключом (личным ключом). Я прав в этом предположении или это две отдельные пары ключей в целом?
Если это две отдельные пары ключей, что математически связывает подключ с главным ключом?
Это просто GnuPG, который использует этот метод, где автоматически создается подраздел для шифрования, или это предписано протоколом OpenPGP?
Когда я загружаю ключ на сервер ключей, какой ключ загружается, мой главный ключ или подраздел? Или оба?
Когда я использую --export функция, какой ключ OpenPGP экспортируется, когда я указываю свой UID?
2 ответа
О первичных ключах и подключах
Главный ключ (например, закрытый ключ) использовался для подписи данных, которые может расшифровывать только подключ (открытый ключ), но подключ (открытый ключ) мог только шифровать данные, которые затем могли быть расшифрованы только главным ключом (закрытый ключ). Я прав в этом предположении или это две отдельные пары ключей в целом?
Вы не совсем поняли концепцию криптографии с открытым / закрытым ключом (также называемой ассиметричной). Каждый набор открытых и закрытых ключей разделен, вы публикуете открытый ключ, чтобы другие могли его использовать и сохранить закрытый ключ закрытым. Подписи, выданные закрытым ключом, могут быть проверены с помощью открытого ключа, сообщения, зашифрованные с использованием открытого ключа, могут быть расшифрованы с помощью закрытого ключа. В OpenPGP нет непосредственной связи между парами первичного ключа и подключа, это абсолютно разные пары ключей.
Это просто GnuPG, который использует этот метод, где автоматически создается подраздел для шифрования, или это предписано протоколом OpenPGP?
Настройка по умолчанию в GnuPG - у вас есть пара первичных ключей, используемых для сертификации и подписей, в то время как подраздел шифрования используется только для шифрования. Используя RSA, вы также можете генерировать первичные ключи, поддерживающие все эти операции (а также с GnuPG и --expert флаг, можно!). Это в основном из-за других алгоритмов, таких как DSA и Elgamal, которые поддерживают только одну из операций (DSA только для подписи, Elgamal для шифрования), где вам нужно иметь разные ключи.
Есть также некоторое преимущество в наличии разных ключей для разных видов использования: рассмотрим обнаруженный недостаток, который позволяет при определенных условиях вычислить закрытый ключ из подписей. В то время как ваш ключ подписи будет целевым, подраздел шифрования является другим и не предназначен для этой атаки. Некоторые люди даже считают целесообразным ограничить первичный ключ только сертификацией, и добавление двух пар подразделов является наилучшей практикой: одна для подписи, другая для шифрования.
Обязательные подписи
Если это две отдельные пары ключей, что математически связывает подключ с главным ключом?
В OpenPGP особый вид подписи привязки выдается при создании подключа. Подключи, способные к подписи, также могут выдавать такую обязательную подпись на первичном ключе. Эти специальные подписи определены в RFC 4880, OpenPGP, 5.2.1. Типы подписей:
0x18: Subkey Binding Signature
This signature is a statement by the top-level signing key that
indicates that it owns the subkey. This signature is calculated
directly on the primary key and subkey, and not on any User ID or
other packets. A signature that binds a signing subkey MUST have
an Embedded Signature subpacket in this binding signature that
contains a 0x19 signature made by the signing subkey on the
primary key and subkey.
0x19: Primary Key Binding Signature
This signature is a statement by a signing subkey, indicating
that it is owned by the primary key and subkey. This signature
is calculated the same way as a 0x18 signature: directly on the
primary key and subkey, and not on any User ID or other packets.
Адресация подразделов в GnuPG
Когда я загружаю ключ на сервер ключей, какой ключ загружается, мой главный ключ или подраздел? Или оба?
Когда я использую
--exportфункция, какой ключ OpenPGP экспортируется, когда я указываю свой UID?
Обычно в GnuPG идентификаторы ключей и идентификаторы всегда разрешаются в первичный ключ. Все операции экспорта (и выгрузка на сервер ключей также считаются экспортом) также экспортируют подключи, идентификаторы пользователей и сертификаты на ваш ключ. Подобные вещи существуют для других операций, таких как подписывание и шифрование. Если вы действительно хотите обозначить подраздел для операций, вы должны добавить ! за подразделом (например, gpg --recipient 0xDEADBEEF! --encrypt).
Мне нравится думать об отношениях между главным ключом и подключами, как об отношениях между центром сертификации (CA) и сертификатами, которые он подписывает и выпускает. Третьи стороны, пытающиеся подтвердить сертификаты, устанавливают доверительные отношения с ЦС и используют его открытый ключ для проверки своей подписи выданных им сертификатов. Точно так же у вас есть другие люди, которые проверяют ваш главный ключ PGP и подписывают его (т. Е. Вся децентрализованная сеть паутины доверия). Затем вы используете свои подразделы для всей практической работы по подписанию и шифрованию данных. Когда другие хотят подтвердить достоверность подключей, они используют тот факт, что ваш главный ключ является (надеюсь) доверенным (поскольку он был подписан другими доверенными ключами), а затем может быть использован для проверки подписи на подключах, тем самым устанавливая подключи как доверенные.
Мастер-ключи следует использовать редко, кроме таких вещей, как подпись новых подразделов.