Типы ключей


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

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


Комментарии
— SATtva (08/08/2005 17:30)   
RSA — общий ключ для шифрования и подписи.
RSA-E — ключ RSA только для шифрования.
RSA-S — ключ RSA только для подписи.

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

В ранних версиях 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)   
(к ним, если мне не изменяет память, относится и РФ)

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

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

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

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

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

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

Планирую к концу 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)   
"подсунуть" вам один ключ, чтобы завладеть подписью на другом может только человек генерировавший оба ключа, так что злоупотребить вашей подписью он не сможет.

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

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

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

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

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

Главное чтобы не в роли Мэллори или Евы!
— sentaus (05/09/2005 18:59)   
В 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)   


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



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

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

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



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



Аналогично.


Хотя, мне эта ситуация не нравится, могут быть подводные камни в реализации, я бы считал весь ключ скомпрометированным целиком.
— Lustermaf (03/11/2005 21:44)   
1. Что означают параметры A (Authentication) и C (Certify) в свойствах ключа/подключа, что они дают?
pub 1024D/0x500B8987 created: 2005-08-06 expires: 2008-12-31 usage: CSA
trust: ultimate validity: ultimate
sub 4096g/0xBF3D3DC2 created: 2005-08-06 expires: 2008-12-31 usage: E
[ultimate] (1). lusfert <...@email.com>
[ultimate] (2) Lustermaf <...@email.com>

Почему A не ставится по умолчанию при генерации ключа (можно поставить в --expert), а C прописывается всегда (даже в --expert нельзя что-то поправить)? Возможно ли изменить эти параметры уже после создания ключевой пары?

2. Какая длина ключа у используемой в GnuPG реализации blowfish?
— SATtva (03/11/2005 22:24)   
1. Certify — сертификация ключей (?). Насчёт Authentication ничего толкового в голову не приходит.

2. 128 бит[link1].
— Lustermaf (08/11/2005 21:59)   
SATtva:
Насчёт Authentication ничего толкового в голову не приходит.

Ответ David Shaw на этот вопрос:
> What does type "A" mean and where is it used?

One possible (and current) use is to use an OpenPGP key for ssh authentication.

David

http://lists.gnupg.org/piperma..... November/027478.html[link2]
— SATtva (09/11/2005 00:00)   
Предполагал нечто подобное. Спасибо.
— Вий (02/01/2006 06:26)   
Известно, что GPG позволяет использовать ключи на эллиптических кривых, однако меню генерации ключей (версия gpg .1.4.2) не предлагает генерацию таких ключей. Как сгенерировать такие ключи? О предостережении разработчиков и комментариях на эту тему мне известно.
— Lustermaf (02/01/2006 15:11)   
Вий, http://alumnes.eup.udl.es/~d4372211/descobj.en.html
— Вий (30/05/2006 19:49)   
SATtva:
Для улучшения ситуации был предложен новый формат ключей v4, представляющих собой как бы связку из нескольких ключевых пар, где одна — базовая, применяется только для подписей, а остальные, названные подключами (subkeys), — только для зашифрования / расшифрования данных.

Здравствуйте!
1. Если в версии V4 базовый ключ все же используется для подписи, значит для проверки ЭЦП на связке ключей получателя письма должен присутствовать материал открытой части, соответствующей базовому закрытому ключу.
Пусть для шифрования (на стороне отправителя) и расшифрования (у меня) используется подключ, таким образом оберегая материал базового ключа от операций шифрования. Но в данной ситуации злоумышленник, располагая ЭЦП и открытым текстом подписанного мной сообщения, все равно может пытаться проводить атаки. Где находится грань повышения безопасности, которую не позволяет перейти формат V4?
SATtva:
RSA — общий ключ для шифрования и подписи.
RSA-E — ключ RSA только для шифрования.
RSA-S — ключ RSA только для подписи.

Первый соответствует формату ключей v3, где один асимметричный ключ применялся для обеих операций. В формате v4 мы находим два или более асимметричных ключа, где один — базовый — используется только для подписи (RSA-S), а остальные — подключи (RSA-E) — для шифрования.

2. Какому типу ключей соответствует ключ RSA созданный в gpg но не содержащий подключа? Согласно длине отпечатка это V4, обмен шифрованными сообщениями работает.
— SATtva (30/05/2006 20:40)   
Но в данной ситуации злоумышленник, располагая ЭЦП и открытым текстом подписанного мной сообщения, все равно может пытаться проводить атаки. Где находится грань повышения безопасности, которую не позволяет перейти формат V4?

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

