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

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


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


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


 
На страницу: 1, 2, 3 След.
Комментарии
— Гость (23/09/2013 14:28)   <#>

Да, gpg ругается и не даёт подписать, при этом шифрует на ура, всё как надо.
— SATtva (23/09/2013 14:46, исправлен 23/09/2013 14:47)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Для шифров — например, 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)   <#>

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

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


Та же ситуация. Есть предположительное объяснение: когда после генерации ключа меняются настройки через setpref, реально генерируется ещё одна подпись, заверяющая такое изменение предпочтений. В моём случае из двух этих подписей чётко видно, что одна старая (создана во время генерации ключа по умолчанию), а другая появилась только после операций с подключами. Впрочем, я смог получить вторую подпись только после того, как загрузил обратно свой же обновлённый ключ с сервера ключей.
— sentaus (23/09/2013 21:31)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
но версия GnuPG современная, поэтому ей всё равно, она расшифрует?

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

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

Так и есть, предпочтения должны быть заверены подписью.
— Гость (23/09/2013 22:44)   <#>

Тогда, казалось бы, для этого достаточно указать версию GnuPG/PGP, а списки предпочтений — излишество.
— sentaus (24/09/2013 00:41)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Это только кажется :-)
— unknown (24/09/2013 10:35)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
когда после генерации ключа меняются настройки через setpref, реально генерируется ещё одна подпись, заверяющая такое изменение предпочтений.
Так и есть, предпочтения должны быть заверены подписью.

Любое изменение в подключах должно сопровождаться переподписыванием всей этой связки главным ключом, иначе будет выглядеть, что ключ повреждён или его пытался отредактировать кто-то посторонний, кто не владеет секретной частью сертифицирующего главного ключа, которым заверена вся связка.
— SATtva (24/09/2013 12:35)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Тогда, казалось бы, для этого достаточно указать версию GnuPG/PGP, а списки предпочтений — излишество.

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

Да уж. Разработчикам всех реализаций OpenPGP пришлось бы поддерживать внутренние таблицы совместимостей со всеми прочими реализациями. Предпочтения как раз — самый гибкий и универсальный способ обеспечить долгосрочную совместимость.
— Гость (25/09/2013 00:12)   <#>

Всех полутора релизаций, про bouncy castle и NetPGP если не вспоминать? GnuPG — де факто стандарт, который реализован подо все платформы. Коммерческое PGP ненужно. Пусть они клепают дисковое шифрование, но я бы предпочёл установить GnuPG и пользоваться ею, даже если бы у меня была винда и коммерческая PGP.
— sentaus (25/09/2013 00:21)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Праведный гнев лучше выражать непосредственно разработчикам стандарта OpenPGP. Может, и они поржут. Продуктивнее будет.
— Гость (25/09/2013 01:22)   <#>

OpenPGP — это мы, вот и выражаю. :-)
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3