id: Гость   вход   регистрация
текущее время 21:25 28/03/2024
Автор темы: Вий, тема открыта 08/08/2005 17:05 Печать
создать
просмотр
ссылки

Типы ключей


Здравствуйте!


Из консоли 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 без «расширения»?


 
На страницу: 1, 2, 3, 4, 5 След.
Комментарии
— SATtva (08/08/2005 17:30)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
RSA — общий ключ для шифрования и подписи.
RSA-E — ключ RSA только для шифрования.
RSA-S — ключ RSA только для подписи.

Первый соответствует формату ключей v3, где один асимметричный ключ применялся для обеих операций. В формате v4 мы находим два или более асимметричных ключа, где один — базовый — используется только для подписи (RSA-S), а остальные — подключи (RSA-E) — для шифрования.
— unknown (08/08/2005 17:59)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
И второй вариант действительно лучше.
— Гость (24/08/2005 18:58)   <#>
Скажите, ключ подписания и ключ расшифрования это одно и то же или нет?
— SATtva (24/08/2005 19:45)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Вообще и ту, и другую операцию выполняет закрытый ключ асимметричной пары.

В ранних версиях PGP (до 5.0), где применялся формат ключей v3, каждый закрытый ключ был предназначен как для подписания (т.е. генерации цифровых подписей на документах и на сертификатах ключей), так и для расшифрования данных. Такая практика менее безопасна по той причине, что взлом одного закрытого ключа позволит и подделывать подписи пользователя, и расшифровывать все зашифрованные этим ключом файлы и переписку.

Для улучшения ситуации был предложен новый формат ключей v4, представляющих собой как бы связку из нескольких ключевых пар, где одна — базовая, применяется только для подписей, а остальные, названные подключами (subkeys), — только для зашифрования / расшифрования данных. При этом подключи можно свободно заменять, аннулировать и удалять, не жертвуя базовым ключом и собранными на нём сертифицирующими подписями.

Поэтому в контексте ключей формата v4 (это ключи DH/DSS и новые RSA) ответ на Ваш вопрос будет — не одно и то же. Но раньше было иначе.
— Гость (02/09/2005 22:29)   <#>
В общем, SATtva прав, но стоить несколько уточнить в чем дело и зачем все это делается. Разделение на ключ подписи и ключ шифрования Циммерман реализовал во время правовых и политических бурь вокруг PGP по той причине, что в некоторых странах (к ним, если мне не изменяет память, относится и РФ) при некоторых обстоятельствах вы обязани раскрыть правоохранительным органам ваш ключ для шифрования (или это просто целесообразно сделать в целях доказательства чего-то связанного с прошлым секретом).
Разделив ключи, вы передаете ваш ключ шифрования, отзывайте его и генерируете новый, но при этом не теряете подписи на вашем основном ключе, так что не надо зарабатывать доверие к ключу, как с самого начала. Таким образом, правоохранительные органы или суд получают доступ к вашим прошлым секретам, но не могут в будущем читать вашу конфиденциальную переписку, и вам не надо заново со всеми встречаться.
Так поступать очень целесообразно, но совсем не обязательно. Общий ключь RSA может быть использован и в новом формате v4, правда смысла в этом мало. Формат v4 более безопасен по ряду причин, и возможность разделения ключа — лишь одна из них.
К слову, можно еще использовать под-ключ для подписи документов. В этом случае подпись ключей (своих и чужих, сертификация и отзыв) производится основным ключем, а документы подписываются под-ключем. Таким образом появляется возможность не держать основной секретный ключ на подключенном к сети компьютеру вообще никогда, что сильно повышает безопасность, при том, что опять же, сохраняет ваши сертификати при смене ключа для подписи документов, которым вы регулярно пользуетесь.

Я этого, к сожалению, пять лет назад не знал, так что придется опять всех умолять подписать мой новый ключ до истечения срока и отзыва старого (обновлять его не собераюсь по разным причинам). Но такое происходит в последний раз.
Следующий мой основной ключ будет 4096-битовым RSA-S ключем, который я сертифицирую на неопределенный срок, но пользоваться им для подписи документов не буду (подпись таким ключем — монстр). Для этой цели будет несколько, регулярно меняемых ключей от 1024 до 2048 битов, с разными алгоритмами. А для шифрования однин ElGamal ключ в 2048 битов, тоже регулярно меняемый (каждые 5 лет, скажем).
Иметь несколько ключей шифрования одновременно не стоит, так как не вы выберайте, каким из них ваши корреспонденты будут пользоваться, а рассчитывать на то, что они будут этот выбор делать рационально — не стоит; это все реализации делают автоматически, просто выберая самый новый ключ. А тогда зачем все остальные?

