Я меняю свой PGP ключ

Я создал свой ключ 0xC48251EB4F8E4E6E в 2007 году, когда начал писать проект DiskCryptor, ключ создавался с настройками по-умолчанию, без прицела на долговременную безопасность, поэтому он использует DSA-1024 и sha1. SHA1 уже взломан и вот-вот следует ожидать практических коллизий, в достаточности DSA-1024 на ближайшие 10 лет тоже есть сомнения. В связи с вышесказанным, а также из других соображений, созрела мысль заменить ключ в ближайшее время, чем раньше это сделать – тем безболезненнее будет процесс.
Новый ключ я собираюсь сгенерировать по-уму и хранить с соблюдением повышенных мер безопасности, чтобы в идеале больше не понадобилось его менять никогда. А чтобы сделать всё идеально я хочу проконсультироваться со знатоками GnuPG насчет наилучших настроек и желательного комплекса мер при создании, хранении и использовании ключа.

Специально для параноиков: этот пост я пишу в трезвом уме и твердой памяти, не находясь под принуждением.

Комментарии

— unknown (09/08/2011 09:47, исправлен 22/06/2015 07:20)

Кое что^[link1] по этой теме есть. Хотя можно ещё обсудить и дополнить для совсем параноидально-гиковских вариантов.

Например, связку ключей можно разобрать на отдельные подключи и UID'ы с подписями, назначить им разные пароли и из этого собрать связку обратно. Можно имеющимся у вас пока старым ключом заверения связки не просто подписать новый ключ (связку), а вынести его из связки главного нынешнего ключа и внести в новую связку в качестве подключа и уже там объявить отозванным.

Это всё требует включения нестандартных опций GnuPG, работы под разными пользователями и правки в HEX-редакторе. Имеется шанс остаться без ключа (если не сбэкапить), но если всё протестить и проверить в узком кругу, то скорее всего такой нестандартный ключ будет успешно работать. Правда, мало кто сможет оценить такое утончённое использование GnuPG :-) Скорее ради хохмы только.

— SATtva (09/08/2011 09:59)

Правда, мало кто сможет оценить такое утончённое использование GnuPG :-)

Ну, мы-то точно поставим высший балл за артистизм и за технику.

— unknown (09/08/2011 10:19, исправлен 09/08/2011 10:19)

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

— Гость (09/08/2011 12:13)
Генерирую ключ следуя указаниям из статьи и делаю дамп его пакетов. Получается что-то вроде этого:

:public key packet:
	version 4, algo 1, created 1312876894, expires 0
	pkey[0]: [4096 bits]
	pkey[1]: [17 bits]
:user ID packet: "testaa"
:signature packet: algo 1, keyid 1560BE8524397F05
	version 4, created 1312876894, md5len 0, sigclass 0x13
	digest algo 2, begin of digest b2 f8
	hashed subpkt 2 len 4 (sig created 2011-08-09)
	hashed subpkt 27 len 1 (key flags: 03)
	hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
	hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
	hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
	hashed subpkt 30 len 1 (features: 01)
	hashed subpkt 23 len 1 (key server preferences: 80)
	subpkt 16 len 8 (issuer key ID 1560BE8524397F05)
	data: [4095 bits]

version 4, algo 1 – по спецификации асимметрик с номером 1 это RSA (Encrypt or Sign) [HAC], хотя я создавал sign-only ключ.
digest algo 2 – это SHA-1 [FIPS180], хотя у меня в gpg.conf прописан digest-algo sha512

Как полностью избавиться от sha1 и не грозит ли это серьезными проблемами с совместимостью?

— SATtva (09/08/2011 12:21)
Избавиться от SHA-1 прям полностью, увы, невозможно — кое-где он захардкоден в стандарт. Например, отпечаток ключа всегда вычисляется по SHA-1.

— Гость (09/08/2011 12:38)
Использование sha1 для подписи блоков ключа тоже захардкодено, или это настраивается?

— sentaus (09/08/2011 12:41)

хотя у меня в gpg.conf прописан digest-algo sha512

Это для подписи данных, а для подписей сертификатов ключей надо "cert-digest-algo sha512".

— SATtva (09/08/2011 12:46)

хотя у меня в gpg.conf прописан digest-algo sha512

Более того, использование этой опции как раз-таки повлечёт проблемы несовместимости — она принудительно задаёт алгоритм хэширование данных, игнорируя предпочтения в ключе получателя.

— sentaus (09/08/2011 12:47, исправлен 09/08/2011 12:48)

не грозит ли это серьезными проблемами с совместимостью

Может грозить совместимостью со старыми версиями, но в случае с gpg это не очень актуально. Другой вопрос – PGP, там сейчас вроде sha256 применяется. Так что надо бы проверить, умеет ли она sha512 хотя бы проверять, а то вдруг ее пользователи не смогут понимать эти подписи.

Я точно знаю, что с sha512 полностью несовместимы версии 8.x, при этом 8.1 умеет проверять подписи с sha256, но не генерировать их. Более поздними не пользовался.

— Гость (09/08/2011 13:01)
При работе с подключами можно сделать вот что [поправьте, где не прав]. Имея один главный подключ для подписи, подписывать им дополнительные подключи для шифрования. С точки зрения конечного пользователя это будет как бы один PGP-ключ, который иногда нужно "продлевать" скопировав себе его копию с keyserver'а. С другой стороны, при замене подключа шифрования на другой, вся информация, зашифрованная предыдущим подключом уже невскрываема, если владелец PGP-ключа удалил у себя все его старые копии (и старые подключи со связки). Это может быть использовано для защиты от силового принуждения к выдаче ключа (PFS или как оно там). Т.е. вместо создания главного PGP-ключа для подписи других "временных" PGP-ключей, можно всё то же делать в рамках подключей одного и того же PGP-ключа.

