Каков предел объема данных, которые могут быть зашифрованы с помощью RSA?

Обычно рекомендуется использовать RSA для шифрования симметричного ключа, который затем используется для шифрования "полезной нагрузки".

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

В частности, мне интересно, безопасно ли шифровать открытый ключ RSA (256 байтов) с открытым (открытым) ключом RSA? Я использую криптографические библиотеки Bouncy Castle в Java.

Ответы

Ответ 1

Для n-разрядного ключа RSA прямое шифрование (с PKCS # 1 "старое" дополнение) работает для произвольных бинарных сообщений до пола (n/8) -11 байт. Другими словами, для 1024-битного ключа RSA (128 байт) до 117 байт. С OAEP (дополнением PKCS # 1 "новый стиль" ) это немного меньше: OAEP использует хэш-функцию с выходной длиной h бит; это подразумевает ограничение по размеру пола (n/8) -2 * ceil (h/8) -2: все еще для 1024-битного ключа RSA с SHA-256 в качестве хэш-функции (h = 256), это означает двоичные сообщения до 60 байт.

Нет никакой проблемы при шифровании ключа RSA с другим RSA-ключом (нет никакой проблемы при шифровании любой последовательности байтов с RSA, независимо от того, что представляют эти байты), но, конечно, "внешний" RSA-ключ должен будет быть больше: с заполнением старого стиля, чтобы зашифровать 256-байтовое сообщение, вам понадобится ключ RSA с модулем не менее 2136 бит.

Гибридные режимы (вы шифруете случайный симметричный ключ с RSA, а затем используете этот ключ для симметричного шифрования), тем не менее, рекомендуется в качестве общего случая, хотя бы потому, что они не имеют каких-либо практических ограничений размера, а также потому, что они делают это проще заменить часть RSA другим алгоритмом обмена ключами (например, Diffie-Hellman).

Ответ 2

(теоретический) предел бесконечен.

Для практического ограничения вам нужно будет провести тесты с вашей конкретной аппаратной/программной реализацией и сравнить с вашими требованиями относительно скорости.


Что касается безопасности, я бы сказал, да. Ваша личность (которую вы хотите скрывать) безопасна, как безопасность вашего личного ключа получателя.

Ответ 3

Предел более или менее бесконечен, но, как вы говорите сами, это не так, как следует использовать асимметричный крипто. Методы, используемые для реализации асимметричной криптосистемы, на порядок медленнее, чем методы симметричного криптографического (например, AES, TrippleDES, PRESENT,...). Так зачем вам это делать? Используйте асимметричный криптографический ключ для создания ключа (используя протокол установления защищенного ключа, не изобретайте его), а затем зашифруйте свои данные с помощью симметричного алгоритма с использованием установленного ключа.

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

[Изменить]. Одна вещь, которую вы обязательно должны проверить, - это функции, которые вы используете для заполнения приложений (желательно RSAES-OAEP). В противном случае ваш открытый ключ будет каждый раз зашифровывать на один и тот же вывод, и, таким образом, противник, шпионящий в вашем сообщении, все еще может узнать, что именно вы передаете что-то, хотя он не может видеть, какой открытый ключ вы передаете.

Ответ 4

Спустя три года после того, как вы задали вопрос, я наткнулся на вашу публикацию, потому что мне просто пришлось реализовать что-то похожее. В этом случае вам понадобится режим шифрования, чтобы разбить сообщение на куски размера ключа из-за максимальной длины сообщения. Вам также потребуется заполнить блок, чтобы заполнить каждый блок сообщения (с учетом заполнения сообщения, которое обычно применяется к чему-то вроде DES, 3DES, AES). Нелегко, но возможно. Вы должны убедиться, что каждый заполненный блок меньше максимально допустимого размера. Для заполнения блока вы можете использовать, например, OAEP или PKCS_V1_5. В качестве режима шифрования вы можете использовать ECB (не защищенный, но работает) или что-то более продуманное. (см. режимы википедии и шифрования).

если у вас есть хороший API-интерфейс криптографии, вы должны иметь возможность установить режим шифрования и отложить блок/сообщение и просто выбросить на него сообщение.