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

    Команда европейских и американских математиков проанализировала свыше 11 000 000 сертификатов, принадлежащих различным сайтам и обнаружила, что в среднем на тысячу из них приходится около 2х со слабыми параметрами, позволяющими восстановить секретный ключ.


    Мало того, что у многих из них модули(N) были одинаковыми, у малой части открытых ключей модули RSA позволяли себя факторизовать за минимальное время.

    Дока очень объемная и на английском, поэтому интересующиеся приглашаются к самостоятельному увлекательному чтению.

    Предваряя вопросы «а как проверить?»
    Авторы судя по всему хотели сделать паблик сервис по проверке, но побоялись что это может навредить компаниям, если уязвимый ключ проверят левые люди раньше них самих. По их идее, знающим людям не составит труда написать такую тулзу самостоятельно после прочтения доклада.

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 24

      0
      Ну вот. И кому теперь можно доверять?
        +1
        Эллиптике, там все кривые предрассчитаны и проверены. Хотя, дай, как грится, дураку хер стеклянный…
          +2
          Эллиптику нужно использовать очень обдуманно и осторожно.
          RSA не взломан, ему по-прежнему можно доверять, проблема с ключами — это как слабые пароли.
            +4
            Это опаснее слабых паролей. Ибо слабый пароль можно увидеть «на глазок», а как заметить, что твой рандомайзер схалтурил и сгенерировал тебе слабый ключ?
              +1
              очень просто — использовать для генерации ключей проверенные средства, которые дадут достаточную энтропию и правильно осуществят проверку простоты чисел. далеко ходить не нужно — openssl с этим отлично справляется.
                0
                Это понятно, но даже openSSL не застрахована от ошибок ( в реализациях они уже случались, вспомните случай когда добрые ребята из Debian удалили пару строк, не нравившихся Purify). Да и кто сможет гарантировать отсутствие фундаментальных жуков, способных предугадать «случайное» число?
                  0
                  добиться отсутствия жучков в данном случае помогут открытые исходные коды. мы живем в неидеальном мире — везде могут быть ошибки, между «шифровать с помощью openssl, который возможно содержит закладки» и «не шифровать» для меня выбор очевиден :)
                  рекомендация к использованию эллиптической криптографии в данном случае неуместна, т.к. если в случае с RSA нам нужен хороший random лишь один раз(схемы padding'а мы здесь не обсуждаем), при генерации ключей, и его можно проверить, то для эллиптики всё гораздо сложнее и мест для закладок там еще больше.
        +12
        Вроде бы стандарт RSA явно оговаривает требования к выбираемым параметрам. Получается, не все криптографическое ПО соответствует стандарту.
        Теперь нужно выяснить, какими именно инструментами сгенерированы найденные слабые ключи.
          +2
          Кстати, PGP пишет в ascii-armored файлы ключей комментарий с версией, на которой он генерился.
          -----BEGIN PGP PUBLIC KEY BLOCK-----
          Version: PGP 8.1


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

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


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

            0
            public ключи, очевидно, извлекались из ssl/https сертификатов, информации о ПО, которым сгенерированы ключи, они не содержат, разве что можно было сохранять баннеры сервисов и затем попытаться проанализировать.
              0
              Посмотрите, там только половина — 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.
          +8
          А мне футболка понравилась.
            +1
            Что-то я не понимаю. Откуда публичная экспонента 65535 взялась? это же не простое число?!
              0
              А вообще спасибо, интересное чтиво. Закон больших чисел в действии…
                0
                Именно поэтому не 65535, а 65537.
                  +1
                  в PDF загляните. 65537 — подавляющее большинство, но в топ попало и 65535. отчего и рисую O_O
                  +1
                  Вообще говоря, достаточно чтобы публичная экспонента была взаимно простой с fi.
                  0
                  А можете объяснить почему на первой картинке они говорят что если есть ключи GH и JK, и появляется новый ключ GJ, то все три ключа становятся скомпрометированными?
                    +1
                    gcd(GH, GJ) = G
                    GH / G = H
                    GJ / G = J
                    JK / J = K
                    В итоге знаем все простые составляющие и запросто генерируем приватные ключи.
                    –2
                    Кто желает может проверить свои ключики на уязвимость

                    P.S. Бага ещё 2006 года
                      +2
                      Читайте статью, эти ключи как раз были исключены из исследования.
                      0
                      Скажите, а с помощью вашего сервиса возможно ли открыть такой счет, который бы поддерживался PayPal на 100%?

                    Only users with full accounts can post comments. Log in, please.