Комментарии 17
Скоро вместо вместо ключей будут видео передавать, размер «ключа» будет что надо.
Ну, во-первых. /etc/ssh/moduli используется в SSH-протоколе для Diffie-Hellman key exchange, и ничего общего с DSA-ключем сервера не имеет.
Во-вторых, FIPS 186-2 все четко и понятно обьясняет. В DSA ключе грубо говоря есть два параметра — один, который имеет размер тех самых 1024 бит, и второй, который имеет фиксированый размер 160 бит (= размер хеша SHA1). И от обеих параметров зависит безопасность схемы. Когда размер первого параметра больше 1024 бит, фиксированый размер второго параметра становится «более слабым звеном», и дальнейшее увеличение размера первого параметра становится бессмысленным, только время вычислений увеличивается.
Ну и насчет преимущества RSA над DSA — на деле, общие параметры в DSA практически нигде не используются, и всегда генерируются заново.
Во-вторых, FIPS 186-2 все четко и понятно обьясняет. В DSA ключе грубо говоря есть два параметра — один, который имеет размер тех самых 1024 бит, и второй, который имеет фиксированый размер 160 бит (= размер хеша SHA1). И от обеих параметров зависит безопасность схемы. Когда размер первого параметра больше 1024 бит, фиксированый размер второго параметра становится «более слабым звеном», и дальнейшее увеличение размера первого параметра становится бессмысленным, только время вычислений увеличивается.
Ну и насчет преимущества RSA над DSA — на деле, общие параметры в DSA практически нигде не используются, и всегда генерируются заново.
Более того, бездумное увеличение длины ключей, как ни странно, УВЕЛИЧИВАЕТ восприимчивость алгоритма к некоторым видам атак (как правило, основанным на деталях реализации алгоритма). Вот неплохая презенташка, иллюстрирующая это:
www.comodo.com/research/crypto/CDW_SAC_03.ppt
Впрочем, насколько я помню, уже готовится FIPS 186-3, который допускает более длинные ключи. Видимо, он учитывает тот факт, что на более современных компьютерах уже более сложно «поймать» всякие разницы во времени между операциями умножения и возведения в степень, и т.п.
www.comodo.com/research/crypto/CDW_SAC_03.ppt
Впрочем, насколько я помню, уже готовится FIPS 186-3, который допускает более длинные ключи. Видимо, он учитывает тот факт, что на более современных компьютерах уже более сложно «поймать» всякие разницы во времени между операциями умножения и возведения в степень, и т.п.
FIPS-186-3 уже в финальной стадии, но вроде действительно еще в качестве стандарта его не приняли.
В основном он ориентирован на использование ECDSA (DSA на эллиптических кривых), но также описывает использование SHA-2 с DSA, благодаря чему размер ключа увеличивается до 4096 бит (с соответствующим увеличением параметра Q до 224...256..384..512 бит, а используемого хеш-алгритма — до SHA256..SHA512). Это уже используется в PGP, есть какие-то драфты по использованию этого в PKI, может еще где.
В основном он ориентирован на использование ECDSA (DSA на эллиптических кривых), но также описывает использование SHA-2 с DSA, благодаря чему размер ключа увеличивается до 4096 бит (с соответствующим увеличением параметра Q до 224...256..384..512 бит, а используемого хеш-алгритма — до SHA256..SHA512). Это уже используется в PGP, есть какие-то драфты по использованию этого в PKI, может еще где.
А где было сказано, что moduli вообще к ключам отношение имеет? И вот механизм того, почему короткий параметр становится 'более слабым звеном' совсем не понятен, скорее уж от увеличения длины стойкость не увеличивается. Долгое же время вычислений это, скорее, плюс. Потому что осуществлять атаку сложнее. Атаки же по вычислительной сложности (как по ссылке ниже), imho, иррелевантны. Их нужно проводить в идеальных условиях, когда на машине единственным работающим процессом является криптодвижок.
DSA vs. RSA: Вообще, тогда можно сказать, что и DSA практически нигде не используется. Но вот в личных целях, когда есть много машин, и много пользователей, работающих с ними по ssh, при том, что новые пользователи довольно часто приходят, DSA удобнее.
DSA vs. RSA: Вообще, тогда можно сказать, что и DSA практически нигде не используется. Но вот в личных целях, когда есть много машин, и много пользователей, работающих с ними по ssh, при том, что новые пользователи довольно часто приходят, DSA удобнее.
Интересно, какой же плюс представляет собой долгое время вычисления? Чем сложнее осуществлять атаку??
Чем больше p, тем больше чисел вида g^k (mod p), дающих одинаковые модули по основанию q. А, если ломать, например, электронную подпись, то для восстановления приватного ключа x, k нужно знать точно. Увеличивается пространство для поиска для нужного варианта. Или я не прав?
Вы были бы правы, если бы тупой поиск g был единственно возможной атакой на алгоритм. При увеличении p сложность других видов атак (на ту же хеш функцию например) становится относительно проще, и общая стойкость системы (которая есть минимальная стойкость всех компонентов, грубо говоря) не увеличивается.
Хм. Вот не понятно, почему проще. У вас есть какие-нибудь ссылки на рассуждения? Хэш-функция же в вычислениях учавствует только по модулю q (это который 160iB, чтобы под SHA1 подходил). Увеличение же пространства возможных решений, imho, всё же усложняет поиск ответа.
Почитайте теорию, тот же FIPS. Есть обобщенное понятие «bits of security», которое позволяет примерно сравнить «стойкость» разных алгоритмов. Ну в конце концов не просто так же они в официальном документа ограничили размер P?
Так. В том-то и проблема, что нигде не могу найти обоснования. В той же Applied Cryptography просто стоит ссылка на тот же FIPS. А в FIPS написано, мол используйте L = 1024 (в исправленной редакции), и будет вам счастье. Никаких объяснений и комментариев по этому поводу нагуглить не выходит. Если у вас есть какие-то ссылки по теме, буду за признателен, если поделитесь, ибо интересно.
Так что, естественно, не зря ограничение введено, но почему? Мне лично не понятно. Так что вот. Но цель же сообщения была не в призыве использовать длинные DSA-ключи, а в демонстрации того, как переносить ключи между openssl и ssh, что может быть полезно во многих ситуациях.
Так что, естественно, не зря ограничение введено, но почему? Мне лично не понятно. Так что вот. Но цель же сообщения была не в призыве использовать длинные DSA-ключи, а в демонстрации того, как переносить ключи между openssl и ssh, что может быть полезно во многих ситуациях.
К сожалению, навскидку ссылок с анализом этого привести не могу, если попадется на глаза, так отпишусь.
Ну вот что-то: osdir.com/ml/ietf.secsh/2005-11/msg00000.html
А в чем смысл такого длинного DSA ключа? Чем не устраивает RSA, тем более он и утилиткой собирается, да и вообще по-дефолту идет.
Недавно сгенерил и заюзал 16к+ без проблем
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
использование очень длинных ассиметричных ключей в ssh