— unknown (09/08/2011 14:58, исправлен 01/02/2015 12:50)

Именно это и описано в инструкции^[link1], более подробно эту мысль раскрывали здесь^[link2].

— ntldr (09/08/2011 18:23)
Создал новый ключ, вот его дамп:

:public key packet:
	version 4, algo 1, created 1312891435, expires 0
	pkey[0]: [4096 bits]
	pkey[1]: [17 bits]
:user ID packet: "ntldr (pgpru.com user, diskcryptor.net admin)"
:signature packet: algo 1, keyid 1385C07275430121
	version 4, created 1312891435, md5len 0, sigclass 0x13
	digest algo 8, begin of digest d4 90
	hashed subpkt 2 len 4 (sig created 2011-08-09)
	hashed subpkt 27 len 1 (key flags: 03)
	hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
	hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
	hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
	hashed subpkt 30 len 1 (features: 01)
	hashed subpkt 23 len 1 (key server preferences: 80)
	subpkt 16 len 8 (issuer key ID 1385C07275430121)
	data: [4096 bits]
:user ID packet: "ntldr <ntldr@diskcryptor.net>"
:signature packet: algo 1, keyid 1385C07275430121
	version 4, created 1312891967, md5len 0, sigclass 0x13
	digest algo 8, begin of digest d6 17
	hashed subpkt 2 len 4 (sig created 2011-08-09)
	hashed subpkt 27 len 1 (key flags: 03)
	hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
	hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
	hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
	hashed subpkt 30 len 1 (features: 01)
	hashed subpkt 23 len 1 (key server preferences: 80)
	subpkt 16 len 8 (issuer key ID 1385C07275430121)
	data: [4096 bits]
:public sub key packet:
	version 4, algo 1, created 1312892170, expires 0
	pkey[0]: [2048 bits]
	pkey[1]: [17 bits]
:signature packet: algo 1, keyid 1385C07275430121
	version 4, created 1312892170, md5len 0, sigclass 0x18
	digest algo 8, begin of digest ee 78
	hashed subpkt 2 len 4 (sig created 2011-08-09)
	hashed subpkt 27 len 1 (key flags: 02)
	hashed subpkt 9 len 4 (key expires after 4y146d0h0m)
	subpkt 16 len 8 (issuer key ID 1385C07275430121)
	subpkt 32 len 283 (signature: v4, class 0x19, algo 1, digest algo 8)
	data: [4094 bits]
:public sub key packet:
	version 4, algo 1, created 1312892531, expires 0
	pkey[0]: [2048 bits]
	pkey[1]: [17 bits]
:signature packet: algo 1, keyid 1385C07275430121
	version 4, created 1312892531, md5len 0, sigclass 0x18
	digest algo 8, begin of digest da 6d
	hashed subpkt 2 len 4 (sig created 2011-08-09)
	hashed subpkt 27 len 1 (key flags: 0C)
	hashed subpkt 9 len 4 (key expires after 4y146d0h0m)
	subpkt 16 len 8 (issuer key ID 1385C07275430121)
	data: [4096 bits]

Всё ли правильно?
В preferences ключа первым стоит SHA256, но почему-то при подписи используется sha1 если не прописать digest-algo sha256 в gpg.conf.
Похоже что GnuPG игнорирует предпочтения для хэшей при подписи.

— Гость (09/08/2011 20:44)

более подробно эту мысль раскрывали здесь.