Какому типу ключей соответствует ключ RSA созданный в gpg но не содержащий подключа?

Только что созданный ключ RSA v4 в GnuPG — это RSA-S: базовый ключ подписи (кстати, GnuPG в нынешних версиях и не позволит Вам сгенерировать ключ v3). Чтобы шифровать таким ключом, нужно добавить ему подключ RSA-E.

Правда, PGP не обращает внимания на флаги применения ключей RSA. Так, даже если Ваш ключ RSA не содержит шифровальных подключей, PGP всё равно позволит шифровать данные, используя для этого материал базового ключа подписи.
— Вий (31/05/2006 16:35)   
SATtva, понимаю, что с подключом лучше и все же хочу уточнить насчет использования флагов, о чем вы говорили. Провел эксперимент с ключом RSA V4, который не содержит подключа. Сообщение для корреспондента отправлено в зашифрованном виде. Моя версия gpg 1.4.2, у корреспондента 1.2.6. Выходит с помощью gpg и ключа RSA V4 без подключа все таки зашифровать можно?
— SATtva (31/05/2006 19:01)   
Ключ генерировал Ваш получатель? Может GPG 1.2.6 не выставляет флаг?

Ради эксперимента создал в GPG 1.4.3 новый ключ RSA без подключей шифрования. При попытке зашифровать файл получил предполагавшийся ответ:

— Вий (01/06/2006 17:15)   
То же провел такой же эксперемент
gpg: qqqqq: пропущено: непригодный открытый ключ

Видимо действительно старые версии gpg не выставляет влаг. Ключ (о котором писал в предыдущем сообщении) был создан корреспондентом.
— Вий (29/05/2009 17:43)   
Есть ли отличия в ключах, создаваемых GnuPG 1.4.9 от ключей, которые были созданы в более ранних версиях GnuPG (1.4.6 и более ранние)? Дело в том, что апплет шифрования от Gnome 2.26.1 не понимает моего ключа при расшифровке буфера обмена. Срабатывает только подписывание текста. Однако апплет безотказно работает с ключом, созданным для эксперемента в версии GnuPG 1.4.9.
— sentaus (29/05/2009 18:00)   
А какую ошибку выдает?
Работает ли сам gpg без апплета?
— Вий (06/06/2009 08:41, исправлен 06/06/2009 08:51)   
Да, что-то я напутал, не могу разобраться, GnuPG дает сообщение:
gpg: сбой расшифрования: секретный ключ не найден

Ключ свой импортировал, в файле конфигурации gpg.conf задал параметр:

Проверил, что доверие ключа абсолютное. Секретный ключ на месте, проверил командой gpg --list-secret-key.
Не работает так же Enigmail в почтовой программе. В настоящее время используется GPG 1.4.9, ключ делал в более ранних версиях программы (а может быть даже еще в PGP 8.1, точно не припомню).
В параметре default-key ID своего ключа нужно писать с 0x или без? (пробовал оба варианта).
В чем еще может быть причина не рабочего состояния?
— SATtva (06/06/2009 09:52)   
Как спрашивал sentaus, без апплета работает? Из консоли подпись-расшифрование этим ключом выполняется?
— sentaus (06/06/2009 11:48)   
В параметре default-key ID своего ключа нужно писать с 0x или без?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

