Я меняю свой PGP ключ
Я создал свой ключ 0xC48251EB4F8E4E6E в 2007 году, когда начал писать проект DiskCryptor, ключ создавался с настройками по-умолчанию, без прицела на долговременную безопасность, поэтому он использует DSA-1024 и sha1. SHA1 уже взломан и вот-вот следует ожидать практических коллизий, в достаточности DSA-1024 на ближайшие 10 лет тоже есть сомнения. В связи с вышесказанным, а также из других соображений, созрела мысль заменить ключ в ближайшее время, чем раньше это сделать – тем безболезненнее будет процесс.
Новый ключ я собираюсь сгенерировать по-уму и хранить с соблюдением повышенных мер безопасности, чтобы в идеале больше не понадобилось его менять никогда. А чтобы сделать всё идеально я хочу проконсультироваться со знатоками GnuPG насчет наилучших настроек и желательного комплекса мер при создании, хранении и использовании ключа.
Специально для параноиков: этот пост я пишу в трезвом уме и твердой памяти, не находясь под принуждением.
комментариев: 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]
Не забыть отправить на сервер обновлённую версию ключа.
комментариев: 371 документов: 19 редакций: 20
Возник вопрос: зачем нужен UID без почтового адреса? Если он примари, то ключ некрасиво отображается в WinPT. Если адрес изменился, всегда можно создать новый UID.
комментариев: 9796 документов: 488 редакций: 5664
Кроме того, инструкция задумана с тем, чтобы на разных машинах пользователь имел возможность применять разные подписи (и разные UID'ы) соответственно. Для этого перед экспортированием проще удалять лишние UID'ы и подключи со связки, а не трогать primary UID.
комментариев: 371 документов: 19 редакций: 20
Еще вылезла одна странная проблема. Генерирую новый ключ как в инструкции, делаю gpg --list-sigs 0x3DC2A42E
В ключе по одной подписи на каждый UID и subkey. Теперь делаю export-secret-subkeys и импортирую subkeys.gpg и pubkey.gpg в рабочую среду. Делаю gpg --list-sigs 0x3DC2A42E
Подпись у первого UID почему-то продублировалась. Дублирование происходит независимо от того, в каком порядке я импортирую открытые ключи и секретные подключи. Если импортировать только подключи, то теряется настройка primari UID.
Дамп ключа после импорта:
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 371 документов: 19 редакций: 20
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 371 документов: 19 редакций: 20
Новый ключ подписан старым, старый ключ 0xC48251EB4F8E4E6E остается действительным на неопределенное время, но для связи со мной прошу использовать новый ключ и им-же будут подписываться следующие релизы DiskCryptor.
Активистов прошу подписать мой новый ключ.
комментариев: 371 документов: 19 редакций: 20
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 11558 документов: 1036 редакций: 4118
Если у абонента был старый ключ на связке, а потом он сымпортирует новый ключ, созданный по данной методике, GnuPG не переклинит от коллизии keyid'ов (один и тот же keyid будет использоваться в качестве основного для одного ключа и в качестве подключа для другого ключа)?
Казалось бы, предпочтения (pref) в GnuPG таковы, чтобы для новых ключей по умолчанию использовались самые сильные шифры и хэши, или это не так? Сейчас вижу, что SHA256 приоритетней, чем SHA512 почему-то. Вот почему? В чём смысл? И, вообще, есть ли особый смысл в следовании этим рекомендациям по изменению умолчаний? Кстати, в списке предпочтей выше приоритет у того хэша/шифра, что перечислен ранее? Например, шифр по умолчанию для всех новых ключей есть, как я вижу, AES256.
И ещё вопрос: есть ли какая-то связь между uid'ами собственного ключа и его подключами? Судя по интерфейсу, они создаются и управляются совершенно независимо: подключи сами по себе, uid'ы тоже сами по себе. Есть ли какой-то способ связать конкретный uid с конкретной парой подключей для подписи и шифрования? Есть подпись uid'ов, но по умолчанию все они подписаны основным ключом связки после создания, опции подписывать их конкретными подключами вроде как нет.
Сейчас игрался с ключом и получил что-то такое:
И последний вопрос: можно ли создать ключ только для шифрования? Т.е., чтобы им (по крайней мере, при его штатном использовании в программах) нельзя было подписывать текст. Получается, что если есть подключ шифрования, используется он, а если нету, то главный ключ (а он всегда имеет опцию подписи). Задача неразрешима?
комментариев: 1060 документов: 16 редакций: 32
В совместимости с PGP, который всего несколько лет назад только SHA256 умел.
В стандартной модели применения нету. Подключи просто заменяют основной ключ. С помощью экспертных настроек нагородить наверно можно много чего.
Подпись ключей(C) и подпись данных(S) – это разные способы применения ключа, однако gnupg создаёт главный ключ с обоими флагами. Я сам не пробовал, но наверно можно попробовать подправить код gnupg, чтобы он ставил у главного ключа флаги C и E, но не S. Тогда, возможно, этим ключом нельзя будет подписывать текст. Возможность подписи ключей, разумеется, останется.
комментариев: 11558 документов: 1036 редакций: 4118
Что значит "самые сильные"? С наибольшим размером ключа / длиной выхода? Умолчания gpg с этим никак не связаны, конкретные алгоритмы просто захардкодены в программе.
Слева направо от наболее приоритетных к менее приоритетным.
UID'ы — атрибут главного ключа, так же, как и подключи. Если Вы имеете в виду возможность создания ролей в рамках одного базового ключа (чтобы при проверке подписи было видно, какой UID её поставил), то стандарт такой возможности не предоставляет. Для разных ролей генерируйте отдельные базовые ключи.
Отвечающему предлагается угадать, что Вы там наиграли и как выводите этот список? Опишите порядок своих действий хотя бы.
При генерации ключа в экспертном режиме (--expert --gen-key) можно выбрать требуемые capability, в том числе и для главного ключа.
Для шифров — например, AES256 вместо DES3; для хэшей — SHA512 вместо SHA1. Т.е. речь о ранжировании по криптостойкости (по качеству в данном классе, а не количеству).
Имелось в виду что-то типа: на каждом UID висит свой e-mail и свой подключ, причём абонент выбирает автоматически тот подключ для шифрования, который соответствует выбранному e-mail.
Что касается «проверки подписи» (то, о чём вы пишете), то это как раз работает: gpg -v --verify напишет, что подпись сделана таким-то подключом, и что основной ключ для связки такой-то. Проверял.
Это 2 подключа (один для шифрования, другой для подписи) повешенные на один сертифицирующий (главный) ключ. Выхлоп команды gpg --list-sigs, очевидно. Сейчас вспомнил, что на каком-то этапе игрался с notation, и, видимо, чего-то туда добавил в этом плане. man gpg:
Спасибо! Ровно то, что надо. Вроде работает правильно. В связи с этим возникает ещё один вопрос: зачем главный ключ имеет по умолчанию флаг S? Логично делать его только C, а для S и E добавлять подключи по желанию. Или здесь есть какие-то подводные камни, и так делать не стоит?
P.S. При работе под «экспертом» gpg веселит: