id: Гость   вход   регистрация
текущее время 14:11 29/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 След.
Комментарии
— sentaus (06/06/2009 11:48)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
В параметре default-key ID своего ключа нужно писать с 0x или без?

Не знаю, я как-то без этой настройки обхожусь.

Из консоли подпись-расшифрование этим ключом выполняется?

Есть подпись работает, но не работает расшифрование, то возникает ещё такая версия: секретный ключ не содержит некоторых секретных подключей, соответствующих открытым подключам. Такая ситуация может возникнуть, если вы делали эксперименты с отделением подключей от главного ключа – там вполне можно допустить подобную ошибку при обновлении комплекта подключей.
— Вий (06/06/2009 12:36, исправлен 06/06/2009 12:41)   профиль/связь   <#>
комментариев: 510   документов: 110   редакций: 75
Понял в чем дело. После переустановки системы я восстановил ключ с резервного носителя, но на нем был уже просроченный подключ шифрования. Новый подключ шифрования я не сохранил. Восстановив из репозитария открытый ключ я восстановил только открытый ключ подключа шифрования.
ps отозвал старый подключ, создал новый, обновил на сервере. Все заработало.
sentaus, респект, подсказка про подключи сработала :)
— Гость (23/09/2013 11:09)   <#>
> Стойкость к коллизиям хеш-функций интересна только в нотариальных приложениях ЭЦП. Если подписывать только свои сообщения, то стойкость к коллизиям не играет роли. Даже в случае подписи PGP-ключей, коллизии неважны, так как "подсунуть" вам один ключ, чтобы завладеть подписью на другом может только человек генерировавший оба ключа, так что злоупотребить вашей подписью он не сможет.
> Например, Алиса является заверителем. Мэллори просит её подписать его ключ. Она устанавливает его личность и заверяет ключ. Позднее Мэллори заменяет свой сертификат коллизирующим сертификатом на имя Чарли и подсовывает его Бобу, который доверяет подписи Алисы, чтобы организовать атаку MITM на линию связи между Бобом и Чарли.

Наверно, можно и без таких извращений: если противник может полностью подделывать хэш, то он может приделать мою сертифицирующую подпись к (потенциально) любому ключу. Разве не так?

> Хотя, мне эта ситуация не нравится, могут быть подводные камни в реализации, я бы считал весь ключ скомпрометированным целиком.

Какие могут быть камни в реализации, если основной ключ на связке даже не ночевал во время атаки?

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

Сможет ли GnuPG расшифровать такие данные?

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

А как-то принудительно можно подписать документ основным (сертифицирующим) ключом, а не подключами? Или это можно сделать, только удалив все подключи подписи со связки? Интересен и противоположный вопрос: можно ли подписать чужие ключи своими подключами? Чисто спортивный интерес.

> Например, связку ключей можно разобрать на отдельные подключи и UID'ы с подписями, назначить им разные пароли и из этого собрать связку обратно.
> Использовать такой ключ в GnuPG точно можно, и даже создать посредством "расчленения" его на подключи (экспорт несколько раз, удаление разных подключей, и т. д.), изменения паролей, и соберания заново.

Плохо понимаю, что имелось в виду. Сделать пару основных ключей с отличающимся составом подключей? И что тогда будет после того, когда абонент импортирует оба таких ключа? У него же должны будут оба ключа слиться в один. Т.е. схема неустойчива к бездумным операциям абонента, два таких ключа не должны быть на одной GnuPG-связке ключей.

И штатными средствами до сих пор нельзя назначить разные пароли для разных подключей? passwd в --edit-key умеет менять только все пароли для всех ключей сразу?
— Гость (23/09/2013 12:04)   <#>
На примере этого топика заметил странную особенность: ник sentaus зарегистрирован в 2006-ом, но первые его посты числятся 2005-ым. Как это так получилось? Результат ручного вмешательства после перехода на новый движок?
— SATtva (23/09/2013 12:33)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Археологи в треде.

Наверно, можно и без таких извращений: если противник может полностью подделывать хэш, то он может приделать мою сертифицирующую подпись к (потенциально) любому ключу. Разве не так?

Что понимать под подделкой? Выше речь шла об устойчивости к нахождению коллизий, Ваша же атака подразумевает нахождение прообраза.

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

Сможет ли GnuPG расшифровать такие данные?

Насколько помню, да.

А как-то принудительно можно 1) подписать документ основным (сертифицирующим) ключом, а не подключами? Или это можно сделать, только удалив все подключи подписи со связки? Интересен и противоположный вопрос: 2) можно ли подписать чужие ключи своими подключами? Чисто спортивный интерес.

Первое допустимо, если позволяют capability нужного (под)ключа и если принудительно указать его ID — 0xAB123456!. Второе — нет, сертифицирующая подпись может быть только от главного ключа.

Плохо понимаю, что имелось в виду. Сделать пару основных ключей с отличающимся составом подключей? И что тогда будет после того, когда абонент импортирует оба таких ключа? У него же должны будут оба ключа слиться в один. Т.е. схема неустойчива к бездумным операциям абонента, два таких ключа не должны быть на одной GnuPG-связке ключей.

