id: Гость   вход   регистрация
текущее время 01:53 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 След.
Комментарии
— Гость (29/09/2013 11:48)   <#>
А другие реализации допускают? Например, коммерческое PGP.
— SATtva (29/09/2013 12:00)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
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)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Такой команды нет, разработчики явно не рассчитывали, что кто-то станет генерировать подключи пачками и распространять ключ в обход серверов ключей. Пишите 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»? Сам термин понятен, но что именно имелось в виду?

  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, который появился в самых последних версиях?

  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)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Что значит «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)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Хочется дать понять всем, что конкретные подключи более не будут использоваться ни при каких обстоятельствах. Достаточно ли для этого их просто не обновлять, и пусть они висят на связке как «expired», или лучше принудительно отзывать их перед истечением срока действия?

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

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

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


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

Запретить это принципиально Вы, конечно, не можете.
— unknown (19/03/2014 10:15)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Третий подключ не имеет типа «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)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Если мне напишут сообщение, зашифровав его отозванным ключом/подключом, я смогу его расшифровать (возможно, указав gpg дополнительные опции)?

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

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

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

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


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


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

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