В связи с озвученным возникает ещё один вопрос: допустим, подключ просрочен[link12] или был отозван, как тогда его обновить в профиле? Для просроченных (expired) ключей после их продления, я так понял, надо либо просить вас лично, либо ждать истечения двухнедельного таймаута. Но если при синхронизации БД ключей с серверами ключей ключ пометился как отозванный, то как его заменить в профиле? И, вообще, что будет в этом случае писать движок? «Ваш ключ отозван, поэтому доступ к изменению профиля по ключу более невозможен ни при каких обстоятельствах»? В стандарте[link13] эти вопросы вроде никак не отражены. В «индикаторе состояния» вроде даже нет такого понятия, как «ключ отозван». Может, оно и логично (ключом подписывалось, потом он вышел из обращения и всё хорошо), но что произойдёт, если изгалиться так: после отзыва ключа принудительно что-нибудь им подписать и положить на сайт? Такая подпись будет, получается, полностью ОК, хотя сайт может уже знать, что ключ просрочен? Или он всё-таки поругается?
Гость (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)   
Стандарт допускает такую штуку (конкатенация множества подписей в один пакет), но gpg, насколько мне известно, нет. Если указать несколько -u, используется только первая.
Гость (29/09/2013 11:48)   
А другие реализации допускают? Например, коммерческое PGP.
— SATtva (29/09/2013 12:00)   
PGP тоже нет. Вроде, некоторые библиотечные реализации (e.g. BouncyCastle) допускают более гибкое применение в рамках стандарта; на счёт GPGme не уверен, он всё-таки ближе к GnuPG.
Гость (02/02/2014 05:15)   
Есть ли какой-то способ удалить со связки все устаревшие и отозванные подключи одной командой? Дело в том, что, во-первых, это делать тяжело, когда подключей много, а, во-вторых, трудно объяснить, что именно надо сделать, тому, кто не так подкован в работе с GnuPG и командной строкой. Имеется в виду автоматизация следующего процесса (в этом примере учитываются только revoked-ключи):
$ gpg -v -k 0xXXXXXXXX |grep sub |grep -n revoked |sed 's/:.*$//'
1
3
8
9
10
$ gpg --edit-key 0xXXXXXXXX
gpg> key 1
gpg> key 3
gpg> key 8
gpg> key 9
gpg> key 10
gpg> delkey
gpg> save
Гуглил, читал man gpg, но не нашёл ничего про удаление подключей из обычной командной строки без входа в режим --edit-key. Всё это осложняется ещё и тем, что, получается, подключ нельзя задать его keyid'ом, а только номером на связке, но этот номер нефиксирован и может произвольным образом меняться при обновлении связки с сервера ключей. Т.е. порядок следования подключей в выводе совсем не получается упорядочить.
— SATtva (02/02/2014 11:38)   
Такой команды нет, разработчики явно не рассчитывали, что кто-то станет генерировать подключи пачками и распространять ключ в обход серверов ключей. Пишите feature request.
Гость (04/02/2014 17:20)   
Обход серверов ключей тут ни при чём. Как раз цель была в том, чтобы любой мог легко обновить ключ с сервера ключей. Но из-за багов после обновления ключ становится нерабочим в некоторых тупых программах, ему нужен пофикс с удалением старых подключей. Собственно, эту процедуру и хотелось автоматизировать.

Спасибо за пояснение.
Гость (19/03/2014 04:30)   
Есть несколько вопросов по теме.

  1. При пользовании --refresh-keys 0xXXXXXXXX пишется
    gpg: Total number processed: 1
    gpg:         new signatures: XXX
    gpg: XX keys cached (XXXX signatures)
    gpg: XX keys processed (XX validity counts cleared)
    Что значит «validity counts cleared»? Сам термин понятен[link14], но что именно имелось в виду?

  1. Команда обновления ключа Nick'а Mathewson'а:
    $ gpg -v --refresh-keys 0x165733EA
    gpg: refreshing 1 key from hkp://XXX.XXX.XXX
    gpg: requesting key 165733EA from hkp server XXX.XXX.XXX
    gpg: armor header: Version: SKS X.X.X
    gpg: armor header: Comment: Hostname: XXX.XXX
    gpg: can't handle public key algorithm 19
    Что это за такой особенный алгоритм 19? ECDSA[link15], который появился в самых последних версиях?

  1. Обновление ключа:
    $ gpg --edit-key 0xD21739E9
    gpg (GnuPG) X.X.X; Copyright (C) XXXX Free Software Foundation, Inc.
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
     
     
    pub  4096R/D21739E9  created: 2007-06-02  expires: 2015-02-26  usage: SC
                         trust: unknown       validity: unknown
    sub  4096R/21484CFF  created: 2007-06-02  expires: 2015-02-26  usage: E  
    sub  2048R/4BFA08E4  created: 2008-06-19  expires: 2015-02-26  usage: A  
    sub  2432R/0CA757FB  created: 2013-09-11  expires: 2014-09-11  usage:   
    sub  4096R/1BFDFA5C  created: 2013-03-12  expires: 2015-03-12  usage: S
    [ unknown] (1). Daniel Kahn Gillmor <dkg@fifthhorseman.net>
    [ unknown] (2)  Daniel Kahn Gillmor <dkg@openflows.com>
    [ revoked] (3)  Daniel Kahn Gillmor <dkg@astro.columbia.edu>
    [ revoked] (4)  Daniel Kahn Gillmor <dkg-debian.org@fifthhorseman.net>
    [ unknown] (5)  [jpeg image of size 3515]
    [ unknown] (6)  Daniel Kahn Gillmor <dkg@debian.org>
    Третий подключ не имеет типа «usage» (даже не знал, что такие подключи можно создавать). Как GnuPG работает с такими подключами? Например, если на связке будут такой подключ, будет ли он использоваться как для подписи, так и для шифрования данных?
