Типы ключей
Здравствуйте!
Из консоли GnuPG:
Home: D:/Program Files/GnuPG
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512
Compression: Uncompressed, ZIP, ZLIB, BZIP2
Подскажите, что означает третья строка, я имею в виду разновидности RSA с символами E и S, и чем они отличаются от RSA без «расширения»?
комментариев: 11558 документов: 1036 редакций: 4118
RSA-E — ключ RSA только для шифрования.
RSA-S — ключ RSA только для подписи.
Первый соответствует формату ключей v3, где один асимметричный ключ применялся для обеих операций. В формате v4 мы находим два или более асимметричных ключа, где один — базовый — используется только для подписи (RSA-S), а остальные — подключи (RSA-E) — для шифрования.
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 11558 документов: 1036 редакций: 4118
В ранних версиях PGP (до 5.0), где применялся формат ключей v3, каждый закрытый ключ был предназначен как для подписания (т.е. генерации цифровых подписей на документах и на сертификатах ключей), так и для расшифрования данных. Такая практика менее безопасна по той причине, что взлом одного закрытого ключа позволит и подделывать подписи пользователя, и расшифровывать все зашифрованные этим ключом файлы и переписку.
Для улучшения ситуации был предложен новый формат ключей v4, представляющих собой как бы связку из нескольких ключевых пар, где одна — базовая, применяется только для подписей, а остальные, названные подключами (subkeys), — только для зашифрования / расшифрования данных. При этом подключи можно свободно заменять, аннулировать и удалять, не жертвуя базовым ключом и собранными на нём сертифицирующими подписями.
Поэтому в контексте ключей формата v4 (это ключи DH/DSS и новые RSA) ответ на Ваш вопрос будет — не одно и то же. Но раньше было иначе.
Разделив ключи, вы передаете ваш ключ шифрования, отзывайте его и генерируете новый, но при этом не теряете подписи на вашем основном ключе, так что не надо зарабатывать доверие к ключу, как с самого начала. Таким образом, правоохранительные органы или суд получают доступ к вашим прошлым секретам, но не могут в будущем читать вашу конфиденциальную переписку, и вам не надо заново со всеми встречаться.
Так поступать очень целесообразно, но совсем не обязательно. Общий ключь RSA может быть использован и в новом формате v4, правда смысла в этом мало. Формат v4 более безопасен по ряду причин, и возможность разделения ключа — лишь одна из них.
К слову, можно еще использовать под-ключ для подписи документов. В этом случае подпись ключей (своих и чужих, сертификация и отзыв) производится основным ключем, а документы подписываются под-ключем. Таким образом появляется возможность не держать основной секретный ключ на подключенном к сети компьютеру вообще никогда, что сильно повышает безопасность, при том, что опять же, сохраняет ваши сертификати при смене ключа для подписи документов, которым вы регулярно пользуетесь.
Я этого, к сожалению, пять лет назад не знал, так что придется опять всех умолять подписать мой новый ключ до истечения срока и отзыва старого (обновлять его не собераюсь по разным причинам). Но такое происходит в последний раз.
Следующий мой основной ключ будет 4096-битовым RSA-S ключем, который я сертифицирую на неопределенный срок, но пользоваться им для подписи документов не буду (подпись таким ключем — монстр). Для этой цели будет несколько, регулярно меняемых ключей от 1024 до 2048 битов, с разными алгоритмами. А для шифрования однин ElGamal ключ в 2048 битов, тоже регулярно меняемый (каждые 5 лет, скажем).
Иметь несколько ключей шифрования одновременно не стоит, так как не вы выберайте, каким из них ваши корреспонденты будут пользоваться, а рассчитывать на то, что они будут этот выбор делать рационально — не стоит; это все реализации делают автоматически, просто выберая самый новый ключ. А тогда зачем все остальные?
Походные ключи, развертываемые из паролей вставлять в свой основной блок я скорее всего не буду. Это будет отдельный ключ, сертифицированный (в том числе и для отзыва) первым. Но над этим еще надо как-следует подумать. Походный ключь из пароля — штука новая, и нет ни опыта его использования ни консенсусных рекомендаций по их безопасному использованию. Для обсуждения практик, рисков и опыта связанних с такими ключами я уже открыл соответствующаю тему "PGP на ходу".
комментариев: 11558 документов: 1036 редакций: 4118
Ну, вообще к этим странам относятся все страны. :) Не рассматривая нюансы в законодательной базе и судебной практике, в любой стране суд или органы следствия могут обязать Вас раскрыть свой ключ шифрования. Санкции за нарушение, конечно, везде различны.
Возможно, но, на мой взгляд, не совсем верно — оппонент получает возможность скомпрометировать всю информацию, зашифрованную этим подключом. В ситуации правового принуждения (именно правового; при физическом такой номер не пройдёт) разумнее прибегнуть к GnuPG и его функции расшифрования сеансового ключа. Мы предоставляем органам сеансовые шифровальные ключи к интересующим их письмам/файлам, при этом не раскрывая прочую информацию.
Только в GnuPG, если не ошибаюсь? Указывая при подписании данных ID конкретного подключа?
Это интересная мысль. Планирую к концу 2006 заменить свой ключ (учитывая "последние события в криптоанализе хэш-функций") и как раз думаю над стратегией формата и размеров.
комментариев: 1060 документов: 16 редакций: 32
Хотелось бы поскорее получить v5, но пока не судьба. :(
А как это сделать-то? Как убрать мастер-ключ, оставив только подключи?
Кстати, в CKT версиях PGP была весьма полезная возможность – можно было назначить разные парольные фразы для подписи и шифрования. Было бы неплохо получить это же, но в расширенном виде: по фразе для расшифрования, подписи документов/файлов... и подписи ключей.
Согласен, но всякое бывает.
PGP я уже очень давно не видел в лицо, но в GnuPG это происходит так: для подписи документов всегда используется самый новый под-ключ, пригодный для подписи, или в отсутсвии такого — основной ключ.
Стойкость к коллизиям хеш-функций интересна только в нотариальных приложениях ЭЦП. Если подписывать только свои сообщения, то стойкость к коллизиям не играет роли. Даже в случае подписи PGP-ключей, коллизии неважны, так как "подсунуть" вам один ключ, чтобы завладеть подписью на другом может только человек генерировавший оба ключа, так что злоупотребить вашей подписью он не сможет.
Или вы начинаете бизнес частного цифрового нотариуса, подтверждающим подлинность документов?
В GnuPG для этого существует
export-secret-subkeys, который експортирует закытый ключ без секретной части мастер-ключа. Но там замечание:escaped<!
><blockquote><!escaped> --export-secret-subkeys [names]
Same as --export, but exports the secret keys instead. This
See the option --simple-sk-checksum if you want to import
escapedis normally not very useful and a security risk. The second
form of the command has the special property to render the
secret part of the primary key useless; this is a GNU exten‐
sion to OpenPGP and other implementations can not be expected
to successfully import such a key.
such an exported key with an older OpenPGP implementation.
<!
></blockquote><!escaped>
escapedРиск для безопасности состоит в самом экспорте секретного материала. Никакого дополнительного риска по сравнению с --export-secret-key нет.
<!
><blockquote><!escaped>Кстати, в CKT версиях PGP была весьма полезная возможность – можно было назначить разные парольные фразы для подписи и шифрования. Было бы неплохо получить это же, но в расширенном виде: по фразе для расшифрования, подписи документов/файлов... и подписи ключей.escaped<!
></blockquote><!escaped-->Использовать такой ключ в GnuPG точно можно, и даже создать посредством "расчленения" его на подключи (экспорт несколько раз, удаление разных подключей, и т. д.), изменения паролей, и соберания заново. Но это долго, и потенциально разбрасывается слишком большое количество секретной информации, так что делать это надо осторожно.
Вообщето наверное стоит написать маленькую утилиту специально для этой цели. Полезная вещь, действительно.
PGP я уже очень давно не видел в лицо, но в GnuPG это происходит так: для подписи документов всегда используется самый новый под-ключ, пригодный для подписи, или в отсутсвии такого — основной ключ.
Даже указав основной ключ, будет происходить вышеописанное. То есть GnuPG никогда не будет использовать основной ключ для подписи документов, если есть под-ключ для подписи. Оно и логично.
Основной ключ: для сертификации, под-ключи для шифрования и подписи документов. Основной ключ может выполнять эти функции, если нет соответствующего под-ключа.
комментариев: 11558 документов: 1036 редакций: 4118
В принципе, можно допустить ситуацию, когда злонамеренный пользователь генерирует два ключа с правдоподобным содержанием сертификатов, образующих коллизию, но, при этом, один из ключей таков, что заверитель никогда бы не стал его подписывать.
Например, Алиса является заверителем. Мэллори просит её подписать его ключ. Она устанавливает его личность и заверяет ключ. Позднее Мэллори заменяет свой сертификат коллизирующим сертификатом на имя Чарли и подсовывает его Бобу, который доверяет подписи Алисы, чтобы организовать атаку MITM на линию связи между Бобом и Чарли.
Конечно, сертификаты OpenPGP имеют защиту от таких атак, но учитывая, как этой весной удалось сформировать два правдоподобных коллизирующих сертификата Х.509, трудно что-то исключить (да, записи сертификата там были идентичны, но и методики вычисления коллизий не стоят на месте, в чём можно убедиться на примере работы Келси и Коно по атаке Нострадамуса).
Несколько раз приходилось выступать в роли Трента. Но исключительно на безвозмездной основе.
комментариев: 9796 документов: 488 редакций: 5664
Главное чтобы не в роли Мэллори или Евы!
комментариев: 1060 документов: 16 редакций: 32
комментариев: 9796 документов: 488 редакций: 5664
То что вы вероятно называете "базовым" ключем используется только для подписи и установления подлинности подключей. Противник сможет только создавать новые фальшивые подключи, которые будут выглядеть подлинными.
Взломать уже имеющиеся подключи? Поскольку подпись проводится по хэш-значению, то не должен. Если отбросить какие-нибудь теоретические-гипотетические атаки.
Если Алиса подпишет ключ Боба, а у Алисы ключ украдут, то ключ Боба от этого не станет взламываемым. А здесь тоже самое, только на связке одного хозяина.
Аналогично.
Хотя, мне эта ситуация не нравится, могут быть подводные камни в реализации, я бы считал весь ключ скомпрометированным целиком.