Не пришло ли время отказаться от старых версий?
Ну да, лень-матушка – это всегда большая проблема. :)
Только с учетом этого:
http://www.pgpru.com/focus/hash_callas.htm
> пришло время, так сказать, упаковывать ящики.
стоило бы сделать это поскорее.
комментариев: 9796 документов: 488 редакций: 5664
Спокойно. без паники. Если бы в реальности появились и стали кем-то распространяться фальшивые ключи, то их бы уже какие-нибудь параноики обнаружили бы побайтовым сравнением или путем
вычисления хэш сумм по разным алгоритмам.
[ИМХО]
Отказываться от использования различных алгоритмов имеет смысл не тогда, когда уже начали проявляться явно болезненные симптомы, а хотя бы чуть-чуть раньше.
[/ИМХО]
комментариев: 9796 документов: 488 редакций: 5664
Я в принципе согласен, но ведь и "новое – это не всегда лучшее". Нельзя же просто так выкинуть из PGP алгоритмы SHA и MD5 и вставить туда WHIRLPOOL.
Ах да, я совсем забыл – есть же еще ГОСТ Р 34.11-94. :)
Но, кажется мы отвлекаемся в оффтопик.
Вот SHA-1 пока достаточно, имхо.
Все, заканчиваем. А то сейчас замочат :)
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Ну так и в PGP можно сделать нечто подобное (отчасти это уже реализовано).
В GnuPG создатель ключа может сам выбирать предпочитаемые алгоритмы.
Если он хочет использовать иной алгоритм хэширования на свой страх и риск – наверное можно будет предусмотретьи такую опцию. Но для массового решения нужен новый стандарт, а его принятие – долгий процесс.
комментариев: 11558 документов: 1036 редакций: 4118
Добавлено:
Правда вопроса со старыми ключами RSA v3 (MD5) всё это действительно не снимает. Впрочем, как и Unknown я не склонен полагать, что в ближайшее время стоит ожидать подделок. Я не думаю, что они вообще могут появятся до полного взлома MD5 и массового распространения ПО, осуществляющего вычислительную часть работы. Всё же RSA v3 применяются только в целях обратной совместимости, тогда как критические части инфраструктуры давно переведены на новый формат v4.
Кое-что, однако, вызывает тревогу. Автоматизированные системы, прежде всего, ремейлеры Type 1 (Cypherpunk), служба меток времени Stamper и некоторые другие используют движок PGP 2.x и по-прежнему применяют RSA v3. Принимая во внимание важность этих систем, в перспективе можно ожидать фальсификации ключей и подделку подписей.
Кстати – когда мы скачиваем с римэйлера статистику и ключи других римэйлеров, подлинность
этой информации ведь ничем не заверена? Есть ли такие узлы статистики, которые заверяли бы информацию хотя бы своей подписью, или давали ее скачать через SSL с самоподписанным сертификатом (чтобы было какое-то постоянство источника информации хотя бы с иллюзией его надежности)?
комментариев: 9796 документов: 488 редакций: 5664
Аутентифицирую, что это был я :)
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 8 документов: 2 редакций: 0
Боюсь соврать, но по-моему в DSS определена только хэш-функция SHA-1. Поэтому, скорей всего, это будет касаться только RSAv4 ключей.
P. S. Стас это я.
комментариев: 11558 документов: 1036 редакций: 4118
Базовый ключ подписания DSS служит не только для выработки цифровых подписей, но и для связывания всех элементов сертификата ключа, шифровальных подключей DH и т.д. Таким образом, взлом базового ключа подписания повлечёт не только угрозу подделки ЭЦП, но и угрозу подделки самих ключей и дешифрования сообщений.
Вообще стоит вспомнить, что главная причина создания этой каракатицы из ключа подписания по DSA и ключа шифрования по Эльгамалю была в патентном статусе RSA в начале-середине 90-х. (Даже сам тип ключа был парадоксально назван Diffie-Hellman/DSS, хотя не имел ничего общего с алгоритмом Диффи-Хеллмана, чем многие были введены в заблуждение. Проблема та же — патент на алгоритм Эльгамаля и ряд похожих схем.) Ныне же сложность в переходе на RSA v4 обусловлена, на мой взгляд, проблемами совместимости и наследования: многие продолжают использовать PGP 6.x и даже более ранние версии...
Кстати, я же уже говорил здесь, что RSAv4 ключи вполне работоспособны, по крайней мере, в 6.5.8, если размер их <=2048 бит. Такими должны быть как ключи подписания, так и ключи шифрования. Ключ подписания должен быть <=2048, и среди ключей шифрования должен быть хотя бы один <=2048.
комментариев: 8 документов: 2 редакций: 0
комментариев: 9796 документов: 488 редакций: 5664