Спасибо за ссылку. Увы, в 2005ом году ещё не читал этот форум :(

2 ntldr:

— unknown (09/08/2011 22:00, исправлен 09/08/2011 22:01)

Попробуйте установить утилиту pgpdump и прикладывать дамп сразу в двух форматах.

Как сейчас:
gpg --export [keyname] | gpg --list-packets

И в таком виде:
gpg --export [keyname] | pgpdump

Может что-то вылезет, сходу незаметное глазу.

— ntldr (10/08/2011 08:04, исправлен 10/08/2011 08:06)

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

gpg --export [keyname] | gpg --list-packets
:public key packet: version 4, algo 1, created 1312891435, expires 0 pkey[0]: [4096 bits] pkey[1]: [17 bits] :user ID packet: "ntldr (pgpru.com user) <ntldr@pgpru.com>" :signature packet: algo 1, keyid 1385C07275430121 version 4, created 1312948687, md5len 0, sigclass 0x13 digest algo 8, begin of digest 91 45 hashed subpkt 2 len 4 (sig created 2011-08-10) hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2) hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11) hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (key server preferences: 80) subpkt 16 len 8 (issuer key ID 1385C07275430121) data: [4090 bits] :user ID packet: "ntldr (DiskCryptor dev) <ntldr@diskcryptor.net>" :signature packet: algo 1, keyid 1385C07275430121 version 4, created 1312948752, md5len 0, sigclass 0x13 digest algo 8, begin of digest 58 36 hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2) hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11) hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (key server preferences: 80) hashed subpkt 2 len 4 (sig created 2011-08-10) hashed subpkt 25 len 1 (primary user ID) subpkt 16 len 8 (issuer key ID 1385C07275430121) data: [4094 bits] :public sub key packet: version 4, algo 1, created 1312892170, expires 0 pkey[0]: [2048 bits] pkey[1]: [17 bits] :signature packet: algo 1, keyid 1385C07275430121 version 4, created 1312892170, md5len 0, sigclass 0x18 digest algo 8, begin of digest ee 78 hashed subpkt 2 len 4 (sig created 2011-08-09) hashed subpkt 27 len 1 (key flags: 02) hashed subpkt 9 len 4 (key expires after 4y146d0h0m) subpkt 16 len 8 (issuer key ID 1385C07275430121) subpkt 32 len 283 (signature: v4, class 0x19, algo 1, digest algo 8) data: [4094 bits] :public sub key packet: version 4, algo 1, created 1312892531, expires 0 pkey[0]: [2048 bits] pkey[1]: [17 bits] :signature packet: algo 1, keyid 1385C07275430121 version 4, created 1312892531, md5len 0, sigclass 0x18 digest algo 8, begin of digest da 6d hashed subpkt 2 len 4 (sig created 2011-08-09) hashed subpkt 27 len 1 (key flags: 0C) hashed subpkt 9 len 4 (key expires after 4y146d0h0m) subpkt 16 len 8 (issuer key ID 1385C07275430121) data: [4096 bits]
gpg --export [keyname] | pgpdump
Old: Public Key Packet(tag 6)(525 bytes) Ver 4 - new Public key creation time - Tue Aug 9 12:03:55 UTC 2011 Pub alg - RSA Encrypt or Sign(pub 1) RSA n(4096 bits) - ... RSA e(17 bits) - ... Old: User ID Packet(tag 13)(40 bytes) User ID - ntldr (pgpru.com user) <ntldr@pgpru.com> Old: Signature Packet(tag 2)(568 bytes) Ver 4 - new Sig type - Positive certification of a User ID and Public Key packet(0x13). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA256(hash 8) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Wed Aug 10 03:58:07 UTC 2011 Hashed Sub: key flags(sub 27)(1 bytes) Flag - This key may be used to certify other keys Flag - This key may be used to sign data Hashed Sub: preferred symmetric algorithms(sub 11)(5 bytes) Sym alg - AES with 256-bit key(sym 9) Sym alg - AES with 192-bit key(sym 8) Sym alg - AES with 128-bit key(sym 7) Sym alg - CAST5(sym 3) Sym alg - Triple-DES(sym 2) Hashed Sub: preferred hash algorithms(sub 21)(5 bytes) Hash alg - SHA256(hash 8) Hash alg - SHA1(hash 2) Hash alg - SHA384(hash 9) Hash alg - SHA512(hash 10) Hash alg - SHA224(hash 11) Hashed Sub: preferred compression algorithms(sub 22)(3 bytes) Comp alg - ZLIB <RFC1950>(comp 2) Comp alg - BZip2(comp 3) Comp alg - ZIP <RFC1951>(comp 1) Hashed Sub: features(sub 30)(1 bytes) Flag - Modification detection (packets 18 and 19) Hashed Sub: key server preferences(sub 23)(1 bytes) Flag - No-modify Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0x1385C07275430121 Hash left 2 bytes - 91 45 RSA m^d mod n(4090 bits) - ... -> PKCS-1 Old: User ID Packet(tag 13)(47 bytes) User ID - ntldr (DiskCryptor dev) <ntldr@diskcryptor.net> Old: Signature Packet(tag 2)(571 bytes) Ver 4 - new Sig type - Positive certification of a User ID and Public Key packet(0x13). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA256(hash 8) Hashed Sub: key flags(sub 27)(1 bytes) Flag - This key may be used to certify other keys Flag - This key may be used to sign data Hashed Sub: preferred symmetric algorithms(sub 11)(5 bytes) Sym alg - AES with 256-bit key(sym 9) Sym alg - AES with 192-bit key(sym 8) Sym alg - AES with 128-bit key(sym 7) Sym alg - CAST5(sym 3) Sym alg - Triple-DES(sym 2) Hashed Sub: preferred hash algorithms(sub 21)(5 bytes) Hash alg - SHA256(hash 8) Hash alg - SHA1(hash 2) Hash alg - SHA384(hash 9) Hash alg - SHA512(hash 10) Hash alg - SHA224(hash 11) Hashed Sub: preferred compression algorithms(sub 22)(3 bytes) Comp alg - ZLIB <RFC1950>(comp 2) Comp alg - BZip2(comp 3) Comp alg - ZIP <RFC1951>(comp 1) Hashed Sub: features(sub 30)(1 bytes) Flag - Modification detection (packets 18 and 19) Hashed Sub: key server preferences(sub 23)(1 bytes) Flag - No-modify Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Wed Aug 10 03:59:12 UTC 2011 Hashed Sub: primary User ID(sub 25)(1 bytes) Primary - Yes Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0x1385C07275430121 Hash left 2 bytes - 58 36 RSA m^d mod n(4094 bits) - ... -> PKCS-1 Old: Public Subkey Packet(tag 14)(269 bytes) Ver 4 - new Public key creation time - Tue Aug 9 12:16:10 UTC 2011 Pub alg - RSA Encrypt or Sign(pub 1) RSA n(2048 bits) - ... RSA e(17 bits) - ... Old: Signature Packet(tag 2)(835 bytes) Ver 4 - new Sig type - Subkey Binding Signature(0x18). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA256(hash 8) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Tue Aug 9 12:16:10 UTC 2011 Hashed Sub: key flags(sub 27)(1 bytes) Flag - This key may be used to sign data Hashed Sub: key expiration time(sub 9)(4 bytes) Time - Fri Jan 1 12:16:10 UTC 2016 Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0x1385C07275430121 Sub: embedded signature(sub 32)(283 bytes) Ver 4 - new Sig type - Primary Key Binding Signature(0x19). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA256(hash 8) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Tue Aug 9 12:16:10 UTC 2011 Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0xC343E544C7212533 Hash left 2 bytes - 78 02 RSA m^d mod n(2040 bits) - ... -> PKCS-1 Hash left 2 bytes - ee 78 RSA m^d mod n(4094 bits) - ... -> PKCS-1 Old: Public Subkey Packet(tag 14)(269 bytes) Ver 4 - new Public key creation time - Tue Aug 9 12:22:11 UTC 2011 Pub alg - RSA Encrypt or Sign(pub 1) RSA n(2048 bits) - ... RSA e(17 bits) - ... Old: Signature Packet(tag 2)(549 bytes) Ver 4 - new Sig type - Subkey Binding Signature(0x18). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA256(hash 8) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Tue Aug 9 12:22:11 UTC 2011 Hashed Sub: key flags(sub 27)(1 bytes) Flag - This key may be used to encrypt communications Flag - This key may be used to encrypt storage Hashed Sub: key expiration time(sub 9)(4 bytes) Time - Fri Jan 1 12:22:11 UTC 2016 Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0x1385C07275430121 Hash left 2 bytes - da 6d RSA m^d mod n(4096 bits) - ... -> PKCS-1