Гость (19/03/2014 04:39)   
Хочется дать понять всем, что конкретные подключи более не будут использоваться ни при каких обстоятельствах. Достаточно ли для этого их просто не обновлять, и пусть они висят на связке как «expired», или лучше принудительно отзывать их перед истечением срока действия? Вопрос вызван тем, что, судя по статистике, мало кто отзывает подключи, почти все считают факт «expired» достаточным (смотрел на Tor- и Debian-ключи). Может быть, «revoked» традиционно трактуется как нечто исключительно экстраординарное (украден/скомпрометирован и т.п)?

Как я понимаю, если кому-то из абонентов сильно хочется, используя дополнительные экспертные опции, он зашифрует что-нибудь нужным подключом независимо от того, устарел ли он или отозван.
— SATtva (19/03/2014 10:00)   
Что значит «validity counts cleared»?

Без понятия. Вероятно, связано с пересчётом значений в trust DB.

Что это за такой особенный алгоритм 19? ECDSA, который появился в самых последних версиях?

Айдишник тот самый.

Третий подключ не имеет типа «usage» (даже не знал, что такие подключи можно создавать). Как GnuPG работает с такими подключами? Например, если на связке будут такой подключ, будет ли он использоваться как для подписи, так и для шифрования данных?

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

When using gpg an exclamation mark (!) may be appended to force using the specified primary or secondary key and not to try and calculate which primary or secondary key to use.
— SATtva (19/03/2014 10:08)   
Хочется дать понять всем, что конкретные подключи более не будут использоваться ни при каких обстоятельствах. Достаточно ли для этого их просто не обновлять, и пусть они висят на связке как «expired», или лучше принудительно отзывать их перед истечением срока действия?

Expired-состояние может быть обойдено случайно, если у пользователя некорректно настроены системные часы. Однако я не помню, как GnuPG реагирует на наличие сертификата отзыва, подписанного в будущем. Если метка времени не проверяется, а проверяется только подпись, то случайно использовать такой ключ не удастся даже при сбитом таймере.

Может быть, «revoked» традиционно трактуется как нечто исключительно экстраординарное (украден/скомпрометирован и т.п)?

Как правило, именно так[link16]:
Аннулированный сертификат гораздо более подозрителен, нежели истекший.


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

Запретить это принципиально Вы, конечно, не можете.
— unknown (19/03/2014 10:15)   
Третий подключ не имеет типа «usage» (даже не знал, что такие подключи можно создавать). Как GnuPG работает с такими подключами? Например, если на связке будут такой подключ, будет ли он использоваться как для подписи, так и для шифрования данных?

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

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

В общем-то да, но получатель имеет право относится к такому сообщению с подозрением, да и отправитель не может быть уверенным, что такое сообщение будет вообще прочитано получателем. Получатель может удалять просроченные закрытые подключи со своей ключевой связки. А так, да, обычно или продлевают срок действия или не трогают по его истечении.

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

Над остальными вопросами стоит подумать.
Гость (19/03/2014 19:12)   

А можно отозвать за день до истечения срока, например. Если хочется сделать резкую границу для перехода на новые подключи, чтобы не ждать секунда-в-секунду точного истечения срока старых, проще добавить новые подключи и отозвать старые. Точнее, как только абонент обновит связку, он сразу начнёт шифровать самыми свежими подключами, но я при пользовании автоматическими программами не увижу, обновил ли кто-либо или ещё нет, пока не истечёт срок подключей (считаем, что никто не будет принудительно шифровать устаревшими или отозванными подключами). Если же на моей связке я отозвал старые подключи до срока их действия, и кто-то ими что-то зашифровал, GnuPG сразу начнёт ругаться, как я понимаю. Т.е. вероятность заметить проблему, что кто-то вовремя не обновил ключ, выше. Впрочем, это всё имеет смысл только для короткого промежутка времени между созданием новых подключей и устареванием старых.
Гость (23/03/2014 09:14)   

