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

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

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

На страницу: 1, 2, 3 След.

Комментарии

—	unknown (10/08/2011 10:44, исправлен 10/08/2011 11:37) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Выглядит нормально. Базовый ключ для связки, два уида, один подключ только для шифрования, второй подключ только для подписи (и он 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 активно обсуждали в дебиановском блоге, там есть наглядные примеры (см. также коментарии) и в рассылке gnupg, но похоже так ни до чего и не договорились. Хотя рекомендации Апача сходятся с дебиановским решением. Вполне можно ориентироваться на эти способы ухода с 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) профиль/связь <#> комментариев: 371 документов: 19 редакций: 20

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

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

—	unknown (10/08/2011 14:35) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

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

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

—	ntldr (10/08/2011 14:41, исправлен 10/08/2011 14:43) профиль/связь <#> комментариев: 371 документов: 19 редакций: 20

Еще вылезла одна странная проблема. Генерирую новый ключ как в инструкции, делаю 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) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

gpg --list-secret-keys что показывает после экспорта-импорта?

—	ntldr (10/08/2011 15:06) профиль/связь <#> комментариев: 371 документов: 19 редакций: 20

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) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Тогда непонятно.

—	ntldr (11/08/2011 06:20) профиль/связь <#> комментариев: 371 документов: 19 редакций: 20

Новый ключ 0x1B6A24550F33E44A загружен на сервер, отпечаток ключа: 8B697E907B3DE193E8E9B9FE1B6A24550F33E44A
Новый ключ подписан старым, старый ключ 0xC48251EB4F8E4E6E остается действительным на неопределенное время, но для связи со мной прошу использовать новый ключ и им-же будут подписываться следующие релизы DiskCryptor.
Активистов прошу подписать мой новый ключ.

—	ntldr (11/08/2011 08:06) профиль/связь <#> комментариев: 371 документов: 19 редакций: 20

Ключ на сайте изменен. Это сообщение подписано новым ключом.

—	unknown (11/08/2011 09:33) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

По цветам отпечатка кого-то напоминает, только в обратном порядке.

—	SATtva (11/08/2011 11:19) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Действительно. :)

—	*Гость* (23/09/2013 12:00) <#>

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

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

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

Казалось бы, предпочтения (pref) в GnuPG таковы, чтобы для новых ключей по умолчанию использовались самые сильные шифры и хэши, или это не так? Сейчас вижу, что SHA256 приоритетней, чем SHA512 почему-то. Вот почему? В чём смысл? И, вообще, есть ли особый смысл в следовании этим рекомендациям по изменению умолчаний? Кстати, в списке предпочтей выше приоритет у того хэша/шифра, что перечислен ранее? Например, шифр по умолчанию для всех новых ключей есть, как я вижу, 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) профиль/связь <#> комментариев: 1060 документов: 16 редакций: 32

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

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

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

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

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

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

—	SATtva (23/09/2013 12:59) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Казалось бы, предпочтения (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.

На страницу: 1, 2, 3 След.

Ваша оценка документа [показать результаты]