Походные ключи, развертываемые из паролей вставлять в свой основной блок я скорее всего не буду. Это будет отдельный ключ, сертифицированный (в том числе и для отзыва) первым. Но над этим еще надо как-следует подумать. Походный ключь из пароля — штука новая, и нет ни опыта его использования ни консенсусных рекомендаций по их безопасному использованию. Для обсуждения практик, рисков и опыта связанних с такими ключами я уже открыл соответствующаю тему "PGP на ходу".
— SATtva (02/09/2005 23:50)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
(к ним, если мне не изменяет память, относится и РФ)

Ну, вообще к этим странам относятся все страны. :) Не рассматривая нюансы в законодательной базе и судебной практике, в любой стране суд или органы следствия могут обязать Вас раскрыть свой ключ шифрования. Санкции за нарушение, конечно, везде различны.

Разделив ключи, вы передаете ваш ключ шифрования, отзывайте его и генерируете новый

Возможно, но, на мой взгляд, не совсем верно — оппонент получает возможность скомпрометировать всю информацию, зашифрованную этим подключом. В ситуации правового принуждения (именно правового; при физическом такой номер не пройдёт) разумнее прибегнуть к GnuPG и его функции расшифрования сеансового ключа. Мы предоставляем органам сеансовые шифровальные ключи к интересующим их письмам/файлам, при этом не раскрывая прочую информацию.

К слову, можно еще использовать под-ключ для подписи документов.

Только в GnuPG, если не ошибаюсь? Указывая при подписании данных ID конкретного подключа?

Это интересная мысль. Планирую к концу 2006 заменить свой ключ (учитывая "последние события в криптоанализе хэш-функций") и как раз думаю над стратегией формата и размеров.
— sentaus (03/09/2005 00:46)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32

Планирую к концу 2006 заменить свой ключ (учитывая "последние события в криптоанализе хэш-функций") и как раз думаю над стратегией формата и размеров.