Проверил:
$ gpg -vvv -e -r 0x0CA757FB! test
gpg: using character set `utf-8'
gpg: 0x0CA757FB!: skipped: unusable public key
gpg: test: encryption failed: unusable public key
$ gpg -vvv -e -r 0x1BFDFA5C! test
gpg: using character set `utf-8'
gpg: 0x1BFDFA5C!: skipped: unusable public key
gpg: test: encryption failed: unusable public key
Один подключ — для подписи, другой — вообще без capabilities, результат один и тот же.


Если мне напишут сообщение, зашифровав его отозванным ключом/подключом, я смогу его расшифровать (возможно, указав gpg дополнительные опции)?

И ещё такой вопрос: можно ли «разотозвать» ключ при условии, что он никуда в интернет не загружался, а сертификат отзыва был загружен только на локальную связку (чистой копии связки с неотозванной версией ключа нет)? Судя по тому, что все операции с ключом — навешивание дополнительных подписей, это должно делаться, но я не знаю, можно ли это сделать встроенными средствами gpg.
— SATtva (23/03/2014 12:26)   
Если мне напишут сообщение, зашифровав его отозванным ключом/подключом, я смогу его расшифровать (возможно, указав gpg дополнительные опции)?

В экспертном режиме, кажется, да.

И ещё такой вопрос: можно ли «разотозвать» ключ при условии, что он никуда в интернет не загружался, а сертификат отзыва был загружен только на локальную связку (чистой копии связки с неотозванной версией ключа нет)?

Некогда перепроверять, но штатной функции вроде бы нет (поправьте, если неправ). Т.е. единственный вариант — разбивать ключ на пакеты, выкидывать сертификат отзыва и склеивать обратно.
Гость (24/03/2014 00:20)   
Спасибо, ясно.
— unknown (23/12/2014 13:54, исправлен 23/12/2014 14:18)   

Вот подумалось, помимо индекса, размер ключа — странный! 211 = 2048, 211 + 28 = 2304, 211 + 29 = 2560, 211 + 210 = 3072, 212 = 4096; а 2432 для индекса "R" — это как? Этот ключ единственный для GnuPG-RSA с таким невозможным размером, только у этого Гиллмора он и есть.


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


Конечно, в текстовом виде можно вроде как пару килобайт запихать и в UID, но некрасиво — такой UID будет загромождать отображение ключа при работе в консоли. А в бинарном виде, да ещё и под видом подключа, было бы совсем замечательно.

— SATtva (23/12/2014 14:07)   
Тогда уж под видом Photo ID, для этого даже никаких специальных инструментов не надо — штатное поле для произвольных бинарных данных.

Плюс, если данный подключ имеет signing capability, то такой трюк вообще не сработает, т.к. на ключе в этом случае должен быть особый тип подписи — Primary Key Binding Signature — генерируемый данным подключом.
— unknown (23/12/2014 14:16, исправлен 23/12/2014 14:25)   

Псевдофото, конечно, лучше: GnuPG всегда могут обновить и пропатчить, чтобы она некорректные ключи не принимала.


Я немного поправил свой комент[link18]. А как тогда сгенерить RSA-ключ с таким размером? Помимо странного индекса, размер ключа выглядит ещё более странно. Таких больше ни у кого нет.


P.S. В принципе, такой размер возможен: 2432 = 211 + 28 + 27. Наверное, через экспертный интерфейс его можно выбрать, тогда вопрос снят.

— SATtva (23/12/2014 14:27, исправлен 23/12/2014 14:27)   

Вот, только что проверки ради спокойно сгенерировал ключ такой же длины:


pub 2432R/34F7AD34 2014-12-23


Без всяких expert-режимов.

— unknown (23/12/2014 14:32, исправлен 23/12/2014 14:33)   

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


Осталось придумать, как удобнее цеплять произвольное количество бинарников под видом PhotoID и вообще с этим работать.

Гость (23/12/2014 14:51)   
При добавлении фото оно должно иметь формат JPEG, произвольный файл не добавится.

Не совсем понятно, какая практическая польза от этого и зачем передавать в ключах сообщения.
— SATtva (23/12/2014 14:58)   
Действительно, но формат — это просто заголовок, дальше к нему можно любое содержимое прилепить.
— unknown (23/12/2014 15:32, исправлен 23/12/2014 15:40)   