— unknown (10/08/2011 10:44, исправлен 10/08/2011 11:37)

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

При этом оба подключа имеют Pub alg – RSA Encrypt or Sign(pub 1), но подписывающий: Flag – This key may be used to sign data, а шифровальный Flag – This key may be used to encrypt communications / Flag – This key may be used to encrypt storage — это нормально.

В 2009 году проблему наилучших вариантов миграции с SHA-1 активно обсуждали в дебиановском блоге^[link3], там есть наглядные примеры (см. также коментарии) и в рассылке gnupg^[link4], но похоже так ни до чего и не договорились. Хотя рекомендации Апача^[link5] сходятся с дебиановским решением. Вполне можно ориентироваться на эти способы ухода с SHA-1.

Для создания новых и отчасти использования старых ключей добавить строки в gpg.conf:
#To use SHA512 (recommended): personal-digest-preferences SHA512 cert-digest-algo SHA512 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

или для большей совместимости:

#To use SHA256: personal-digest-preferences SHA256 cert-digest-algo SHA256 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

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

gpg --edit-key [keyname]

Command> showpref Command> setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed Command> showpref Command> save

Не забыть отправить на сервер обновлённую версию ключа.

— ntldr (10/08/2011 13:29)

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

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

— unknown (10/08/2011 14:35)
Удалить старый UID и после этого добавить новый можно. Только удалить на серверах открытых ключей это нельзя. Можно только отзывать UID, также как и открытый подключ.

