Более быстрый асимметричный шифр, чем RSA

Question

Я работал над системой, которая использует асимметричное шифрование большого количества файлов. В настоящее время я использую RSA с 4096-битными ключами для шифрования 256-битного случайно сгенерированного ключа AES для каждого файла, но производительность несколько снижается, поскольку одной из необходимых операций является сканирование всех файлов (расчетное число, когда система находится в использовать около 10000) и определить, какие из них могут быть расшифрованы с помощью конкретного закрытого ключа. Хотя я не ожидаю, что эта операция будет мгновенной, в данный момент она занимает слишком много времени (~ 2 файла обрабатывается в секунду). Я подумал об уменьшении длины ключа, но даже уменьшение его до 2048 бит не обеспечивает требуемый уровень производительности. 512 бит вот-вот его обрежут, но поскольку такие ключи теперь можно взломать тривиально, об этом не может быть и речи.

Кто-нибудь может направить меня в сторону системы, которая быстрее, но с такой же криптографической силой? Это должно быть реализовано через провайдера Java JCA (например, что-то вроде bouncycastle), чтобы аккуратно подключаться к моему существующему приложению. Я знаю, что надувной замок поддерживает Эль-Гамаля, но я не могу найти какие-либо подробности о том, насколько силен этот алгоритм или даже если он будет быстрее, чем RSA. Я также слышал о системах эллиптических кривых, которым нужны только относительно короткие клавиши (384 бита или тому подобное), но я не знаю, где найти реализацию одного из них.

Answer 1

В ответ на свой вопрос попробуйте Диффи-Хеллмана по эллиптическим кривым, также известным как «ECDH». Оценка безопасности становится немного труднее, когда мы имеем дело с размерами, которые невозможно взломать с помощью современных технологий, поскольку это зависит от того, как мы делаем ставку на будущие технологические изменения. Тем не менее, можно сказать, что ECDH по кривой P-256 обеспечивает «128-битную» безопасность, уровень, аналогичный тому, который вы получили бы от 2048-битного RSA. Этого уровня достаточно для всех текущих применений или, точнее говоря, если P-256 недостаточно для вас, тогда у вашей проблемы есть очень особые потребности, и криптографическая стойкость, вероятно, будет наименьшей из ваших забот.

На моем ПК (Intel Core2 2,4 ГГц, 64-битный режим, под управлением Linux) OpenSSL заявляет, что обрабатывает около 900 экземпляров ECDH в секунду, используя одно ядро.

Изменить: для оценки безопасности ключа, в зависимости от длины, для нескольких алгоритмов, см. этот сайт .

Answer 2

Почему бы вам не вычислить криптографически стойкий хэш каждого ключа, а затем сохранить его в открытом виде с каждым именем файла?Затем, учитывая ключ, который необходимо сопоставить со всеми файлами, вы можете просто хешировать ключ и найти его в таблице.

Answer 3

Я бы пошел на подход, который требует меньше операций RSA. SSL / TLS, хотя они используют RSA и т. Д. Для шифрования ключей AES и т. Д., Не используют AES для данных просто потому, что это вычислительно дорогая операция с достаточно большими размерами ключа для обеспечения безопасности для каждого пакета или в вашем случае для каждого файла.

Другая система открытых ключей: http://en.wikipedia.org/wiki/ElGamal_encryption. С точки зрения безопасности, я считаю, что она еще не сломана, но пока лично доверяю RSA. Я не знаю, есть ли в настоящее время какие-либо алгоритмы шифрования на основе эллиптических кривых, то есть я знаю, что они исследуются, но понимаю, что они могут быть не готовы к производственному использованию, и я слышал, что были патентные проблемы.