Типы ключей
Здравствуйте!
Из консоли 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 без «расширения»?
комментариев: 1060 документов: 16 редакций: 32
Не знаю, я как-то без этой настройки обхожусь.
Есть подпись работает, но не работает расшифрование, то возникает ещё такая версия: секретный ключ не содержит некоторых секретных подключей, соответствующих открытым подключам. Такая ситуация может возникнуть, если вы делали эксперименты с отделением подключей от главного ключа – там вполне можно допустить подобную ошибку при обновлении комплекта подключей.
комментариев: 510 документов: 110 редакций: 75
ps отозвал старый подключ, создал новый, обновил на сервере. Все заработало.
sentaus, респект, подсказка про подключи сработала :)
> Например, Алиса является заверителем. Мэллори просит её подписать его ключ. Она устанавливает его личность и заверяет ключ. Позднее Мэллори заменяет свой сертификат коллизирующим сертификатом на имя Чарли и подсовывает его Бобу, который доверяет подписи Алисы, чтобы организовать атаку MITM на линию связи между Бобом и Чарли.
Наверно, можно и без таких извращений: если противник может полностью подделывать хэш, то он может приделать мою сертифицирующую подпись к (потенциально) любому ключу. Разве не так?
> Хотя, мне эта ситуация не нравится, могут быть подводные камни в реализации, я бы считал весь ключ скомпрометированным целиком.
Какие могут быть камни в реализации, если основной ключ на связке даже не ночевал во время атаки?
> Так, даже если Ваш ключ RSA не содержит шифровальных подключей, PGP всё равно позволит шифровать данные, используя для этого материал базового ключа подписи.
Сможет ли GnuPG расшифровать такие данные?
> GnuPG это происходит так: для подписи документов всегда используется самый новый под-ключ, пригодный для подписи, или в отсутсвии такого — основной ключ.
> То есть GnuPG никогда не будет использовать основной ключ для подписи документов, если есть под-ключ для подписи. Оно и логично.
> Основной ключ: для сертификации, под-ключи для шифрования и подписи документов. Основной ключ может выполнять эти функции, если нет соответствующего под-ключа.
А как-то принудительно можно подписать документ основным (сертифицирующим) ключом, а не подключами? Или это можно сделать, только удалив все подключи подписи со связки? Интересен и противоположный вопрос: можно ли подписать чужие ключи своими подключами? Чисто спортивный интерес.
> Например, связку ключей можно разобрать на отдельные подключи и UID'ы с подписями, назначить им разные пароли и из этого собрать связку обратно.
> Использовать такой ключ в GnuPG точно можно, и даже создать посредством "расчленения" его на подключи (экспорт несколько раз, удаление разных подключей, и т. д.), изменения паролей, и соберания заново.
Плохо понимаю, что имелось в виду. Сделать пару основных ключей с отличающимся составом подключей? И что тогда будет после того, когда абонент импортирует оба таких ключа? У него же должны будут оба ключа слиться в один. Т.е. схема неустойчива к бездумным операциям абонента, два таких ключа не должны быть на одной GnuPG-связке ключей.
И штатными средствами до сих пор нельзя назначить разные пароли для разных подключей? passwd в --edit-key умеет менять только все пароли для всех ключей сразу?
комментариев: 11558 документов: 1036 редакций: 4118
Что понимать под подделкой? Выше речь шла об устойчивости к нахождению коллизий, Ваша же атака подразумевает нахождение прообраза.
Насколько помню, да.
Первое допустимо, если позволяют capability нужного (под)ключа и если принудительно указать его ID — 0xAB123456!. Второе — нет, сертифицирующая подпись может быть только от главного ключа.
Мне лень перечитывать всё, на что Вы ссылаетесь, но: /Библиотека/Руководства/УправлениеКлючами/ПодключиOpenPGP
Давно этого не делал, так что без понятия. Раньше это достигалось путём разделения подключей по разным связкам и смены пароля отдельно на каждой.
Этот документ, естественно, был проштудирован в первую очередь. Потом прочитал топик про смену ключа ntldr и оттуда по ссылкам попал сюда. Кстати, этот топик хороший несмотря на археологичность, он снял много вопросов из тех, которые накопились после прочтения документа «ПодключиOpenPGP».
Для шифрования так же? Т.е. если опцию E имеет как главный ключ, так и подключи, то используются подключи, причём из подключей выбирается самый последний сгенерированный (или последний обновлёный/продлёный)?
комментариев: 11558 документов: 1036 редакций: 4118
Это очень большое "если" — в обычных условиях ни одна реализация с поддежкой ключей v4 не генерирует главные ключи с функцией шифрования.
Из числа шифрующих подключей, при условии наложения их сроков действия, выбирается самый новый.
... но обычные условия легко обходятся с помощью опции --expert. :-) Впрочем, да, смысла генерировать такие ключи не вижу.
комментариев: 11558 документов: 1036 редакций: 4118
На то она и expert, что, как предполагается, пользователь понимает последствия своих действий.
Очень полезная информация, уже пригодилась: хотел обновить ключ в профиле, но опции нет. Пришлось сначала удалить ключ, а потом загрузить обновлённый. Чтобы удалить ключ, надо было подписать случайную строку, выданную движком. Но ключ-то я уже обновил, потому подпись была сделана новым подключом этого же PGP-ключа. Движок почему-то туп и не понимает такую подпись, хотя при проверке подписи ему должно писаться, что эта подпись сделана некоторым подключом на связке, заверенным старым главным сертифицирующим ключом (разве нет?). Пользуясь тем, что на старом ключе подключа подписи не было, а, значит, подписи проставлялись главным ключом, чтобы убедить движок в своей идентичности было достаточно принудительно подписать строку своим главным ключом, а не подключом. Всё сработало. В крайнем случае всегда можно было сделать подпись ключом из бэкапа, но принудительная подпись упростила решение проблемы.
В связи с озвученным возникает ещё один вопрос: допустим, подключ просрочен или был отозван, как тогда его обновить в профиле? Для просроченных (expired) ключей после их продления, я так понял, надо либо просить вас лично, либо ждать истечения двухнедельного таймаута. Но если при синхронизации БД ключей с серверами ключей ключ пометился как отозванный, то как его заменить в профиле? И, вообще, что будет в этом случае писать движок? «Ваш ключ отозван, поэтому доступ к изменению профиля по ключу более невозможен ни при каких обстоятельствах»? В стандарте эти вопросы вроде никак не отражены. В «индикаторе состояния» вроде даже нет такого понятия, как «ключ отозван». Может, оно и логично (ключом подписывалось, потом он вышел из обращения и всё хорошо), но что произойдёт, если изгалиться так: после отзыва ключа принудительно что-нибудь им подписать и положить на сайт? Такая подпись будет, получается, полностью ОК, хотя сайт может уже знать, что ключ просрочен? Или он всё-таки поругается?
Ещё один способ запороть профиль: создаём такой PGP-ключ, что главный ключ имеет только право на сертификацию, но не подпись, а также подключи для подписи и шифрования. Через какое-то время отзываем подключи и удаляем их копии, но не сам ключ, а местный сервер ключей синхронизируется с основными серверами ключей. Всё, теперь по ключу никак не авторизоваться на сайте и никак его не удалить с профиля, потому что нет возможности подписать что-либо. Пока не загрузим новый подключ подписи на сервера ключей, и пока сайт не синхронизируется с ними, ничего с профилем будет сделать нельзя.
комментариев: 11558 документов: 1036 редакций: 4118