Кроме того, инструкция задумана с тем, чтобы на разных машинах пользователь имел возможность применять разные подписи (и разные UID'ы) соответственно. Для этого перед экспортированием проще удалять лишние UID'ы и подключи со связки, а не трогать primary UID.

— ntldr (10/08/2011 14:41, исправлен 10/08/2011 14:43)

Еще вылезла одна странная проблема. Генерирую новый ключ как в инструкции, делаю gpg --list-sigs 0x3DC2A42E

pub 4096R/3DC2A42E 2011-08-10 uid ntldr (diskcryptor.net admin) <ntldr@diskcryptor.net> sig 3 3DC2A42E 2011-08-10 ntldr (diskcryptor.net admin) <ntldr@diskcryptor.net> uid ntldr <ntldr@pgpru.com> sig 3 3DC2A42E 2011-08-10 ntldr (diskcryptor.net admin) <ntldr@diskcryptor.net> sub 2048R/74172768 2011-08-10 [expires: 2016-01-01] sig 3DC2A42E 2011-08-10 ntldr (diskcryptor.net admin) <ntldr@diskcryptor.net> sub 2048R/AE1ABE58 2011-08-10 [expires: 2016-01-01] sig 3DC2A42E 2011-08-10 ntldr (diskcryptor.net admin) <ntldr@diskcryptor.net>
В ключе по одной подписи на каждый UID и subkey. Теперь делаю export-secret-subkeys и импортирую subkeys.gpg и pubkey.gpg в рабочую среду. Делаю gpg --list-sigs 0x3DC2A42E

pub 4096R/3DC2A42E 2011-08-10 uid ntldr (diskcryptor.net admin) <ntldr@diskcryptor.net> sig 3 3DC2A42E 2011-08-10 ntldr (diskcryptor.net admin) <ntldr@diskcryptor.net> sig 3 3DC2A42E 2011-08-10 ntldr (diskcryptor.net admin) <ntldr@diskcryptor.net> uid ntldr <ntldr@pgpru.com> sig 3 3DC2A42E 2011-08-10 ntldr (diskcryptor.net admin) <ntldr@diskcryptor.net> sub 2048R/74172768 2011-08-10 [expires: 2016-01-01] sig 3DC2A42E 2011-08-10 ntldr (diskcryptor.net admin) <ntldr@diskcryptor.net> sub 2048R/AE1ABE58 2011-08-10 [expires: 2016-01-01] sig 3DC2A42E 2011-08-10 ntldr (diskcryptor.net admin) <ntldr@diskcryptor.net>
Подпись у первого UID почему-то продублировалась. Дублирование происходит независимо от того, в каком порядке я импортирую открытые ключи и секретные подключи. Если импортировать только подключи, то теряется настройка primari UID.
Дамп ключа после импорта:

Old: Public Key Packet(tag 6)(525 bytes) Ver 4 - new Public key creation time - Wed Aug 10 09:08:18 UTC 2011 Pub alg - RSA Encrypt or Sign(pub 1) RSA n(4096 bits) - ... RSA e(17 bits) - ... Old: User ID Packet(tag 13)(53 bytes) User ID - ntldr (diskcryptor.net admin) <ntldr@diskcryptor.net> Old: Signature Packet(tag 2)(567 bytes) Ver 4 - new Sig type - Positive certification of a User ID and Public Key packet(0x13). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA256(hash 8) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Wed Aug 10 09:08:18 UTC 2011 Hashed Sub: key flags(sub 27)(1 bytes) Flag - This key may be used to certify other keys Flag - This key may be used to sign data Hashed Sub: preferred symmetric algorithms(sub 11)(4 bytes) Sym alg - AES with 256-bit key(sym 9) Sym alg - AES with 192-bit key(sym 8) Sym alg - AES with 128-bit key(sym 7) Sym alg - CAST5(sym 3) Hashed Sub: preferred hash algorithms(sub 21)(4 bytes) Hash alg - SHA512(hash 10) Hash alg - SHA384(hash 9) Hash alg - SHA256(hash 8) Hash alg - SHA224(hash 11) Hashed Sub: preferred compression algorithms(sub 22)(4 bytes) Comp alg - ZLIB <RFC1950>(comp 2) Comp alg - BZip2(comp 3) Comp alg - ZIP <RFC1951>(comp 1) Comp alg - Uncompressed(comp 0) Hashed Sub: features(sub 30)(1 bytes) Flag - Modification detection (packets 18 and 19) Hashed Sub: key server preferences(sub 23)(1 bytes) Flag - No-modify Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0x83D36C793DC2A42E Hash left 2 bytes - f7 c8 RSA m^d mod n(4096 bits) - ... -> PKCS-1 Old: Signature Packet(tag 2)(570 bytes) Ver 4 - new Sig type - Positive certification of a User ID and Public Key packet(0x13). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA256(hash 8) Hashed Sub: key flags(sub 27)(1 bytes) Flag - This key may be used to certify other keys Flag - This key may be used to sign data Hashed Sub: preferred symmetric algorithms(sub 11)(4 bytes) Sym alg - AES with 256-bit key(sym 9) Sym alg - AES with 192-bit key(sym 8) Sym alg - AES with 128-bit key(sym 7) Sym alg - CAST5(sym 3) Hashed Sub: preferred hash algorithms(sub 21)(4 bytes) Hash alg - SHA512(hash 10) Hash alg - SHA384(hash 9) Hash alg - SHA256(hash 8) Hash alg - SHA224(hash 11) Hashed Sub: preferred compression algorithms(sub 22)(4 bytes) Comp alg - ZLIB <RFC1950>(comp 2) Comp alg - BZip2(comp 3) Comp alg - ZIP <RFC1951>(comp 1) Comp alg - Uncompressed(comp 0) Hashed Sub: features(sub 30)(1 bytes) Flag - Modification detection (packets 18 and 19) Hashed Sub: key server preferences(sub 23)(1 bytes) Flag - No-modify Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Wed Aug 10 09:10:01 UTC 2011 Hashed Sub: primary User ID(sub 25)(1 bytes) Primary - Yes Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0x83D36C793DC2A42E Hash left 2 bytes - 0c f1 RSA m^d mod n(4096 bits) - ... -> PKCS-1 Old: User ID Packet(tag 13)(23 bytes) User ID - ntldr <ntldr@pgpru.com> Old: Signature Packet(tag 2)(567 bytes) Ver 4 - new Sig type - Positive certification of a User ID and Public Key packet(0x13). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA256(hash 8) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Wed Aug 10 09:09:27 UTC 2011 Hashed Sub: key flags(sub 27)(1 bytes) Flag - This key may be used to certify other keys Flag - This key may be used to sign data Hashed Sub: preferred symmetric algorithms(sub 11)(4 bytes) Sym alg - AES with 256-bit key(sym 9) Sym alg - AES with 192-bit key(sym 8) Sym alg - AES with 128-bit key(sym 7) Sym alg - CAST5(sym 3) Hashed Sub: preferred hash algorithms(sub 21)(4 bytes) Hash alg - SHA512(hash 10) Hash alg - SHA384(hash 9) Hash alg - SHA256(hash 8) Hash alg - SHA224(hash 11) Hashed Sub: preferred compression algorithms(sub 22)(4 bytes) Comp alg - ZLIB <RFC1950>(comp 2) Comp alg - BZip2(comp 3) Comp alg - ZIP <RFC1951>(comp 1) Comp alg - Uncompressed(comp 0) Hashed Sub: features(sub 30)(1 bytes) Flag - Modification detection (packets 18 and 19) Hashed Sub: key server preferences(sub 23)(1 bytes) Flag - No-modify Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0x83D36C793DC2A42E Hash left 2 bytes - 98 d0 RSA m^d mod n(4096 bits) - ... -> PKCS-1 Old: Public Subkey Packet(tag 14)(269 bytes) Ver 4 - new Public key creation time - Wed Aug 10 09:13:05 UTC 2011 Pub alg - RSA Encrypt or Sign(pub 1) RSA n(2048 bits) - ... RSA e(17 bits) - ... Old: Signature Packet(tag 2)(836 bytes) Ver 4 - new Sig type - Subkey Binding Signature(0x18). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA256(hash 8) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Wed Aug 10 09:13:05 UTC 2011 Hashed Sub: key flags(sub 27)(1 bytes) Flag - This key may be used to sign data Hashed Sub: key expiration time(sub 9)(4 bytes) Time - Fri Jan 1 09:13:05 UTC 2016 Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0x83D36C793DC2A42E Sub: embedded signature(sub 32)(284 bytes) Ver 4 - new Sig type - Primary Key Binding Signature(0x19). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA256(hash 8) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Wed Aug 10 09:13:05 UTC 2011 Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0x6E632E9774172768 Hash left 2 bytes - 05 63 RSA m^d mod n(2047 bits) - ... -> PKCS-1 Hash left 2 bytes - 10 52 RSA m^d mod n(4096 bits) - ... -> PKCS-1 Old: Public Subkey Packet(tag 14)(269 bytes) Ver 4 - new Public key creation time - Wed Aug 10 09:19:13 UTC 2011 Pub alg - RSA Encrypt or Sign(pub 1) RSA n(2048 bits) - ... RSA e(17 bits) - ... Old: Signature Packet(tag 2)(549 bytes) Ver 4 - new Sig type - Subkey Binding Signature(0x18). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA256(hash 8) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Wed Aug 10 09:19:13 UTC 2011 Hashed Sub: key flags(sub 27)(1 bytes) Flag - This key may be used to encrypt communications Flag - This key may be used to encrypt storage Hashed Sub: key expiration time(sub 9)(4 bytes) Time - Fri Jan 1 09:19:13 UTC 2016 Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0x83D36C793DC2A42E Hash left 2 bytes - f0 66 RSA m^d mod n(4096 bits) - ... -> PKCS-1

— unknown (10/08/2011 15:01)
gpg --list-secret-keys что показывает после экспорта-импорта?

— ntldr (10/08/2011 15:06)

sec#  4096R/3DC2A42E 2011-08-10
uid                  ntldr (diskcryptor.net admin) <ntldr@diskcryptor.net>
uid                  ntldr <ntldr@pgpru.com>
ssb   2048R/74172768 2011-08-10
ssb   2048R/AE1ABE58 2011-08-10

— unknown (10/08/2011 15:25)
Тогда непонятно.

— ntldr (11/08/2011 06:20)
Новый ключ 0x1B6A24550F33E44A загружен на сервер, отпечаток ключа: 8B697E907B3DE193E8E9B9FE1B6A24550F33E44A
Новый ключ подписан старым, старый ключ 0xC48251EB4F8E4E6E остается действительным на неопределенное время, но для связи со мной прошу использовать новый ключ и им-же будут подписываться следующие релизы DiskCryptor.
Активистов прошу подписать мой новый ключ.

— ntldr (11/08/2011 08:06)
Ключ на сайте изменен. Это сообщение подписано новым ключом.

— unknown (11/08/2011 09:33)
По цветам отпечатка кого-то напоминает, только в обратном порядке.

— SATtva (11/08/2011 11:19)
Действительно. :)

