Я меняю свой PGP ключ
Я создал свой ключ 0xC48251EB4F8E4E6E в 2007 году, когда начал писать проект DiskCryptor, ключ создавался с настройками по-умолчанию, без прицела на долговременную безопасность, поэтому он использует DSA-1024 и sha1. SHA1 уже взломан и вот-вот следует ожидать практических коллизий, в достаточности DSA-1024 на ближайшие 10 лет тоже есть сомнения. В связи с вышесказанным, а также из других соображений, созрела мысль заменить ключ в ближайшее время, чем раньше это сделать – тем безболезненнее будет процесс.
Новый ключ я собираюсь сгенерировать по-уму и хранить с соблюдением повышенных мер безопасности, чтобы в идеале больше не понадобилось его менять никогда. А чтобы сделать всё идеально я хочу проконсультироваться со знатоками GnuPG насчет наилучших настроек и желательного комплекса мер при создании, хранении и использовании ключа.
Специально для параноиков: этот пост я пишу в трезвом уме и твердой памяти, не находясь под принуждением.
Ссылки
[link1] http://www.pgpru.com/biblioteka/rukovodstva/upravleniekljuchami/podkljuchiopenpgp
[link2] http://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] http://www.pgpru.com/comment47542
[link7] http://www.pgpru.com/comment47550
[link8] http://www.pgpru.com/comment47568
[link9] http://www.pgpru.com/comment47555
[link10] http://www.pgpru.com/comment47574
[link11] http://www.pgpru.com/proekt
Кое что[link1] по этой теме есть. Хотя можно ещё обсудить и дополнить для совсем параноидально-гиковских вариантов.
Например, связку ключей можно разобрать на отдельные подключи и UID'ы с подписями, назначить им разные пароли и из этого собрать связку обратно. Можно имеющимся у вас пока старым ключом заверения связки не просто подписать новый ключ (связку), а вынести его из связки главного нынешнего ключа и внести в новую связку в качестве подключа и уже там объявить отозванным.
Это всё требует включения нестандартных опций GnuPG, работы под разными пользователями и правки в HEX-редакторе. Имеется шанс остаться без ключа (если не сбэкапить), но если всё протестить и проверить в узком кругу, то скорее всего такой нестандартный ключ будет успешно работать. Правда, мало кто сможет оценить такое утончённое использование GnuPG :-) Скорее ради хохмы только.
Ну, мы-то точно поставим высший балл за артистизм и за технику.
Другие возможные участники публичных выступлений с ключами смогут рассчитывать на приз зрительских симпатий.
Генерирую ключ следуя указаниям из статьи и делаю дамп его пакетов. Получается что-то вроде этого:
version 4, algo 1 – по спецификации асимметрик с номером 1 это RSA (Encrypt or Sign) [HAC], хотя я создавал sign-only ключ.
digest algo 2 – это SHA-1 [FIPS180], хотя у меня в gpg.conf прописан digest-algo sha512
Как полностью избавиться от sha1 и не грозит ли это серьезными проблемами с совместимостью?
Избавиться от SHA-1 прям полностью, увы, невозможно — кое-где он захардкоден в стандарт. Например, отпечаток ключа всегда вычисляется по SHA-1.
Использование sha1 для подписи блоков ключа тоже захардкодено, или это настраивается?
Это для подписи данных, а для подписей сертификатов ключей надо "cert-digest-algo sha512".
Более того, использование этой опции как раз-таки повлечёт проблемы несовместимости — она принудительно задаёт алгоритм хэширование данных, игнорируя предпочтения в ключе получателя.
Может грозить совместимостью со старыми версиями, но в случае с gpg это не очень актуально. Другой вопрос – PGP, там сейчас вроде sha256 применяется. Так что надо бы проверить, умеет ли она sha512 хотя бы проверять, а то вдруг ее пользователи не смогут понимать эти подписи.
Я точно знаю, что с sha512 полностью несовместимы версии 8.x, при этом 8.1 умеет проверять подписи с sha256, но не генерировать их. Более поздними не пользовался.
При работе с подключами можно сделать вот что [поправьте, где не прав]. Имея один главный подключ для подписи, подписывать им дополнительные подключи для шифрования. С точки зрения конечного пользователя это будет как бы один PGP-ключ, который иногда нужно "продлевать" скопировав себе его копию с keyserver'а. С другой стороны, при замене подключа шифрования на другой, вся информация, зашифрованная предыдущим подключом уже невскрываема, если владелец PGP-ключа удалил у себя все его старые копии (и старые подключи со связки). Это может быть использовано для защиты от силового принуждения к выдаче ключа (PFS или как оно там). Т.е. вместо создания главного PGP-ключа для подписи других "временных" PGP-ключей, можно всё то же делать в рамках подключей одного и того же PGP-ключа.
Именно это и описано в инструкции[link1], более подробно эту мысль раскрывали здесь[link2].
Создал новый ключ, вот его дамп:
Всё ли правильно?
В preferences ключа первым стоит SHA256, но почему-то при подписи используется sha1 если не прописать digest-algo sha256 в gpg.conf.
Похоже что GnuPG игнорирует предпочтения для хэшей при подписи.
Спасибо за ссылку. Увы, в 2005ом году ещё не читал этот форум :(
2 ntldr:
Попробуйте установить утилиту pgpdump и прикладывать дамп сразу в двух форматах.
Как сейчас:
И в таком виде:
Может что-то вылезет, сходу незаметное глазу.
Последний вариант ключа:
gpg --export [keyname] | gpg --list-packets
gpg --export [keyname] | pgpdump
Выглядит нормально. Базовый ключ для связки, два уида, один подключ только для шифрования, второй подключ только для подписи (и он 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:
или для большей совместимости:
Отредактировать предпочтения в ранее сгенерированных ключах (если они были созданы до изменения gpg.conf) для того, чтобы уведомить отправителя об использовании своих предпочтений к более сильным алгоритмам.
gpg --edit-key [keyname]
Не забыть отправить на сервер обновлённую версию ключа.
Возник вопрос: зачем нужен UID без почтового адреса? Если он примари, то ключ некрасиво отображается в WinPT. Если адрес изменился, всегда можно создать новый UID.
Удалить старый UID и после этого добавить новый можно. Только удалить на серверах открытых ключей это нельзя. Можно только отзывать UID, также как и открытый подключ.
Кроме того, инструкция задумана с тем, чтобы на разных машинах пользователь имел возможность применять разные подписи (и разные UID'ы) соответственно. Для этого перед экспортированием проще удалять лишние UID'ы и подключи со связки, а не трогать primary UID.
Еще вылезла одна странная проблема. Генерирую новый ключ как в инструкции, делаю gpg --list-sigs 0x3DC2A42E
В ключе по одной подписи на каждый UID и subkey. Теперь делаю export-secret-subkeys и импортирую subkeys.gpg и pubkey.gpg в рабочую среду. Делаю gpg --list-sigs 0x3DC2A42E
Подпись у первого UID почему-то продублировалась. Дублирование происходит независимо от того, в каком порядке я импортирую открытые ключи и секретные подключи. Если импортировать только подключи, то теряется настройка primari UID.
Дамп ключа после импорта:
gpg --list-secret-keys что показывает после экспорта-импорта?
Тогда непонятно.
Новый ключ 0x1B6A24550F33E44A загружен на сервер, отпечаток ключа: 8B697E907B3DE193E8E9B9FE1B6A24550F33E44A
Новый ключ подписан старым, старый ключ 0xC48251EB4F8E4E6E остается действительным на неопределенное время, но для связи со мной прошу использовать новый ключ и им-же будут подписываться следующие релизы DiskCryptor.
Активистов прошу подписать мой новый ключ.
Ключ на сайте изменен. Это сообщение подписано новым ключом.
По цветам отпечатка кого-то напоминает, только в обратном порядке.
Действительно. :)
Если у абонента был старый ключ на связке, а потом он сымпортирует новый ключ, созданный по данной методике, GnuPG не переклинит от коллизии keyid'ов (один и тот же keyid будет использоваться в качестве основного для одного ключа и в качестве подключа для другого ключа)?
Казалось бы, предпочтения (pref) в GnuPG таковы, чтобы для новых ключей по умолчанию использовались самые сильные шифры и хэши, или это не так? Сейчас вижу, что SHA256 приоритетней, чем SHA512 почему-то. Вот почему? В чём смысл? И, вообще, есть ли особый смысл в следовании этим[link8] рекомендациям по изменению умолчаний? Кстати, в списке предпочтей выше приоритет у того хэша/шифра, что перечислен ранее? Например, шифр по умолчанию для всех новых ключей есть, как я вижу, AES256.
И ещё вопрос: есть ли какая-то связь между uid'ами собственного ключа и его подключами? Судя по интерфейсу, они создаются и управляются совершенно независимо: подключи сами по себе, uid'ы тоже сами по себе. Есть ли какой-то способ связать конкретный uid с конкретной парой подключей для подписи и шифрования? Есть подпись uid'ов, но по умолчанию все они подписаны основным ключом связки после создания, опции подписывать их конкретными подключами вроде как нет.
Сейчас игрался с ключом и получил что-то такое:
И последний вопрос: можно ли создать ключ только для шифрования? Т.е., чтобы им (по крайней мере, при его штатном использовании в программах) нельзя было подписывать текст. Получается, что если есть подключ шифрования, используется он, а если нету, то главный ключ (а он всегда имеет опцию подписи). Задача неразрешима?
В совместимости с PGP, который всего несколько лет назад только SHA256 умел.
В стандартной модели применения нету. Подключи просто заменяют основной ключ. С помощью экспертных настроек нагородить наверно можно много чего.
Подпись ключей(C) и подпись данных(S) – это разные способы применения ключа, однако gnupg создаёт главный ключ с обоими флагами. Я сам не пробовал, но наверно можно попробовать подправить код gnupg, чтобы он ставил у главного ключа флаги C и E, но не S. Тогда, возможно, этим ключом нельзя будет подписывать текст. Возможность подписи ключей, разумеется, останется.
Что значит "самые сильные"? С наибольшим размером ключа / длиной выхода? Умолчания 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 веселит:
Да, gpg ругается и не даёт подписать, при этом шифрует на ура, всё как надо.
Для разных пользователей критерии стойкости различны. Умолчания задаются разработчиками из несколько иных соображений, первое из которых: наилучшая совместимость в рамках некоторых best practices.
Именно, что подключом, а не UID'ом.
Короче, подключи и UID'ы — ортогональные сущности.
По умолчанию большинство реализаций создают главный ключ с шифровальным подключом, соответственно, главный ключ должен поддерживать подпись данных. Имейте в виду: не все реализации поддерживают генерацию подключей подписи, некоторые даже не распознаЮт подписи от подключей (хотя сегодня такие реализации уже в меньшинстве). Иными словами, флаги C, S для главного ключа — норма для обычных пользователей. Продвинутые могут менять в своё удовольствие.
Из той же серии: не помню, LUKS или что-то другое при удалении ключа требует "write YES in all caps".
Вообще, для уже созданных по умолчанию ключей update, наверно, можно сделать так: сгенерировать новые подключи для подписи и шифрования, а уже существующий подключ шифрования отозвать через revkey. Результат выложить на keyserver.
Та же проблема. Опции в gpg.conf пока статически не прописывал. Стоит ли?
Меня удивило, что когда посмотрел список предпочтений хэшей на старом ключе, там SHA256 и SHA512 вообще не числились. Значит ли это, что если бы кто-нибудь отправил мне сообщение с SHA256, я бы не смог его расшифровать или проверить подпись? Хоть сам ключ генерировался и давно, но версия GnuPG современная, поэтому ей всё равно, она расшифрует?
Та же ситуация. Есть предположительное объяснение: когда после генерации ключа меняются настройки через setpref, реально генерируется ещё одна подпись, заверяющая такое изменение предпочтений. В моём случае из двух этих подписей чётко видно, что одна старая (создана во время генерации ключа по умолчанию), а другая появилась только после операций с подключами. Впрочем, я смог получить вторую подпись только после того, как загрузил обратно свой же обновлённый ключ с сервера ключей.
Да. Предпочтения вообще говоря предназначен используются другой стороной, которая посылает вам сообщения. Они позволяют составить сообщение таким образом, чтобы ВАШ gnupg/pgp смог его расшифровать и проверить подпись.
Так и есть, предпочтения должны быть заверены подписью.
Тогда, казалось бы, для этого достаточно указать версию GnuPG/PGP, а списки предпочтений — излишество.
Это только кажется :-)
Любое изменение в подключах должно сопровождаться переподписыванием всей этой связки главным ключом, иначе будет выглядеть, что ключ повреждён или его пытался отредактировать кто-то посторонний, кто не владеет секретной частью сертифицирующего главного ключа, которым заверена вся связка.
Да уж. Разработчикам всех реализаций OpenPGP пришлось бы поддерживать внутренние таблицы совместимостей со всеми прочими реализациями. Предпочтения как раз — самый гибкий и универсальный способ обеспечить долгосрочную совместимость.
Всех
полуторарелизаций, про bouncy castle и NetPGP если не вспоминать? GnuPG — де факто стандарт, который реализован подо все платформы. Коммерческое PGP ненужно. Пусть они клепают дисковое шифрование, но я бы предпочёл установить GnuPG и пользоваться ею, даже если бы у меня была винда и коммерческая PGP.Праведный гнев лучше выражать непосредственно разработчикам стандарта OpenPGP.
Может, и они поржут.Продуктивнее будет.OpenPGP — это мы[link11], вот и выражаю. :-)