Возможна ли утечка закрытого ключа RSA, если я подпишу и расшифрую?

Возможна ли утечка данных закрытого ключа, если злоумышленник контролирует запрос на подпись?

Все знают $N$ и $Е$ потому что они общедоступны.

Мой сервер предназначен для расшифровки входящего запроса, который зашифрован открытым ключом.

Сделайте знак и для расшифрованных данных, у которых SHA-2 возвращает знак RSA для этих данных.

Возможно ли, что злоумышленник может узнать мой закрытый ключ?

Я тестирую это в моей местной мастерской в ​​образовательных целях.

Я использую зашифрованное сообщение с открытым ключом PKCS#1 для входящего запроса; данные расшифровываются моим закрытым ключом и имеют SHA-2, поэтому я просто подписываю и возвращаю обратно подписанные данные клиенту.

Пример на Питоне:

Генерация пары сообщений и ключей:

сообщение = struct.pack('>IIII', 0, 0, 0, 1)
(pub, priv) = rsa.newkeys(512) // только для примера, я знаю, что никто не использует 512 бит

Входящий запрос:

зашифровано = pkcs1.encrypt (сообщение, публикация) 

Операции сервера:

расшифровано = pkcs1.decrypt (зашифровано, приватно)
подпись = pkcs1.sign (расшифровано, priv, 'SHA-256')

и вернуть ответ.

Из примера видно, что шифрование и подпись используют некоторые режимы заполнения в ПККС#1; вероятно RSAES-PKCS1-v1_5 для шифрования и RSASSA-PKCS1-v1_5 с SHA-256 для подписи.

Возможна ли утечка данных закрытого ключа?

Насколько мы знаем, нет, то что он расшифровал сообщение и подписал его тем же ключом не может утечка данных закрытого ключа. Это не зависит от точных схем заполнения, используемых для шифрования и подписи: мы просто не знаем, каким образом любое использование закрытого ключа RSA $(н,д)$ ограничивается вычислениями $x\mapsto x^d\bmod n$ в черном ящике без боковых каналов можно утечка данных закрытого ключа.

Среди подобных вещей, которые могут произойти:

• Реализация может привести к утечке закрытого ключа по побочному каналу; например, приземленная троянская программа, работающая на платформе, или Дифференциальный анализ мощности. Есть много других побочных каналов, которых следует опасаться.
• Реализация расшифровки RSAES-PKCS1-v1_5 может быть среди многие из них уязвимы для некоторых вариантов атаки Блейхенбахера. Это могло бы позволить превратить сервер в оракула, который позволяет (при достаточном количестве запросов) вычислять функцию $x\mapsto x^d\bmod n$ для произвольного $х$, давая (очень медленный) эквивалент знания закрытого ключа злоумышленнику, который может связаться с сервером.

Некорректно с академической точки зрения использовать одну и ту же пару открытого и закрытого ключей для шифрования и подписи, но с четырьмя режимами шифрования и подписи в ПККС#1 он не позволяет проводить какие-либо известные атаки. Самыми слабыми очевидными звеньями в цепочке безопасности являются

• Сама функциональность сервера: он позволяет получить подпись всего, что укладывается в ограничение по размеру для шифрования (117 байт).
• 512-битный модуль, который можно факторизовать (это уже было возможно в 20 веке).
• Использование расшифровки RSAES-PKCS1-v1_5 для неаутентифицированного зашифрованного текста из открытого доступа.