Длина зашифрованного текста, созданного RSAES_OAEP_Encryptor?

Мое использование библиотеки Crypto++ прошло очень хорошо, но у меня есть небольшой вопрос...

Если я использую RSAES_OAEP_Encryptor и RSAES_OAEP_Decryptor, все в порядке. (Я использую 2048-битный ключ из файлов PEM, сгенерированных OpenSSL).

Мой вопрос таков: будет ли длина ciphertext, создаваемая encryptor.Encrypt(...), всегда равна decryptor.FixedCiphertextLength() или может быть меньше? Я только спрашиваю, так как это находится в библиотеке, используемой рядом приложений, и мне нужно проверить параметры работоспособности.....

КСТАТИ. Есть ли более быстрое шифрование/дешифрование с использованием RSA, которое поддерживает хотя бы тот же уровень безопасности, что и OAEP? С 1024-битным ключом в примере тестового блока, усредненного по 1000 итерациям, я обнаружил, что для кодирования короткой строки требуется около 80 мкс и 1,03 мс (в 12 раз дольше) для расшифровки; с 2048-битным ключом шифрование занимает 190 мкс, а дешифрование — 4,3 мс (в 22 раза дольше). Я знаю, что расшифровка RSA медленная, но... система работает под управлением XP Pro SP3/Xeon E5520 и была скомпилирована с помощью VS2008 с параметром /MD, а не /MT. Я не могу использовать ключ короче 2048 бит из соображений соответствия...

Большое спасибо

Ник


rsa crypto++
person Nicko    schedule 22.01.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Длина зашифрованного текста, созданного RSAES_OAEP_Encryptor?

В случае с RSA, я думаю, FixedPlaintextLength() и FixedCiphertextLength() вызывают MaxPreImage() и MaxImage(). MaxPreImage() и MaxImage(), в свою очередь, возвращает n - 1.

Будет ли длина зашифрованного текста, создаваемого encryptor.Encrypt(...), всегда равняться decryptor.FixedCiphertextLength() или может быть меньше?

Это зависит от используемой криптосистемы. Обычно размер ключа определяет, сохраняется ли FixedCiphertextLength() (а не размер обычного текста). В случае RSA/OAEP и других, подобных ElGamal, я считаю, что это верно.

Я думаю, что здесь интерес представляет класс PK_CryptoSystem Class Reference. Такие классы, как RSAES_OAEP_Encryptor, наследуются от PK_CryptoSystem, и отсюда берутся FixedCiphertextLength() и его друзья.

С 1024-битным ключом в примере тестового блока, усредненного по 1000 итерациям, я обнаружил, что для кодирования короткой строки требуется около 80 мкс и 1,03 мс (в 12 раз дольше) для расшифровки; с 2048-битным ключом шифрование занимает 190 мкс, а дешифрование — 4,3 мс (в 22 раза дольше)

Это другой вопрос, но...

В случае шифрования или проверки используется публичный показатель. Публичный показатель по умолчанию равен 65537 (IIRC). У него низкий вес Хэмминга (высокая плотность нулей), поэтому процедуры возведения в степень и умножения выполняются относительно быстро.

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

Воспользовавшись этими небольшими временными различиями, вы получите побочные каналы, если не будете осторожны. Если вы не будете осторожны, то АНБ скажет вам спасибо.

Я не могу использовать более короткий ключ, чем 2048 бит, по соображениям соответствия

2048-битный модуль примерно в 10 раз медленнее, чем 1024-битный модуль. Вот почему так много людей не хотели переходить с 1024-битной версии, и почему 1024-битная версия по-прежнему предпочтительнее.

Вот что говорит об этом Питер Гутманн в своей книге «Техническая безопасность» (стр. 229):

Другой пример [неработающих моделей угроз] произошел с ключами в сертификатах, для которых поставщики браузеров (в ответ на требования NIST) заставили центры сертификации перейти со 1024-битных на 2048-битные ключи, при этом все, что все еще использует 1024-битные ключи, публично осуждается. как ненадежный. Как обсуждалось в разделе «Проблемы» на стр. 1, злоумышленники даже не заметили, подписаны ли их мошеннические сертификаты 2048-битными ключами или нет.

person jww    schedule 25.01.2014