использование очень длинных ассиметричных ключей в ssh

    Привет, $username. Если вы примерно такой же криптоманьяк, что и я, то наверняка не ограничитесь регенерацией /etc/ssh/moduli, и вам захочется большего. Например, использовать для авторизации dsa-ключи длиннее 1024iB. Но проблема в том, что ssh-keygen из пакета OpenSSH, которым вооружено большинство UNIX'оидов, не хочет генерировать такие ключи. Причина такого поведения непонятна, man'ы отыслают на документ FIPS 186-2, в котором ничего толком не сказано, и ссылок на толковые объяснение сего ограничения нет. Поэтому, причин не попробовать понаступать на всякие криптограбли с длинными dsa-ключами нет. Осталось только сгенерировать такой ключ. Сделать это просто, но если не хочется тратить время на всякие ковырялки, то с методом можно ознакомиться под hubracut'ом



    В этом деле поможет openssl. Сначала генерируем параметры для dsa-ключей.

    openssl dsaparam -out parameters.pem 4096

    Если, кто-то не знает, то 4096 — это желаемая длина ключей (в битах), которые будут генерироваться при помощи этих параметров, а сами параметры будут записаны (естественно) в файл parameters.pem, который представляет из себя закодированную при помощи base64 двоичную структуру, и снабжённый некой шапкой и антишапкой — всё в соответствии со стандартом PEM (Privacy-enhanced Electronic Mail). Сами же параметры DSA представляют собой три числа. Подробности есть в en.wikipedia.org/wiki/DSA

    После того, как сгенерированы параметры, можно генерировать ключ (если, конечно, дождётесь окончания генерации параметров :) а вообще, если вдруг решите это запускать на сотовом телефоне, то запаситесь книгой 'Идеальный Код' — отличный сбоник отличных эссе):

    openssl dsa -out key.pem parameters.pem

    Этот ключ представляет собой, на деле, два ключа — открытый и закрытый. Если не верите, можете сами посмотреть:

    openssl dsa -noout -text < key.pem

    Теоретически, вы должны увидеть свои DSA-параметры и два небольших числа pub и priv, которые, на самом деле, и будут ключами.

    Теперь нужно сделать три дела: (1) объявить созданный ключ вашей(им) identity, (2) вытащить из него в воспринимаемом openssh формате открытый ключ, (3) засунуть этот открытый ключ на целевую машину в authorized_keys. (2) и (3) будут смешаны в одной pipeline.

    mv key.pem /home/username/.ssh/identity
    chown 600 /home/username/.ssh/identity


    поменять права доступа нужно обязательно, ведь, openssh — штука разборчивая, ведь, сам TrueЪ Тео де Раадт проектом руководил;

    ssh-keygen -y -f /home/username/.ssh/identity | ssh username@somehost.ssh tee -a .ssh/authorized_keys

    Готово. Можно теперь оставить для ssh аутентификацию только по ассиметричным ключам, и идти спокойно играть в шахматы не опасаясь весеннего обострения у латвио-индо-китае-русских хакеров.

    P.S. Конечно, пользователи PuTTY могут спокойно генерировать длинные DSA-ключи puttygen'ом, но проблема в том, что puttygen для каждого нового DSA-ключа генерирует новые параметры, что напрочь убивает всё приемущество DSA над RSA, которое как раз и состоит (если не брать в расчёт возможность считать на эллиптических кривых) в скорости генерации новых ключей.

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      –1
      Скоро вместо вместо ключей будут видео передавать, размер «ключа» будет что надо.
        +2
        Ну, во-первых. /etc/ssh/moduli используется в SSH-протоколе для Diffie-Hellman key exchange, и ничего общего с DSA-ключем сервера не имеет.
        Во-вторых, FIPS 186-2 все четко и понятно обьясняет. В DSA ключе грубо говоря есть два параметра — один, который имеет размер тех самых 1024 бит, и второй, который имеет фиксированый размер 160 бит (= размер хеша SHA1). И от обеих параметров зависит безопасность схемы. Когда размер первого параметра больше 1024 бит, фиксированый размер второго параметра становится «более слабым звеном», и дальнейшее увеличение размера первого параметра становится бессмысленным, только время вычислений увеличивается.
        Ну и насчет преимущества RSA над DSA — на деле, общие параметры в DSA практически нигде не используются, и всегда генерируются заново.
          +3
          Более того, бездумное увеличение длины ключей, как ни странно, УВЕЛИЧИВАЕТ восприимчивость алгоритма к некоторым видам атак (как правило, основанным на деталях реализации алгоритма). Вот неплохая презенташка, иллюстрирующая это:

          www.comodo.com/research/crypto/CDW_SAC_03.ppt

          Впрочем, насколько я помню, уже готовится FIPS 186-3, который допускает более длинные ключи. Видимо, он учитывает тот факт, что на более современных компьютерах уже более сложно «поймать» всякие разницы во времени между операциями умножения и возведения в степень, и т.п.
            0
            FIPS-186-3 уже в финальной стадии, но вроде действительно еще в качестве стандарта его не приняли.
            В основном он ориентирован на использование ECDSA (DSA на эллиптических кривых), но также описывает использование SHA-2 с DSA, благодаря чему размер ключа увеличивается до 4096 бит (с соответствующим увеличением параметра Q до 224...256..384..512 бит, а используемого хеш-алгритма — до SHA256..SHA512). Это уже используется в PGP, есть какие-то драфты по использованию этого в PKI, может еще где.
            0
            А где было сказано, что moduli вообще к ключам отношение имеет? И вот механизм того, почему короткий параметр становится 'более слабым звеном' совсем не понятен, скорее уж от увеличения длины стойкость не увеличивается. Долгое же время вычислений это, скорее, плюс. Потому что осуществлять атаку сложнее. Атаки же по вычислительной сложности (как по ссылке ниже), imho, иррелевантны. Их нужно проводить в идеальных условиях, когда на машине единственным работающим процессом является криптодвижок.

            DSA vs. RSA: Вообще, тогда можно сказать, что и DSA практически нигде не используется. Но вот в личных целях, когда есть много машин, и много пользователей, работающих с ними по ssh, при том, что новые пользователи довольно часто приходят, DSA удобнее.
              0
              Интересно, какой же плюс представляет собой долгое время вычисления? Чем сложнее осуществлять атаку??
                0
                Чем больше p, тем больше чисел вида g^k (mod p), дающих одинаковые модули по основанию q. А, если ломать, например, электронную подпись, то для восстановления приватного ключа x, k нужно знать точно. Увеличивается пространство для поиска для нужного варианта. Или я не прав?
                  0
                  Вы были бы правы, если бы тупой поиск g был единственно возможной атакой на алгоритм. При увеличении p сложность других видов атак (на ту же хеш функцию например) становится относительно проще, и общая стойкость системы (которая есть минимальная стойкость всех компонентов, грубо говоря) не увеличивается.
                    0
                    Хм. Вот не понятно, почему проще. У вас есть какие-нибудь ссылки на рассуждения? Хэш-функция же в вычислениях учавствует только по модулю q (это который 160iB, чтобы под SHA1 подходил). Увеличение же пространства возможных решений, imho, всё же усложняет поиск ответа.
                      0
                      Почитайте теорию, тот же FIPS. Есть обобщенное понятие «bits of security», которое позволяет примерно сравнить «стойкость» разных алгоритмов. Ну в конце концов не просто так же они в официальном документа ограничили размер P?
                        0
                        Так. В том-то и проблема, что нигде не могу найти обоснования. В той же Applied Cryptography просто стоит ссылка на тот же FIPS. А в FIPS написано, мол используйте L = 1024 (в исправленной редакции), и будет вам счастье. Никаких объяснений и комментариев по этому поводу нагуглить не выходит. Если у вас есть какие-то ссылки по теме, буду за признателен, если поделитесь, ибо интересно.

                        Так что, естественно, не зря ограничение введено, но почему? Мне лично не понятно. Так что вот. Но цель же сообщения была не в призыве использовать длинные DSA-ключи, а в демонстрации того, как переносить ключи между openssl и ssh, что может быть полезно во многих ситуациях.
                          0
                          К сожалению, навскидку ссылок с анализом этого привести не могу, если попадется на глаза, так отпишусь.
                            0
                              0
                              Ну, да. В babystep-giantstep зависимость от длины p 'логарифмо-линейная'. Ну-и-вот, это я и хотел сказать: либо ключ ломают за год, либо за 8 лет (если я правильно посчитал) — всё же разница :)
                                0
                                Хотя, да, сложно понять, что именно это я в виду и имел. Буду в следующий раз математикой писать.
              0
              А в чем смысл такого длинного DSA ключа? Чем не устраивает RSA, тем более он и утилиткой собирается, да и вообще по-дефолту идет.
                0
                Недавно сгенерил и заюзал 16к+ без проблем

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое