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

Question

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

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

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

BTW. Быстрее ли было шифрование/расшифровка с использованием RSA, которая поддерживает, по крайней мере, тот же уровень безопасности, который предоставляется OAEP? С 1024-битным ключом, в тестовом поле примера, усредненном более 1000 итераций, я нахожу, что для шифрования короткой строки и 1.03mS (в 12 раз) требуется около 80uS; с 2048-битным ключом шифрования занимает 190uS и дешифрование, 4.3mS (в 22 раза дольше). Я знаю, что расшифровка RSA медленная, но ... система работает под управлением XP Pro SP3/Xeon E5520 и была скомпилирована с VS2008 с/MD, а не с MT. Я не могу использовать более короткий ключ, чем 2048 бит для соответствия требованиям к ...

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

Ник

Answer 1

Длина шифротекста производимого 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 итераций, я нахожу, что она занимает около 80uS кодировать короткую строку и 1.03mS (в 12 раз больше) для расшифровки; с ключом шифрования 2048-бит принимает 190uS и дешифрования, 4.3mS (22 раз дольше)

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

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

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

Воспользовавшись этими небольшими разницами по времени, вы можете использовать свои боковые каналы, если вы не будете осторожны. Если вы не будете осторожны, то NSA поблагодарит вас.

---

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

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

Питер Гутман это сказать об этом в своей книге Engineering Security (стр 229).:

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