2010-07-26 истекает неоднократно продлеваемый срок действия моего "красно-коричневого" ключа 4BD12C40.
Не дожидаясь этой даты в ближайшее время мой ключ на форуме будет 80585959, а цвет отображения выходит фиолетово-серый :)
Полный отпечаток:
EE1E 6772 92A7 F9F1 F1DE 326B 9153 691B 8058 5959
Можно скачать с серверов.
Ключ основной подписи в формате OpenPGP DSA3 3072 бита, вполне согласуется с рекомендациями криптографов вывести 1024-битные ключи из обращения в 2010 году.
Подписи сообщений будут использовать хэш SHA-512.
В выборе такого ключа есть некоторая избыточность в ущерб совместимости и возможным багами в реализации нововведений, это больше подходит для экспериментов.
Пока дата действия ключа до 2012-03-06, дальше будет продлеваться по мере надобности, но поскольку ожидается внедрение массы новых стандартов на хэши, асимметрику и пр., то возможно и этот ключ будет действителен недолгое время.
Не любит административная http-прокси серверы ключей, поэтому пришлось взять отсюда. Однако, на этом сюрпризы не кончились:
Недолгое "вр". Отображаемый текст отличается от подписанного? Или это тонкий side-эффект от перекодировки из utf-8 в koi8-r? Очень странно. И почему сообщение о подписи есть в начале текста и в середине, хотя обычно идёт только в конце? Значит ли это, что не весь предоставляемый текст подписан ключом? Если да, то почему сайт показывает, что подписано якобы всё сообщение? Вот ещё для диагностики:
Имелась в виду вот эта команда (хотя, вероятно, это тонкий эффект на пайпах):
комментариев: 9796 документов: 488 редакций: 5664
Выкладывалось именно через тот самый http-proxy, но есть дополнительные хитрости: опции broken-http-proxy и принудительный таймаут на 10 мин.
Там не подписан только заголовок темы, но при сохранении файла это видно как отдельный текст перед подписью. При отображении сообщения в форуме этот заголовок и не появляется.
М. б. команда называется iconv?
При её работе действительно возникали глюки при перекодировании именно при работе с utf-8.
Судя по тому, что сообщение "перебивает текст", возможно сначала gnupg проверяет RSA-подпись подлюча ID 42065DBD и только спустя время успевает сверить правильность того, что этот подключ правильно подписан основным ключом 4BD12C40.
Кстати, настоятельно рекомендую при расшифровке текста в консоли перенаправлять его в файл и затем смотреть просмотрщиком (достаточно через less), чтобы от кого-нибудь не пришли какие-нибудь странные комбинации символов, которые случайно или намеренно портят вывод команды. Т.е. при отдельном просмотре начала вывода, а затем текста таких глюков быть не должно и будете уверены, что не задействована какая-нибудь неизвестная уязвимость с хитрым форматированием. Хотя возможно неудобно два раза набирать несколько разные команды.
Представляю, какие будут глюки при использовании DSA-3, если ещё UTF-8 плохо обрабатывается во многих системах и утилитах :-(
P. S. вырезайте собаку из мэйлов.
С опциями играться пока лениво.
Да, конечно, просто когда правил алиасы в командах на общепринятые, ошибся :=)
Тогда глюк "исчезнет", т.к. текст самого сообщения и проверка подписи идут в разные потоки. Можно было бы воспользоваться стандартным трюком с перенаправлением потоков типа 1>&2 2>/path/to/file, но там в команде 2 пайпа, и эффект в консольном выводе, видимо, возникает из-за того, что часть попадает от 1го пайпа, а часть от второго, в то время как перенаправление работает только с текущим потоком. Можно поиграться поставив перенаправления на обоих потоках, но уже лениво.
Извиняюсь, не подумал.
комментариев: 9796 документов: 488 редакций: 5664
где строка X... X получается командой
(В Linux-консли надо как-то по-другому вычислять X... X). В настройках браузера при этом прописывается IP:порт для http и https-проксей. Короче, пространство для программы "почему не работать" широкое, но в целом большая часть программ дружат с такой настройкой.
Заметил, что в вашей связке был временный RSA-подключ для подписи, созданный на несколько месяцев. К чему бы это?
комментариев: 9796 документов: 488 редакций: 5664
Я и сам не помню :) Одно время была идея регулярно использовать кратковременные подключи, чтобы гипотетический противник мог успевать поломать только главный ключ, которым подписываются подключи, что для него было бы более заметно и менее применимо в попытках вмешаться в переписку.
Хм...
каскадперестраховочная криптография?? ;)комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Я где-то здесь уже отвечал, что выбрал тот вариант, который хуже и не советовал мой выбор повторять.
На тот момент в стабильной ветке Debian в GnuPG не было поддержки RSA-4096 для подписи главного ключа, а поддержка DSA-3072 и больших хэшей SHA-2 уже была. Хотя, может были ещё какие проблемы, уже не помню.
А если бы такой ключ был сгенерирован на другой системе и импортирован в Debian, GnuPG поняло бы его? Если сделать все три ключа (главный [C], подключ шифрования [E] и подключ подписи [S]) типом RSA-4096, насколько вероятно возникновение несовместимости с немного устаревшими версиями GnuPG (ну там года 3 назад вышедшими)? Они будут мой ключ понимать?
комментариев: 11558 документов: 1036 редакций: 4118
Кажется, я когда-то видел на сайте статью с рекомендациями по выбору типов ключей, но не могу нагуглить. Часть аргументов уже озвучивалась и разобросана по сайту, но было бы удобно, если б кто-то составил таблицу плюсов и минусов каждого алгоритма. Например, RSA проще в реализации (а поэтому меньше вероятность ошибки) и более стоек при уязвимых ГСЧ, но уязвим к реализации паддинга. DSA сразу был свободным, в отличие от RSA, но уязвим к плохому ГСЧ, что теоретически позволяет восстановить приватный ключ. Т.е. какие-то такие аргументы хотелось бы увидеть, особенно с учётом последних новостей.
Как-то возник разговор на тему Elgamal vs RSA для шифрования. Аргументы против RSA были:
Насколько эти аргументы ошибочные? Есть ли какие-то веские аргументы в пользу выбора RSA для шифрования?