id: Гость   вход   регистрация
текущее время 06:49 13/12/2019
Автор темы: ntldr, тема открыта 09/08/2011 04:56 Печать
Категории: криптография, управление ключами
создать
просмотр
ссылки

Я меняю свой 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:


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



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


gpg --edit-key [keyname]



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

— 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



В ключе по одной подписи на каждый UID и subkey. Теперь делаю export-secret-subkeys и импортирую subkeys.gpg и pubkey.gpg в рабочую среду. Делаю gpg --list-sigs 0x3DC2A42E



Подпись у первого UID почему-то продублировалась. Дублирование происходит независимо от того, в каком порядке я импортирую открытые ключи и секретные подключи. Если импортировать только подключи, то теряется настройка primari UID.
Дамп ключа после импорта:


— unknown (10/08/2011 15:01)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
gpg --list-secret-keys что показывает после экспорта-импорта?
— ntldr (10/08/2011 15:06)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
— 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)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
Действительно. :)
— Гость (23/09/2013 12:00)   <#>

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


Казалось бы, предпочтения (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)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
Казалось бы, предпочтения (pref) в GnuPG таковы, чтобы для новых ключей по умолчанию использовались самые сильные шифры и хэши, или это не так?

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

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

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

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

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

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

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

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

При генерации ключа в экспертном режиме (--expert --gen-key) можно выбрать требуемые capability, в том числе и для главного ключа.
— Гость (23/09/2013 13:57)   <#>

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


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

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


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

"N" for a signature that contains a notation


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

P.S. При работе под «экспертом» gpg веселит:
Is this correct? (y/N) y
Really create? (y/N) y
Да мамой клянусь! Зачем он 2-ой раз переспрашивает? Это реакция на addkey.
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3