Scratch 17 фев 2012 в 14:23

В среднем, 2 RSA ключа из 1000 уязвимы к взлому

1 мин

3.4K

Информационная безопасность*

+37

Комментарии 24

frig 17 фев 2012 в 14:54

Ну вот. И кому теперь можно доверять?

Scratch 17 фев 2012 в 14:56

Эллиптике, там все кривые предрассчитаны и проверены. Хотя, дай, как грится, дураку хер стеклянный…

kyprizel 17 фев 2012 в 16:07

Эллиптику нужно использовать очень обдуманно и осторожно.
RSA не взломан, ему по-прежнему можно доверять, проблема с ключами — это как слабые пароли.

f_s_b_37 17 фев 2012 в 16:23

Это опаснее слабых паролей. Ибо слабый пароль можно увидеть «на глазок», а как заметить, что твой рандомайзер схалтурил и сгенерировал тебе слабый ключ?

kyprizel 17 фев 2012 в 17:27

очень просто — использовать для генерации ключей проверенные средства, которые дадут достаточную энтропию и правильно осуществят проверку простоты чисел. далеко ходить не нужно — openssl с этим отлично справляется.

f_s_b_37 17 фев 2012 в 17:39

Это понятно, но даже openSSL не застрахована от ошибок ( в реализациях они уже случались, вспомните случай когда добрые ребята из Debian удалили пару строк, не нравившихся Purify). Да и кто сможет гарантировать отсутствие фундаментальных жуков, способных предугадать «случайное» число?

kyprizel 17 фев 2012 в 18:17

добиться отсутствия жучков в данном случае помогут открытые исходные коды. мы живем в неидеальном мире — везде могут быть ошибки, между «шифровать с помощью openssl, который возможно содержит закладки» и «не шифровать» для меня выбор очевиден :)
рекомендация к использованию эллиптической криптографии в данном случае неуместна, т.к. если в случае с RSA нам нужен хороший random лишь один раз(схемы padding'а мы здесь не обсуждаем), при генерации ключей, и его можно проверить, то для эллиптики всё гораздо сложнее и мест для закладок там еще больше.

Ocelot 17 фев 2012 в 14:54

Вроде бы стандарт RSA явно оговаривает требования к выбираемым параметрам. Получается, не все криптографическое ПО соответствует стандарту.
Теперь нужно выяснить, какими именно инструментами сгенерированы найденные слабые ключи.

+12

ntkt 17 фев 2012 в 21:49

Кстати, PGP пишет в ascii-armored файлы ключей комментарий с версией, на которой он генерился.

-----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGP 8.1

GnuPG — аналогично.

-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (MingW32)

Очень странно, почему этой информации нет в работе. Возможно, авторы решили не усугублять ситуацию называя «то-самое-уязвимое-ПО-с-кривым-ГПСЧ».
Или, быть может они резали все комментарии в ключах еще при сборе данных.

kyprizel 18 фев 2012 в 00:13

public ключи, очевидно, извлекались из ssl/https сертификатов, информации о ПО, которым сгенерированы ключи, они не содержат, разве что можно было сохранять баннеры сервисов и затем попытаться проанализировать.

ntkt 18 фев 2012 в 10:18

Посмотрите, там только половина — SSL-cертификаты, все остальные — PGP-ключи. Вопрос остается открытым :)

Skipping a description of our attempts to agree on a suﬃciently uniform and accessible repre-
sentation of the data, by November 2011 the counts had settled as follows: 6 185 372 distinct
X.509 certiﬁcates (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.

postgree 17 фев 2012 в 15:33

А мне футболка понравилась.

datacompboy 17 фев 2012 в 16:06

Что-то я не понимаю. Откуда публичная экспонента 65535 взялась? это же не простое число?!

datacompboy 17 фев 2012 в 16:19

А вообще спасибо, интересное чтиво. Закон больших чисел в действии…

HeadFore 17 фев 2012 в 16:51

Именно поэтому не 65535, а 65537.

datacompboy 17 фев 2012 в 16:54

в PDF загляните. 65537 — подавляющее большинство, но в топ попало и 65535. отчего и рисую O_O

hellman 17 фев 2012 в 17:28

Вообще говоря, достаточно чтобы публичная экспонента была взаимно простой с fi.

tulskiy 17 фев 2012 в 17:56

А можете объяснить почему на первой картинке они говорят что если есть ключи GH и JK, и появляется новый ключ GJ, то все три ключа становятся скомпрометированными?