Daiki Ueno <u...@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 -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