— Гость (23/09/2013 12:00)

> /comment47542^[link6]: Можно имеющимся у вас пока старым ключом заверения связки не просто подписать новый ключ (связку), а вынести его из связки главного нынешнего ключа и внести в новую связку в качестве подключа и уже там объявить отозванным.

Если у абонента был старый ключ на связке, а потом он сымпортирует новый ключ, созданный по данной методике, GnuPG не переклинит от коллизии keyid'ов (один и тот же keyid будет использоваться в качестве основного для одного ключа и в качестве подключа для другого ключа)?

> /comment47550^[link7]: Это для подписи данных, а для подписей сертификатов ключей надо "cert-digest-algo sha512".

Казалось бы, предпочтения (pref) в GnuPG таковы, чтобы для новых ключей по умолчанию использовались самые сильные шифры и хэши, или это не так? Сейчас вижу, что SHA256 приоритетней, чем SHA512 почему-то. Вот почему? В чём смысл? И, вообще, есть ли особый смысл в следовании этим^[link8] рекомендациям по изменению умолчаний? Кстати, в списке предпочтей выше приоритет у того хэша/шифра, что перечислен ранее? Например, шифр по умолчанию для всех новых ключей есть, как я вижу, AES256.

И ещё вопрос: есть ли какая-то связь между uid'ами собственного ключа и его подключами? Судя по интерфейсу, они создаются и управляются совершенно независимо: подключи сами по себе, uid'ы тоже сами по себе. Есть ли какой-то способ связать конкретный uid с конкретной парой подключей для подписи и шифрования? Есть подпись uid'ов, но по умолчанию все они подписаны основным ключом связки после создания, опции подписывать их конкретными подключами вроде как нет.

Сейчас игрался с ключом и получил что-то такое:

pub   1024R/3F736C62 2013-09-23 [expires: 2013-10-23]
uid                  test-key
sig 3    N   3F736C62 2013-09-23  test-key
uid                  subkey-0
sig 3        3F736C62 2013-09-23  test-key
sub   1024R/2311DC81 2013-09-23 [expires: 2014-09-23]
sig          3F736C62 2013-09-23  test-key
sub   1024R/721C8C79 2013-09-23 [expires: 2013-11-07]
sig          3F736C62 2013-09-23  test-key

Вопрос: что значит буква N в третьей строке? То, что это самоподпись?

