Comments 24
Ну вот. И кому теперь можно доверять?
Эллиптике, там все кривые предрассчитаны и проверены. Хотя, дай, как грится, дураку хер стеклянный…
Эллиптику нужно использовать очень обдуманно и осторожно.
RSA не взломан, ему по-прежнему можно доверять, проблема с ключами — это как слабые пароли.
RSA не взломан, ему по-прежнему можно доверять, проблема с ключами — это как слабые пароли.
Это опаснее слабых паролей. Ибо слабый пароль можно увидеть «на глазок», а как заметить, что твой рандомайзер схалтурил и сгенерировал тебе слабый ключ?
очень просто — использовать для генерации ключей проверенные средства, которые дадут достаточную энтропию и правильно осуществят проверку простоты чисел. далеко ходить не нужно — openssl с этим отлично справляется.
Это понятно, но даже openSSL не застрахована от ошибок ( в реализациях они уже случались, вспомните случай когда добрые ребята из Debian удалили пару строк, не нравившихся Purify). Да и кто сможет гарантировать отсутствие фундаментальных жуков, способных предугадать «случайное» число?
добиться отсутствия жучков в данном случае помогут открытые исходные коды. мы живем в неидеальном мире — везде могут быть ошибки, между «шифровать с помощью openssl, который возможно содержит закладки» и «не шифровать» для меня выбор очевиден :)
рекомендация к использованию эллиптической криптографии в данном случае неуместна, т.к. если в случае с RSA нам нужен хороший random лишь один раз(схемы padding'а мы здесь не обсуждаем), при генерации ключей, и его можно проверить, то для эллиптики всё гораздо сложнее и мест для закладок там еще больше.
рекомендация к использованию эллиптической криптографии в данном случае неуместна, т.к. если в случае с RSA нам нужен хороший random лишь один раз(схемы padding'а мы здесь не обсуждаем), при генерации ключей, и его можно проверить, то для эллиптики всё гораздо сложнее и мест для закладок там еще больше.
Вроде бы стандарт RSA явно оговаривает требования к выбираемым параметрам. Получается, не все криптографическое ПО соответствует стандарту.
Теперь нужно выяснить, какими именно инструментами сгенерированы найденные слабые ключи.
Теперь нужно выяснить, какими именно инструментами сгенерированы найденные слабые ключи.
Кстати, PGP пишет в ascii-armored файлы ключей комментарий с версией, на которой он генерился.
GnuPG — аналогично.
Очень странно, почему этой информации нет в работе. Возможно, авторы решили не усугублять ситуацию называя «то-самое-уязвимое-ПО-с-кривым-ГПСЧ».
Или, быть может они резали все комментарии в ключах еще при сборе данных.
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGP 8.1GnuPG — аналогично.
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.17 (MingW32)Очень странно, почему этой информации нет в работе. Возможно, авторы решили не усугублять ситуацию называя «то-самое-уязвимое-ПО-с-кривым-ГПСЧ».
Или, быть может они резали все комментарии в ключах еще при сборе данных.
public ключи, очевидно, извлекались из ssl/https сертификатов, информации о ПО, которым сгенерированы ключи, они не содержат, разве что можно было сохранять баннеры сервисов и затем попытаться проанализировать.
Посмотрите, там только половина — SSL-cертификаты, все остальные — PGP-ключи. Вопрос остается открытым :)
Skipping a description of our attempts to agree on a sufficiently uniform and accessible repre-
sentation of the data, by November 2011 the counts had settled as follows: 6 185 372 distinct
X.509 certificates (most from the EFF SSL repository, 43 from other sources), and 5 481 332
PGP keys, for a total of at most 11 666 704 public keys.
А мне футболка понравилась.
Что-то я не понимаю. Откуда публичная экспонента 65535 взялась? это же не простое число?!
А можете объяснить почему на первой картинке они говорят что если есть ключи GH и JK, и появляется новый ключ GJ, то все три ключа становятся скомпрометированными?
Скажите, а с помощью вашего сервиса возможно ли открыть такой счет, который бы поддерживался PayPal на 100%?
Вам сюда — habrahabr.ru/company/payweb/blog/138408/
Sign up to leave a comment.
В среднем, 2 RSA ключа из 1000 уязвимы к взлому