Здесь есть две основные возможности:
1) На самом деле вы имеете в виду подписание (операция с закрытым ключом) и проверка (операция с открытым ключом).
При подписании RSAвходное сообщение переваривается, и дайджест объединяется со схемой заполнения, затем закрытый ключ применяется к дополненным данным.
При проверке RSA сообщение кандидата переваривается, открытый ключ используется для отмены закрытогоключ приложения, а затем дайджест используется для проверки дополненного сообщения.(В сигнатурах PKCS # 1 это «посмотрите и посмотрите, правильный ли это ответ», для PSS это сложнее).
Если это то, что вы имеете в виду, тогда вы хотите
- Подпись
- RSA.SignData (хеширует данные, затем вызывает SignHash)
- RSA.SignHash (завершает операцию, является общедоступной, если вы уже хэшировали данные и хотите сэкономить на избыточности)
- Подтверждение
- RSA.VerifyData (хеширует данные, затем вызывает VerifyHash)
- RSA.VerifyHash (аналогично указанному выше)
2) Вы хотите инкапсулировать произвольные данные в преобразовании, используя закрытый ключ.
Стандарты RSA PKCS # 1 и / или RFC не имеют описания того, что это означает.«Зашифровать» в RSA означает применить выбранную схему заполнения к данным (PKCS # 1 или OAEP), а затем выполнить операцию RSA с открытым ключом.«Расшифровать» означает выполнить операцию RSA с использованием закрытого ключа, а затем удалить заполнение.
Встроенные методы Encrypt и Decrypt выполняют эти операции, в том числе знают, какой ключ использовать.
Применение клавиш в обратном направлении даст математически ощутимые результаты, но на практике это не имеет смысла.Предполагая, что мы сохраняем «частный», что означает «ключ, который известен только одной стороне», это означает, что у вас есть данные, созданные одним человеком, которые могут быть прочитаны кем угодно.Если идея заключается в том, что «я хочу, чтобы читатели знали, что это было сделано [держателем закрытого ключа]», тогда подписание - более эффективная операция: она оставляет данные в простом виде, позволяя читателям делать более оптимальное чтение.
Шифрование RSA далее определяется только как однократная операция, что означает, что, как следствие, оно ограничено общим количеством байтов контента, которое меньше, чем количество байтов в модуле RSA (на 11 байтов меньше для PKCS# 1 и большее сокращение OAEP, в зависимости от выбранного алгоритма хеширования OAEP).Поскольку сначала подписываются хэши, объем данных, обрабатываемых в RSA, имеет фиксированный размер.В обычном случае шифрования RSA зашифрованная вещь представляет собой симметричный (AES) ключ или какое-то средство создания ключа AES ... и это намного меньше.
В конце концов, вывод этого пути таков:«Нет, .NET не позволяет вам делать это».
Если вы транспортируете лицензию, стандартный подход заключается в ее подписании.Не забудьте включить механизм замены ключа выдающего лицензию со временем, например, записать сертификат подписи.Или используйте что-то вроде подписанных данных PKCS # 7 / CMS, как показано в .NET System.Security.Cryptography.Pkcs.SignedCms, поскольку это предопределенный формат для передачи данных, подписи и сертификатов подписи - просто проверьте, что cms.SignerInfos[0].Certificate приемлемо, а затем, если CheckSignature(true) не бросает, вы можете идти.