search

Pkcs11Interop / Pkcs11Interop.X509Store

Easy to use PKCS#11 based X.509 certificate store
Apache License 2.0
33 stars 18 forks source link

Added ability to Encrypt and Decrypt for RSA PKCS1 padding. #32

Closed dunkleyr closed 7 months ago

dunkleyr commented 2 years ago

Added logic to the Encrypt and Decrypt overrides for pkcs1 padding. I added some test cases to cover the added code, but the software HSM doesn't support it so the tests were commented out.

jariq commented 7 months ago

Thanks for the PR @dunkleyr.

SoftHSM supports both RSA encryption and RSA decryption with PKCS#1 padding just fine. Code submitted in this PR was incorrect because it was trying to perform encryption with private key while it should be performed with public key.

I've just committed correct implementation in 8b32c33638af22659c08d7066c249d35eba3635b so I'm closing this PR without merge.

dunkleyr commented 7 months ago

There are scenarios where you would want to encrypt with the private key as opposed to the public key. It would be nice if the library supported both, but I understand that was not the intent of these specific methods.

jariq commented 7 months ago

@dunkleyr I am not sure I understand your comment.

RSA is asymmetric public/private key based cryptosystem. In my experience RSA encryption is always performed with public key and RSA decryption is always performed with private key. If it's the other way around, then it's not encryption/decryption but signing/verification. I've also never seen PKCS#11 implementation that would allow you to call C_Encrypt with private RSA key.

Can you please provide an example of a scenario you mentioned (scenario where you would encrypt data with a private RSA key)?
Can you please provide an example of PKCS#11 library that allows you to call C_Encrypt with private RSA key?

dunkleyr commented 7 months ago

Signing/Verification is the scenario I am referring to, but in cases where the full process of SignHash and VerifyHash methods can't be used. I don't remember the exact scenario since it has been 2 years, but I am guessing it was to encrypt ("sign") a hash that would be decrypted ("verified") at a low level (FPGA maybe or secure boot?) for integrity purposes (not concealment). It might have been the PKCS1 Digest info that it couldn't do, but I can't remember for sure.