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

Комментарии
— Гость (07/04/2010 08:18, исправлен 07/04/2010 09:49)   

Не любит административная http-прокси серверы ключей, поэтому пришлось взять отсюда[link1]. Однако, на этом сюрпризы не кончились:
Недолгое "вр". Отображаемый текст отличается от подписанного? Или это тонкий side-эффект от перекодировки из utf-8 в koi8-r? Очень странно. И почему сообщение о подписи есть в начале текста и в середине, хотя обычно идёт только в конце? Значит ли это, что не весь предоставляемый текст подписан ключом? Если да, то почему сайт показывает, что подписано якобы всё сообщение? Вот ещё для диагностики:

— Гость (07/04/2010 08:27, исправлен 07/04/2010 09:50)   
И почему сообщение о подписи есть в начале текста и в середине, хотя обычно идёт только в конце?

Имелась в виду вот эта команда (хотя, вероятно, это тонкий эффект на пайпах):

— unknown (07/04/2010 09:48, исправлен 07/04/2010 10:10)   

Выкладывалось именно через тот самый http-proxy, но есть дополнительные хитрости: опции broken-http-proxy и принудительный таймаут на 10 мин.


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


М. б. команда называется iconv?


При её работе действительно возникали глюки при перекодировании именно при работе с utf-8.


Судя по тому, что сообщение "перебивает текст", возможно сначала gnupg проверяет RSA-подпись подлюча ID 42065DBD и только спустя время успевает сверить правильность того, что этот подключ правильно подписан основным ключом 4BD12C40.


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


Представляю, какие будут глюки при использовании DSA-3, если ещё UTF-8 плохо обрабатывается во многих системах и утилитах :-(


P. S. вырезайте собаку из мэйлов.

— Гость (12/04/2010 00:09)   
Выкладывалось именно через тот самый http-proxy, но есть дополнительные хитрости: опции broken-http-proxy и принудительный таймаут на 10 мин.
У меня когда-то работало и без хитростей. Выше был тест без Tor'а, вот с Tor'ом:
С опциями играться пока лениво.

М. б. команда называется iconv?
Да, конечно, просто когда правил алиасы в командах на общепринятые, ошибся :=)

Кстати, настоятельно рекомендую при расшифровке текста в консоли перенаправлять его в файл и затем смотреть просмотрщиком (достаточно через less), чтобы от кого-нибудь не пришли какие-нибудь странные комбинации символов, которые случайно или намеренно портят вывод команды. Т.е. при отдельном просмотре начала вывода, а затем текста таких глюков быть не должно
Тогда глюк "исчезнет", т.к. текст самого сообщения и проверка подписи идут в разные потоки. Можно было бы воспользоваться стандартным трюком с перенаправлением потоков типа 1>&2 2>/path/to/file, но там в команде 2 пайпа, и эффект в консольном выводе, видимо, возникает из-за того, что часть попадает от 1го пайпа, а часть от второго, в то время как перенаправление работает только с текущим потоком. Можно поиграться поставив перенаправления на обоих потоках, но уже лениво.

P. S. вырезайте собаку из мэйлов.
Извиняюсь, не подумал.
— unknown (12/04/2010 13:01)   
— Гость (12/04/2010 20:07)   
На 8118 – privoxy, которая непосредственно смотрит в инет (Tor'а нет), при этом авторизация на административной http-прокси происходит методом Basic путём включения в файл user.action строчки
где строка X... X получается командой
(В Linux-консли надо как-то по-другому вычислять X... X). В настройках браузера при этом прописывается IP:порт для http и https-проксей. Короче, пространство для программы "почему не работать" широкое, но в целом большая часть программ дружат с такой настройкой.
— Гость (23/09/2013 12:41)   

Заметил, что в вашей связке был временный RSA-подключ для подписи, созданный на несколько месяцев. К чему бы это?
— unknown (23/09/2013 15:05, исправлен 23/09/2013 15:07)   

Я и сам не помню :) Одно время была идея регулярно использовать кратковременные подключи, чтобы гипотетический противник мог успевать поломать только главный ключ, которым подписываются подключи, что для него было бы более заметно и менее применимо в попытках вмешаться в переписку.

— Гость (23/09/2013 18:04)   
Unknown, а чем обусловлен ваш выбор для главного сертифицирующего ключа? Почему именно DSA, а не RSA? Чем, по-вашему, RSA-4096 хуже для подписи?
— Гость (23/09/2013 18:15)   

Хм... каскад перестраховочная криптография?? ;)
— SATtva (23/09/2013 18:18)   
Время жизни ключа — общепринятый, легко формализуемый параметр.
— unknown (24/09/2013 10:26, исправлен 24/09/2013 10:27)   

Я где-то здесь уже отвечал, что выбрал тот вариант, который хуже и не советовал мой выбор повторять.
На тот момент в стабильной ветке Debian в GnuPG не было поддержки RSA-4096 для подписи главного ключа, а поддержка DSA-3072 и больших хэшей SHA-2 уже была. Хотя, может были ещё какие проблемы, уже не помню.