И последний вопрос: можно ли создать ключ только для шифрования? Т.е., чтобы им (по крайней мере, при его штатном использовании в программах) нельзя было подписывать текст. Получается, что если есть подключ шифрования, используется он, а если нету, то главный ключ (а он всегда имеет опцию подписи). Задача неразрешима?

— sentaus (23/09/2013 12:54, исправлен 23/09/2013 13:01)

Сейчас вижу, что SHA256 приоритетней, чем SHA512 почему-то. Вот почему? В чём смысл?

В совместимости с PGP, который всего несколько лет назад только SHA256 умел.

И ещё вопрос: есть ли какая-то связь между uid'ами собственного ключа и его подключами?

В стандартной модели применения нету. Подключи просто заменяют основной ключ. С помощью экспертных настроек нагородить наверно можно много чего.

И последний вопрос: можно ли создать ключ только для шифрования?

Подпись ключей(C) и подпись данных(S) – это разные способы применения ключа, однако gnupg создаёт главный ключ с обоими флагами. Я сам не пробовал, но наверно можно попробовать подправить код gnupg, чтобы он ставил у главного ключа флаги C и E, но не S. Тогда, возможно, этим ключом нельзя будет подписывать текст. Возможность подписи ключей, разумеется, останется.

— SATtva (23/09/2013 12:59)

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

Что значит "самые сильные"? С наибольшим размером ключа / длиной выхода? Умолчания gpg с этим никак не связаны, конкретные алгоритмы просто захардкодены в программе.

Кстати, в списке предпочтей выше приоритет у того хэша/шифра, что перечислен ранее?

Слева направо от наболее приоритетных к менее приоритетным.

Есть ли какой-то способ связать конкретный uid с конкретной парой подключей для подписи и шифрования?

UID'ы — атрибут главного ключа, так же, как и подключи. Если Вы имеете в виду возможность создания ролей в рамках одного базового ключа (чтобы при проверке подписи было видно, какой UID её поставил), то стандарт такой возможности не предоставляет. Для разных ролей генерируйте отдельные базовые ключи.

Сейчас игрался с ключом и получил что-то такое: <...>
Вопрос: что значит буква N в третьей строке? То, что это самоподпись?

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

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

При генерации ключа в экспертном режиме (--expert --gen-key) можно выбрать требуемые capability, в том числе и для главного ключа.

— Гость (23/09/2013 13:57)

> Что значит "самые сильные"? С наибольшим размером ключа / длиной выхода?

Для шифров — например, AES256 вместо DES3; для хэшей — SHA512 вместо SHA1. Т.е. речь о ранжировании по криптостойкости (по качеству в данном классе, а не количеству).

> Если Вы имеете в виду возможность создания ролей в рамках одного базового ключа (чтобы при проверке подписи было видно, какой UID её поставил), то стандарт такой возможности не предоставляет.

Имелось в виду что-то типа: на каждом UID висит свой e-mail и свой подключ, причём абонент выбирает автоматически тот подключ для шифрования, который соответствует выбранному e-mail.

Что касается «проверки подписи» (то, о чём вы пишете), то это как раз работает: gpg -v --verify напишет, что подпись сделана таким-то подключом, и что основной ключ для связки такой-то. Проверял.

> Отвечающему предлагается угадать, что Вы там наиграли и как выводите этот список?

Это 2 подключа (один для шифрования, другой для подписи) повешенные на один сертифицирующий (главный) ключ. Выхлоп команды gpg --list-sigs, очевидно. Сейчас вспомнил, что на каком-то этапе игрался с notation, и, видимо, чего-то туда добавил в этом плане. man gpg:

"N" for a signature that contains a notation

> При генерации ключа в экспертном режиме ... можно выбрать требуемые capability, в том числе и для главного ключа.

Спасибо! Ровно то, что надо. Вроде работает правильно. В связи с этим возникает ещё один вопрос: зачем главный ключ имеет по умолчанию флаг S? Логично делать его только C, а для S и E добавлять подключи по желанию. Или здесь есть какие-то подводные камни, и так делать не стоит?

P.S. При работе под «экспертом» gpg веселит:

Is this correct? (y/N) y
Really create? (y/N) y

Да мамой клянусь! Зачем он 2-ой раз переспрашивает? Это реакция на addkey.

— Гость (23/09/2013 14:28)

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

Да, gpg ругается и не даёт подписать, при этом шифрует на ура, всё как надо.

— SATtva (23/09/2013 14:46, исправлен 23/09/2013 14:47)

Для шифров — например, AES256 вместо DES3; для хэшей — SHA512 вместо SHA1. Т.е. речь о ранжировании по криптостойкости (по качеству в данном классе, а не количеству).

Для разных пользователей критерии стойкости различны. Умолчания задаются разработчиками из несколько иных соображений, первое из которых: наилучшая совместимость в рамках некоторых best practices.

Имелось в виду что-то типа: на каждом UID висит свой e-mail и свой подключ, причём абонент выбирает автоматически тот подключ для шифрования, который соответствует выбранному e-mail.
Что касается «проверки подписи» (то, о чём вы пишете), то это как раз работает: gpg -v --verify напишет, что подпись сделана таким-то подключом, и что основной ключ для связки такой-то. Проверял.

Именно, что подключом, а не UID'ом.

Короче, подключи и UID'ы — ортогональные сущности.

В связи с этим возникает ещё один вопрос: зачем главный ключ имеет по умолчанию флаг S? Логично делать его только C, а для S и E добавлять подключи по желанию. Или здесь есть какие-то подводные камни, и так делать не стоит?

