равнозначная криптостойкость
По какой формуле (или каково примерное соотношение если формулы нет) рассчитывается соотношение длины ключа для ассиметричных систем с длиной ключа для симметричных систем, для обеспечения равнозначной криптостойкости? :D Если предположить, что вскрытие шифр-информации будет проводиться только грубой силой, т.е. перебором ключей.
комментариев: 9796 документов: 488 редакций: 5664
Если симметричный алгоритм считается стойким, то для него действительно нет никакого иного метода вскрытия кроме перебора (хотя это идеальный вариант).
В ассиметричных алгоритмах так не бывает. Методы, намного более эффективные чем "тупой" перебор есть всегда. Например, "методы решета" в факторизации чисел. Если скорость "перебора грубой силой" можно с погрешностью до порядка считать условно однинаковой для всех симметричных алгоритмов, то для ассим. она сильно зависит от выбранного метода.
Для RSA скорости методов растут относительно быстро, для эллиптических кривых медленно (пока).
Соотношения стойкости ассим./симм. ключей часто основаны просто на прогнозах специалистов. .
Можете почитать вот этот материал: http://www.pgpru.com/articles/crypto/keysize.shtml
Вот пример интересующей Вас таблицы:
http://crypto-r.narod.ru/glava4/glava4_6.html
Длина ключей симм./асимметричной криптосистемы, бит:
56/384
64/512
80/768
112/1792
128/2304
Но еще раз: эти таблицы условные и непостоянные.
комментариев: 9796 документов: 488 редакций: 5664
PGP DH vs. RSA FAQ
Copyright © 1999 Sam Simpson – All Rights Reserved
комментариев: 510 документов: 110 редакций: 75
комментариев: 11558 документов: 1036 редакций: 4118
Только, ещё раз подчёркиваю, ECC не имеет никакого отношения к ГОСТу, о котором разговор особый. ECC не является рекомендованным в России алгоритмом. И, наконец, ECC запатентован компанией Certicom, поэтому, как и у IDEA, у него есть ряд ограничений на свободу использования, прежде всего, в коммерческой сфере.
комментариев: 9796 документов: 488 редакций: 5664
На всё. Они применили зонтик из более сотни патентов, запатентованы даже методы выбора точек для эллиптических кривых. После выкупа патентов АНБ и передачи в стандарты ситуация пока не улучшилась, а как-то подвисла — "минное поле" патентов. Упомянутая в вики альтернативная реализация DH от Бернштейна оценивается с осторожностью (т.к. не стандарт — то внедрять не хотят). Стандарты НИСТа также отсылают к разным организациям, которые могут предъявить права на ECC.
А кого-нибудь интересуют программы, не основанные на свободно поддерживаемых криптографических стандартах? Может конечно патентные страхи и преувеличены, но в проект Tor из-за этого пока не торопятся внедрять ECC (хотя очень было бы желательно для серверов).
Ну Samsung (Ю. Корея) же бодается со всякими Apple (USA) насчёт патентов и т.д. Подозреваю, что между развитыми государствами есть ряд соглашений о признании патентов — точно так же, как и о признании авторских прав.
комментариев: 1060 документов: 16 редакций: 32
Они бодаются в основном за американский рынок, это очень большой кусок пирога. Впрочем, в Южной Корее патенты на ПО тоже действуют. Ну и не забывайте, что с точки зрения американской юстиции вы попадаете в её сферу ответственности практически при любой деловой активности с резидентами США.
комментариев: 9796 документов: 488 редакций: 5664
Можно даже патентованные алгоритмы использовать (mp3 тоже был с непонятным патентным статусом, выкидывался из некоторых Linux-дистров и скачивался с отдельных зеркал). То же патентованное шифрование IDEA можно было скачать для GnuPG отдельно, что было актуально, когда выбор хороших свободных симметричных алгоритмов был невелик.
У тора понятно какие проблемы — переход на новое шифрование неизвестно как лучше плавно делать без шатдауна всей сети. И нельзя идти на риск профилирования пользователей по старым версиям, поэтому нельзя обеспечить обратную совместимость протокола. Если вдруг завтра скажут — всё-таки ECC патентно ограничить или появится новый гарантированно свободный стандарт, то не везде допустимо резко всё переделывать. В проектах типа Tor нельзя например резко менять алгоритмы или допускать применения разных параллельно.
Даже при том, что для свободных проектов риск судебных разбирательств невелик. Судятся обычно с тем, кто приводит к серьёзным убыткам или с кого можно получить прибыль (процесс Цертикома против Sony из-за ECC).
Просто, в отличие от коммерческих проектов, OpenSSL/GnuPG и пр. в случае чего могут безболезненно выпилить ECC обратно или вынести отдельным плагином в не US-зону как вы в качестве примера привели. Насколько это неудобно для пользователей — решать им самим. Если у кого-то например большая инфраструктура ключей и их нежелательно резко все менять — это их проблемы.
Он не обеднеет, если надо будет как-то платить владельцам патентов за использование.
Угу, и людям, которые его используют с ЭК, резко поплохеет.
"Погладь кота" в гугле.
[/offtopic]