— Гость (25/09/2013 00:22)   

А если бы такой ключ был сгенерирован на другой системе и импортирован в Debian, GnuPG поняло бы его? Если сделать все три ключа (главный [C], подключ шифрования [E] и подключ подписи [S]) типом RSA-4096, насколько вероятно возникновение несовместимости с немного устаревшими версиями GnuPG (ну там года 3 назад вышедшими)? Они будут мой ключ понимать?
— SATtva (25/09/2013 10:16)   
Будут. Сомневаюсь, что проблемы возникнут даже с версиями 5-8-летней давности.
— Гость (18/10/2013 18:25)   

Кажется, я когда-то видел на сайте статью с рекомендациями по выбору типов ключей, но не могу нагуглить. Часть аргументов уже озвучивалась и разобросана по сайту, но было бы удобно, если б кто-то составил таблицу плюсов и минусов каждого алгоритма. Например, RSA проще в реализации (а поэтому меньше вероятность ошибки) и более стоек при уязвимых ГСЧ, но уязвим к реализации паддинга. DSA сразу был свободным, в отличие от RSA, но уязвим к плохому ГСЧ, что теоретически позволяет восстановить приватный ключ. Т.е. какие-то такие аргументы хотелось бы увидеть, особенно с учётом последних новостей[link2].

Как-то возник разговор на тему Elgamal vs RSA для шифрования. Аргументы против RSA были:
  1. Алгоритм был когда-то запатентован, поэтому не так хорошо анализировался сообществом, Elgamal же появился как свободный сразу.
  2. Доказано, что Elgamal не слабее RSA. Обратное не доказано (речь о сводимости одной трудной задачи к другой).
  3. Сложность реализации RSA и Elgamal примерно одинаковая.
  4. DSA+Elgamal долгое время были дефолтным выбором в GnuPG при генерации ключей.
  5. Асимметрика на дискретном логарифме появилась лишь чуть-чуть позже RSA, поэтому нельзя сказать, что дискретный алгоритм сильно хуже проанализирован сообществом.

Насколько эти аргументы ошибочные? Есть ли какие-то веские аргументы в пользу выбора RSA для шифрования?
— unknown (19/10/2013 13:10)   

  1. Звучит как хорошая шутка! RSA настолько легендарный с самого начала, что большинство исследований велось по нему. Какая разница, запатентован он или нет? Это для симметричных алгоритмов сдерживающий фактор для исследователей, потому что их можно много наизобретать. Одним меньше, одним больше, вот и анализируют больше непатентованные. RSA — это одно из фундаментальных открытий, один из двух истоков асимметричной криптографии.
  2. Не могу всерьёз комментировать эти доказательства.
  3. RSA — всегда проще всех. В DH-based алгоритмах не сразу дошли, какие лучше выбирать параметры группы.
  4. Из-за патентных ограничений RSA действительно много где не использовался. Но он всё равно достаточно хорошо изучен для реализации.
  5. С параметрами выбора группы сначала были непонятки, но этот вопрос давно решён. Вообще, первая ассиметрика на дискретном алгоритме — это собственно протокол совместного вывода ключа по Диффи-Хеллману, который появился чуть раньше RSA.

RSA сейчас лучше изучен и методы решения факторизации изучаются активнее, чем решение проблемы дискретного логарифмирования, хотя примерно одинаково всё равно. При прочих равных лучше выбрать RSA, поскольку он чуть проще в реализации.
— Гость (19/10/2013 21:19)   
Спасибо! Мои аргументы были похожими, хоть я и не специалист. Чисто интуитивное впечатление из практики: в любой, хоть как-то связанной с криптографией книгой или диссертацией, обязательно будет упомянут RSA. Дисерктный логарифм, в лучшем случае, бывает упомянут, но иногда и этого нет, а про ECC в неспециализированной литературе вообще тотальный молчок.
— unknown (19/03/2014 10:44, исправлен 19/03/2014 10:44)   

Ещё 8 марта продлил свой главный ключ до 2018 и добавил парочку подключей сроком до 2015, закачал на серверы.


Смотрю сюда[link3].


Там предлагается keyserver.rayservers.com, на котором уже спустя 11 дней так ничего и не обновилось[link4], зато на pool.sks-keyservers.net всё в порядке[link5].

— Гость (19/03/2014 18:46)   

Ага, ещё вчера видел этот подарок к неслучайно выбранному дню. :)

Ссылки
[link1] http://www.pgpru.com/servisy/keyserver

[link2] http://www.pgpru.com/biblioteka/statji/securityagainstnsa

[link3] https://www.pgpru.com/servisy/keyserver

[link4] http://keyserver.rayservers.com:11371/pks/lookup?search=0x80585959&op=vindex

[link5] http://pool.sks-keyservers.net/pks/lookup?search=0x80585959&fingerprint=on&hash=on&op=vindex