По умолчанию большинство реализаций создают главный ключ с шифровальным подключом, соответственно, главный ключ должен поддерживать подпись данных. Имейте в виду: не все реализации поддерживают генерацию подключей подписи, некоторые даже не распознаЮт подписи от подключей (хотя сегодня такие реализации уже в меньшинстве). Иными словами, флаги C, S для главного ключа — норма для обычных пользователей. Продвинутые могут менять в своё удовольствие.

P.S. При работе под «экспертом» gpg веселит

Из той же серии: не помню, LUKS или что-то другое при удалении ключа требует "write YES in all caps".

— Гость (23/09/2013 18:24)
Вообще, для уже созданных по умолчанию ключей update, наверно, можно сделать так: сгенерировать новые подключи для подписи и шифрования, а уже существующий подключ шифрования отозвать через revkey. Результат выложить на keyserver.

— Гость (23/09/2013 21:24)

> /comment47555^[link9]: В preferences ключа первым стоит SHA256, но почему-то при подписи используется sha1 если не прописать digest-algo sha256 в gpg.conf. Похоже что GnuPG игнорирует предпочтения для хэшей при подписи.

Та же проблема. Опции в gpg.conf пока статически не прописывал. Стоит ли?

Меня удивило, что когда посмотрел список предпочтений хэшей на старом ключе, там SHA256 и SHA512 вообще не числились. Значит ли это, что если бы кто-нибудь отправил мне сообщение с SHA256, я бы не смог его расшифровать или проверить подпись? Хоть сам ключ генерировался и давно, но версия GnuPG современная, поэтому ей всё равно, она расшифрует?

> /comment47574^[link10]: Подпись у первого UID почему-то продублировалась.

Та же ситуация. Есть предположительное объяснение: когда после генерации ключа меняются настройки через setpref, реально генерируется ещё одна подпись, заверяющая такое изменение предпочтений. В моём случае из двух этих подписей чётко видно, что одна старая (создана во время генерации ключа по умолчанию), а другая появилась только после операций с подключами. Впрочем, я смог получить вторую подпись только после того, как загрузил обратно свой же обновлённый ключ с сервера ключей.

— sentaus (23/09/2013 21:31)

но версия GnuPG современная, поэтому ей всё равно, она расшифрует?

Да. Предпочтения вообще говоря предназначен используются другой стороной, которая посылает вам сообщения. Они позволяют составить сообщение таким образом, чтобы ВАШ gnupg/pgp смог его расшифровать и проверить подпись.

сть предположительное объяснение: когда после генерации ключа меняются настройки через setpref, реально генерируется ещё одна подпись, заверяющая такое изменение предпочтений.

Так и есть, предпочтения должны быть заверены подписью.

— Гость (23/09/2013 22:44)

> Предпочтения вообще говоря предназначен используются другой стороной, которая посылает вам сообщения. Они позволяют составить сообщение таким образом, чтобы ВАШ gnupg/pgp смог его расшифровать и проверить подпись.

Тогда, казалось бы, для этого достаточно указать версию GnuPG/PGP, а списки предпочтений — излишество.

— sentaus (24/09/2013 00:41)
Это только кажется :-)

— unknown (24/09/2013 10:35)

когда после генерации ключа меняются настройки через setpref, реально генерируется ещё одна подпись, заверяющая такое изменение предпочтений.

Так и есть, предпочтения должны быть заверены подписью.

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

— SATtva (24/09/2013 12:35)

Тогда, казалось бы, для этого достаточно указать версию GnuPG/PGP, а списки предпочтений — излишество.

Это только кажется :-)

Да уж. Разработчикам всех реализаций OpenPGP пришлось бы поддерживать внутренние таблицы совместимостей со всеми прочими реализациями. Предпочтения как раз — самый гибкий и универсальный способ обеспечить долгосрочную совместимость.

— Гость (25/09/2013 00:12)

> Разработчикам всех реализаций OpenPGP

Всех ~~полутора~~ релизаций, про bouncy castle и NetPGP если не вспоминать? GnuPG — де факто стандарт, который реализован подо все платформы. Коммерческое PGP ненужно. Пусть они клепают дисковое шифрование, но я бы предпочёл установить GnuPG и пользоваться ею, даже если бы у меня была винда и коммерческая PGP.

— sentaus (25/09/2013 00:21)
Праведный гнев лучше выражать непосредственно разработчикам стандарта OpenPGP. ~~Может, и они поржут.~~ Продуктивнее будет.

— Гость (25/09/2013 01:22)

> Праведный гнев лучше выражать непосредственно разработчикам стандарта OpenPGP.

OpenPGP — это мы^[link11], вот и выражаю. :-)

Ссылки

^[link1] https://www.pgpru.com/biblioteka/rukovodstva/upravleniekljuchami/podkljuchiopenpgp

^[link2] https://www.pgpru.com/comment4784

^[link3] http://www.debian-administration.org/users/dkg/weblog/48

^[link4] http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/024999.html

^[link5] http://www.apache.org/dev/openpgp.html#sha1

^[link6] https://www.pgpru.com/comment47542

^[link7] https://www.pgpru.com/comment47550

^[link8] https://www.pgpru.com/comment47568

^[link9] https://www.pgpru.com/comment47555

^[link10] https://www.pgpru.com/comment47574

^[link11] https://www.pgpru.com/proekt

openPGP в России

Я меняю свой PGP ключ