Daiki Ueno ueno@gnu.org writes:
Now that another attack on RSA encryption with PKCS#1 v1.5 padding has been discovered (though Nettle is not vulnerable)[1], it is recommended to avoid using the v1.5 scheme in new applications[2][3], and thus supporting RSA-OAEP in Nettle is becoming more relevant.
I agree oaep support is desirable.
I made some modifications to the existing merge request[4], mainly to make it side-channel safe at decryption: https://git.lysator.liu.se/nettle/nettle/-/merge_requests/60
Thanks for reviving this issue, and looking into side-channel silence.
Could you take a look when you have time?
Thanks, I've had a look, and it looks pretty good to me. Some comments and questions:
* For tests, would it make some with some test that check that encryption with a given message and randomness gives the expected output? Even better if there are any authoritative testcases for that?
* Is it useful to have oaep_decode_mgf1 and oaep_encode_mgf1 advertised as public functions, or would it be better to make them internal?
* Do you see any reasonable (i.e., with a net gain in maintainability) way to share more code between _oaep_sec_decrypt_variable and _pkcs1_sec_decrypt_variable?
* For oaep_decode_mgf1, oaep_encode_mgf1, maybe one could let the caller allocate and pass in the appropriate hashing context? Would be easy to do, e.g., in rsa_oaep_sha512_decrypt. But it looks like that would be inconsistent with pss_mgf1, though (which looks like it needs a separate hashing context).
* I think it was a design mistake to represent RSA ciphertexts as mpz_t rather then octet strings in Nettle's original RSA interfaces. I wonder if it would make sense to let the new functions take octet strings instead?
Regards, /Niels