Типы ключей
Здравствуйте!
Из консоли 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 без «расширения»?
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 11558 документов: 1036 редакций: 4118
Спасибо за пояснение.
Как я понимаю, если кому-то из абонентов сильно хочется, используя дополнительные экспертные опции, он зашифрует что-нибудь нужным подключом независимо от того, устарел ли он или отозван.
комментариев: 11558 документов: 1036 редакций: 4118
Без понятия. Вероятно, связано с пересчётом значений в trust DB.
Айдишник тот самый.
По идее, он не должен использоваться ни для чего. Попробуйте зашифровать что-нибудь данным подключом, чтобы проверить:
комментариев: 11558 документов: 1036 редакций: 4118
Expired-состояние может быть обойдено случайно, если у пользователя некорректно настроены системные часы. Однако я не помню, как GnuPG реагирует на наличие сертификата отзыва, подписанного в будущем. Если метка времени не проверяется, а проверяется только подпись, то случайно использовать такой ключ не удастся даже при сбитом таймере.
Как правило, именно так:
Запретить это принципиально Вы, конечно, не можете.
комментариев: 9796 документов: 488 редакций: 5664
Для подписи и шифрования было бы SE, хотя такое не всегда возможно или не рекомендуется. Существование ключей без свойств — загадка. Вот если бы к ним можно было позднее приклеить свойства, в этом был бы смысл, как в неком зарезервированном на будущее подключе.
В общем-то да, но получатель имеет право относится к такому сообщению с подозрением, да и отправитель не может быть уверенным, что такое сообщение будет вообще прочитано получателем. Получатель может удалять просроченные закрытые подключи со своей ключевой связки. А так, да, обычно или продлевают срок действия или не трогают по его истечении.
Делать явный отзыв имеет смысл для главного сертифицирующего ключа, когда создаётся новая связка ключей. Тогда в старую прописывают UID главного ключа новой связки для уведомления и делают revoke старой, чтобы не было искушения продлить её действие.
Над остальными вопросами стоит подумать.
А можно отозвать за день до истечения срока, например. Если хочется сделать резкую границу для перехода на новые подключи, чтобы не ждать секунда-в-секунду точного истечения срока старых, проще добавить новые подключи и отозвать старые. Точнее, как только абонент обновит связку, он сразу начнёт шифровать самыми свежими подключами, но я при пользовании автоматическими программами не увижу, обновил ли кто-либо или ещё нет, пока не истечёт срок подключей (считаем, что никто не будет принудительно шифровать устаревшими или отозванными подключами). Если же на моей связке я отозвал старые подключи до срока их действия, и кто-то ими что-то зашифровал, GnuPG сразу начнёт ругаться, как я понимаю. Т.е. вероятность заметить проблему, что кто-то вовремя не обновил ключ, выше. Впрочем, это всё имеет смысл только для короткого промежутка времени между созданием новых подключей и устареванием старых.
Проверил:
Если мне напишут сообщение, зашифровав его отозванным ключом/подключом, я смогу его расшифровать (возможно, указав gpg дополнительные опции)?
И ещё такой вопрос: можно ли «разотозвать» ключ при условии, что он никуда в интернет не загружался, а сертификат отзыва был загружен только на локальную связку (чистой копии связки с неотозванной версией ключа нет)? Судя по тому, что все операции с ключом — навешивание дополнительных подписей, это должно делаться, но я не знаю, можно ли это сделать встроенными средствами gpg.
комментариев: 11558 документов: 1036 редакций: 4118
В экспертном режиме, кажется, да.
Некогда перепроверять, но штатной функции вроде бы нет (поправьте, если неправ). Т.е. единственный вариант — разбивать ключ на пакеты, выкидывать сертификат отзыва и склеивать обратно.
комментариев: 9796 документов: 488 редакций: 5664
Вот подумалось, помимо индекса, размер ключа — странный! 211 = 2048, 211 + 28 = 2304, 211 + 29 = 2560, 211 + 210 = 3072, 212 = 4096; а 2432 для индекса "R" — это как? Этот ключ единственный для GnuPG-RSA с таким невозможным размером, только у этого Гиллмора он и есть.
Может это вообще не подключ? Можно ли в GnuPG хитрым образом повесить на связку под видом ключа некий произвольный бинарник, пусть и с левым заголовком? Так можно было бы что-то бэкапить или передавать короткие сообщения.
Конечно, в текстовом виде можно вроде как пару килобайт запихать и в UID, но некрасиво — такой UID будет загромождать отображение ключа при работе в консоли. А в бинарном виде, да ещё и под видом подключа, было бы совсем замечательно.