По типу такого[link19], только вместо tinyurl, см. последний абзац в /comment80997[link20]. Чтобы с отдельными анонимными/псевдонимными адресатами вообще не пользоваться почтой, а только обмениваться ссылками на файлопомойки. Или сделать небольшой твиттер через серверы GnuPG, или анонимно переслать ключ к Bitcoin-кошельку, или для какого-то «походного» ключа повесить под видом открытого ключа запароленную версию закрытого. Можно много чего придумать.

— ressa (23/12/2014 16:08, исправлен 23/12/2014 16:46)   

Размер картинки при --addphoto 7Кб (240x288), туда можно много всего напихать, вплоть до текста и застеганографить.

— unknown (23/12/2014 17:19, исправлен 23/12/2014 17:20)   

7 кб — относительно много текста, если его заархивировать и представить бинарником с jpeg-заголовком.



А вот для этого там практически места не останется. Будет ясно, что никакое это не фото.

— ressa (23/12/2014 17:36, исправлен 23/12/2014 17:39)   

Вот я об этом же, что текста много, а остальные условности о передачи его – можно завуалировать очень сильно. Ну там адресат, время и тд.


Почему? Нужно провести эксперемент, у меня в период беглого знакомства со стеганографией как раз и получалось, что jpeg урезался до немогу. Пусть и с потерей качества, не обязательно ставить туда сверхкачественные фото. Гору в тумане или улицу в дождливую ночь и все – никто ничего не поймет. Тем же DarkJPEG. Просто если вставлять простой, пошифрованный текст – нужно же будет долго и нудно рассказывать собеседникам о том, что ему нужно сделать и как для дешифровки. А я подразумеваю то, что собеседники могут быть совсем далекими от ИТ, соответственно – скачали фото, запихнули ее в DarkJPEG, который залит по указанному заранее адресу и все.
Я к тому, что мне изначально понравились твои идеи и на счет маскировки gpg-переписки под тот же PDF и тд, что в моем понимании очень даже не плохо спасает от глобального наблюдателя, т.к. никто вручную не будет заголовки проверять. Но опять таки – это нужно либо автоматизировать как-то с обеих сторон, либо проводить ликбез, что муторно и порой просто невозможно.

— unknown (23/12/2014 17:53, исправлен 23/12/2014 17:55)   

Подразумевается, что одна сторона создаёт свой псевдонимный ключ, сообщает его отпечаток другой стороне, которая делает также в ответ. Затем, каждая сторона по мере надобности вешает новые УИДы с псевдокартинками для сообщений на свой ключ и периодически проверяет наличие новых УИД-овых картинок на ключе другой стороны. Всё это через Tor, чтобы не спалиться с принадлежностью ключа.


Само по себе появление на общедоступных серверах таких ключей с кучей картинок привлекает внимание, так что нет смысла там чего-то стеганографировать, лучше иметь возможность запихать больше текста в виде откровенно псевдорэндомных данных. А другой стороне можно выслать и скрипт для автоматизации этого всего на баше/питоне/etc.

— ressa (23/12/2014 17:57)   
Понял, спасибо.

Ссылки
[link1] http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/cipher/blowfish.c?rev=3753&view=markup

[link2] http://lists.gnupg.org/pipermail/gnupg-users/2005-November/027478.html

[link3] https://www.pgpru.com/comment4837

[link4] https://www.pgpru.com/comment5160

[link5] https://www.pgpru.com/comment7695

[link6] https://www.pgpru.com/comment4831

[link7] https://www.pgpru.com/comment4833

[link8] https://www.pgpru.com/comment47542

[link9] https://www.pgpru.com/comment4832

[link10] https://www.pgpru.com/proekt/poljzovateli?profile=sentaus

[link11] https://www.pgpru.com/biblioteka/rukovodstva/upravleniekljuchami/podkljuchiopenpgp

[link12] https://www.pgpru.com/comment39533

[link13] https://www.pgpru.com/proekt/osajjte/ecp

[link14] https://www.pgpru.com/comment71504

[link15] https://tools.ietf.org/html/rfc4880

[link16] https://www.pgpru.com/biblioteka/osnovy/vvedenievkripto/glava1/annulirovaniesertifikata

[link17] https://www.pgpru.com/comment77580

[link18] https://www.pgpru.com/comment85387

[link19] https://www.pgpru.com/novosti/2014/prostojjsposobsozdanijaneotslezhivaemyhkommunikacijj

[link20] https://www.pgpru.com/comment80997