Хотелось бы поскорее получить v5, но пока не судьба. :(


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


А как это сделать-то? Как убрать мастер-ключ, оставив только подключи?




Кстати, в CKT версиях PGP была весьма полезная возможность – можно было назначить разные парольные фразы для подписи и шифрования. Было бы неплохо получить это же, но в расширенном виде: по фразе для расшифрования, подписи документов/файлов... и подписи ключей.
— Гость (04/09/2005 23:03)   <#>
SATtva:

Возможно, но, на мой взгляд, не совсем верно — оппонент получает возможность скомпрометировать всю информацию, зашифрованную этим подключом. В ситуации правового принуждения (именно правового; при физическом такой номер не пройдёт) разумнее прибегнуть к GnuPG и его функции расшифрования сеансового ключа. Мы предоставляем органам сеансовые шифровальные ключи к интересующим их письмам/файлам, при этом не раскрывая прочую информацию.

Согласен, но всякое бывает.


Только в GnuPG, если не ошибаюсь? Указывая при подписании данных ID конкретного подключа?

PGP я уже очень давно не видел в лицо, но в GnuPG это происходит так: для подписи документов всегда используется самый новый под-ключ, пригодный для подписи, или в отсутсвии такого — основной ключ.

Это интересная мысль. Планирую к концу 2006 заменить свой ключ (учитывая "последние события в криптоанализе хэш-функций") и как раз думаю над стратегией формата и размеров.

Стойкость к коллизиям хеш-функций интересна только в нотариальных приложениях ЭЦП. Если подписывать только свои сообщения, то стойкость к коллизиям не играет роли. Даже в случае подписи PGP-ключей, коллизии неважны, так как "подсунуть" вам один ключ, чтобы завладеть подписью на другом может только человек генерировавший оба ключа, так что злоупотребить вашей подписью он не сможет.
Или вы начинаете бизнес частного цифрового нотариуса, подтверждающим подлинность документов?
— Гость (04/09/2005 23:19)   <#>
sentaus:
А как это сделать-то? Как убрать мастер-ключ, оставив только подключи?


В GnuPG для этого существует export-secret-subkeys, который експортирует закытый ключ без секретной части мастер-ключа. Но там замечание:
<!
escaped><blockquote><!escaped> --export-secret-subkeys [names]
Same as --export, but exports the secret keys instead. This
is 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.

See the option --simple-sk-checksum if you want to import
such an exported key with an older OpenPGP implementation.

<!
escaped></blockquote><!escaped>
Риск для безопасности состоит в самом экспорте секретного материала. Никакого дополнительного риска по сравнению с --export-secret-key нет.

<!
escaped><blockquote><!escaped>Кстати, в CKT версиях PGP была весьма полезная возможность – можно было назначить разные парольные фразы для подписи и шифрования. Было бы неплохо получить это же, но в расширенном виде: по фразе для расшифрования, подписи документов/файлов... и подписи ключей.
<!
escaped></blockquote><!escaped-->
Использовать такой ключ в GnuPG точно можно, и даже создать посредством "расчленения" его на подключи (экспорт несколько раз, удаление разных подключей, и т. д.), изменения паролей, и соберания заново. Но это долго, и потенциально разбрасывается слишком большое количество секретной информации, так что делать это надо осторожно.

Вообщето наверное стоит написать маленькую утилиту специально для этой цели. Полезная вещь, действительно.
— Гость (04/09/2005 23:40)   <#>
[quote:9500494123="Д. Надь"]
SATtva:
Только в GnuPG, если не ошибаюсь? Указывая при подписании данных ID конкретного подключа?

PGP я уже очень давно не видел в лицо, но в GnuPG это происходит так: для подписи документов всегда используется самый новый под-ключ, пригодный для подписи, или в отсутсвии такого — основной ключ.

Даже указав основной ключ, будет происходить вышеописанное. То есть GnuPG никогда не будет использовать основной ключ для подписи документов, если есть под-ключ для подписи. Оно и логично.

Основной ключ: для сертификации, под-ключи для шифрования и подписи документов. Основной ключ может выполнять эти функции, если нет соответствующего под-ключа.
— SATtva (05/09/2005 09:51)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
"подсунуть" вам один ключ, чтобы завладеть подписью на другом может только человек генерировавший оба ключа, так что злоупотребить вашей подписью он не сможет.

В принципе, можно допустить ситуацию, когда злонамеренный пользователь генерирует два ключа с правдоподобным содержанием сертификатов, образующих коллизию, но, при этом, один из ключей таков, что заверитель никогда бы не стал его подписывать.

Например, Алиса является заверителем. Мэллори просит её подписать его ключ. Она устанавливает его личность и заверяет ключ. Позднее Мэллори заменяет свой сертификат коллизирующим сертификатом на имя Чарли и подсовывает его Бобу, который доверяет подписи Алисы, чтобы организовать атаку MITM на линию связи между Бобом и Чарли.

Конечно, сертификаты OpenPGP имеют защиту от таких атак, но учитывая, как этой весной удалось сформировать два правдоподобных коллизирующих сертификата Х.509, трудно что-то исключить (да, записи сертификата там были идентичны, но и методики вычисления коллизий не стоят на месте, в чём можно убедиться на примере работы Келси и Коно по атаке Нострадамуса).

Или вы начинаете бизнес частного цифрового нотариуса, подтверждающим подлинность документов?

Несколько раз приходилось выступать в роли Трента. Но исключительно на безвозмездной основе.
— unknown (05/09/2005 12:17)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Несколько раз приходилось выступать в роли Трента. Но исключительно на безвозмездной основе.

Главное чтобы не в роли Мэллори или Евы!
— sentaus (05/09/2005 18:59)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
В GnuPG для этого существует export-secret-subkeys,

<!
escaped></blockquote><!escaped>
Да, упустил. А ведь казалось, что внимательно читал. :)

<!
escaped><blockquote><!escaped>
Только в GnuPG, если не ошибаюсь? Указывая при подписании данных ID конкретного подключа?

<!
escaped></blockquote><!escaped-->
И ещё, PGP может проверять такие подписи начиная с версии 8.0.0
— Гость (20/09/2005 09:47)   <#>
Будут ли взломаны подключи, если противник завладеет базовым ключом, но на нем не окажется подключа, и напротив, если противник завладеет подключом (его секретной частью) взломает ли он базовый ключ?
— unknown (20/09/2005 20:05)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664


Будут ли взломаны подключи, если противник завладеет базовым ключом, но на нем не окажется подключа



То что вы вероятно называете "базовым" ключем используется только для подписи и установления подлинности подключей. Противник сможет только создавать новые фальшивые подключи, которые будут выглядеть подлинными.

Взломать уже имеющиеся подключи? Поскольку подпись проводится по хэш-значению, то не должен. Если отбросить какие-нибудь теоретические-гипотетические атаки.

Если Алиса подпишет ключ Боба, а у Алисы ключ украдут, то ключ Боба от этого не станет взламываемым. А здесь тоже самое, только на связке одного хозяина.



если противник завладеет подключом (его секретной частью) взломает ли он базовый ключ?



Аналогично.


Хотя, мне эта ситуация не нравится, могут быть подводные камни в реализации, я бы считал весь ключ скомпрометированным целиком.
На страницу: 1, 2, 3, 4, 5 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3