Re: Add RSA-OAEP encryption/decryption to Nettle
On Mon, 2024-01-15 at 21:43 +0100, Niels Möller wrote: > Daiki Ueno 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? Hi Niels, I did review this part, and to me it seem like it is more maintainable to keep them separate, they already are tricky as it is, adding more variability sounds to me would just make them more complex and difficult to reason about. HTH, Simo. > * 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 -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc ___ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
Re: Add RSA-OAEP encryption/decryption to Nettle
Daiki Ueno 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
Re: ppc64: v3: AES/GCM Performance improvement with stitched implementation
Niels Möller writes: > For next step, I'm considering the refactoring of ghash to use the > new macros. I actually started with the macros relevant for the AES code. And it turned out to be rather easy to do the m4 loops to operate on an arbitrary list of registers. See branch ppc-aes-macros, in particular, https://gitlab.com/gnutls/nettle/-/blob/ppc-aes-macros/powerpc64/machine.m4?ref_type=heads#L67 I'm not entirely happy with the naming (OP_YXX, OP_YXXX), which is on one hand intended to correspond to the instruction pattern the macro expands to, and at the same time correspond to the expected order of arguments, which really doesn't work that well. Suggestion welcome. 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