Мне лень перечитывать всё, на что Вы ссылаетесь, но: /Библиотека/Руководства/УправлениеКлючами/ПодключиOpenPGP

И штатными средствами до сих пор нельзя назначить разные пароли для разных подключей? passwd в --edit-key умеет менять только все пароли для всех ключей сразу?

Давно этого не делал, так что без понятия. Раньше это достигалось путём разделения подключей по разным связкам и смены пароля отдельно на каждой.
— Гость (23/09/2013 13:00)   <#>
Спасибо за ответ.


Этот документ, естественно, был проштудирован в первую очередь. Потом прочитал топик про смену ключа ntldr и оттуда по ссылкам попал сюда. Кстати, этот топик хороший несмотря на археологичность, он снял много вопросов из тех, которые накопились после прочтения документа «ПодключиOpenPGP».
— Гость (23/09/2013 18:17)   <#>

Для шифрования так же? Т.е. если опцию E имеет как главный ключ, так и подключи, то используются подключи, причём из подключей выбирается самый последний сгенерированный (или последний обновлёный/продлёный)?
— SATtva (23/09/2013 18:22)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Т.е. если опцию E имеет как главный ключ

Это очень большое "если" — в обычных условиях ни одна реализация с поддежкой ключей v4 не генерирует главные ключи с функцией шифрования.

Из числа шифрующих подключей, при условии наложения их сроков действия, выбирается самый новый.
— Гость (23/09/2013 18:34)   <#>

... но обычные условия легко обходятся с помощью опции --expert. :-) Впрочем, да, смысла генерировать такие ключи не вижу.
— SATtva (23/09/2013 18:44)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
но обычные условия легко обходятся с помощью опции --expert.

На то она и expert, что, как предполагается, пользователь понимает последствия своих действий.
— Гость (25/09/2013 00:59)   <#>

Очень полезная информация, уже пригодилась: хотел обновить ключ в профиле, но опции нет. Пришлось сначала удалить ключ, а потом загрузить обновлённый. Чтобы удалить ключ, надо было подписать случайную строку, выданную движком. Но ключ-то я уже обновил, потому подпись была сделана новым подключом этого же PGP-ключа. Движок почему-то туп и не понимает такую подпись, хотя при проверке подписи ему должно писаться, что эта подпись сделана некоторым подключом на связке, заверенным старым главным сертифицирующим ключом (разве нет?). Пользуясь тем, что на старом ключе подключа подписи не было, а, значит, подписи проставлялись главным ключом, чтобы убедить движок в своей идентичности было достаточно принудительно подписать строку своим главным ключом, а не подключом. Всё сработало. В крайнем случае всегда можно было сделать подпись ключом из бэкапа, но принудительная подпись упростила решение проблемы.

В связи с озвученным возникает ещё один вопрос: допустим, подключ просрочен или был отозван, как тогда его обновить в профиле? Для просроченных (expired) ключей после их продления, я так понял, надо либо просить вас лично, либо ждать истечения двухнедельного таймаута. Но если при синхронизации БД ключей с серверами ключей ключ пометился как отозванный, то как его заменить в профиле? И, вообще, что будет в этом случае писать движок? «Ваш ключ отозван, поэтому доступ к изменению профиля по ключу более невозможен ни при каких обстоятельствах»? В стандарте эти вопросы вроде никак не отражены. В «индикаторе состояния» вроде даже нет такого понятия, как «ключ отозван». Может, оно и логично (ключом подписывалось, потом он вышел из обращения и всё хорошо), но что произойдёт, если изгалиться так: после отзыва ключа принудительно что-нибудь им подписать и положить на сайт? Такая подпись будет, получается, полностью ОК, хотя сайт может уже знать, что ключ просрочен? Или он всё-таки поругается?
— Гость (25/09/2013 01:46)   <#>
Можно ли отозвать просроченные (expired) подключи без их продления?
— Гость (25/09/2013 23:22)   <#>

Ещё один способ запороть профиль: создаём такой PGP-ключ, что главный ключ имеет только право на сертификацию, но не подпись, а также подключи для подписи и шифрования. Через какое-то время отзываем подключи и удаляем их копии, но не сам ключ, а местный сервер ключей синхронизируется с основными серверами ключей. Всё, теперь по ключу никак не авторизоваться на сайте и никак его не удалить с профиля, потому что нет возможности подписать что-либо. Пока не загрузим новый подключ подписи на сервера ключей, и пока сайт не синхронизируется с ними, ничего с профилем будет сделать нельзя.
— Гость (29/09/2013 10:28)   <#>
Можно ли подписать текст сразу двумя разными ключами или подключами? Ну, т.е., так, чтобы при проверке подписи gpg --verify получатель сразу видел, что подписано двумя ключами. Дважды указать опцию -u поможет?
— SATtva (29/09/2013 11:10)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Стандарт допускает такую штуку (конкатенация множества подписей в один пакет), но gpg, насколько мне известно, нет. Если указать несколько -u, используется только первая.
На страницу: 1, 2, 3, 4, 5 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3