Daiki Ueno <u...@gnu.org> writes: >>> * 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? > > I would be happy to add if there are any, even if they are not so > authoritative, though I wasn't even able to find ones with compatible > license, in particular with SHA-2 being used as an underlying hash > algorithm for MGF-1. > > - Project Wycheproof (Apache 2.0): > > https://github.com/google/wycheproof/blob/master/testvectors/rsa_oaep_2048_sha256_mgf1sha256_test.json > > - Python Cryptography (Apache 2.0 and BSD): > https://cryptography.io/en/latest/development/custom-vectors/rsa-oaep-sha2/ > > In any case, I'll try to check against those vectors manually outside > the Nettle repository to ensure the correctness.
To me it looks like those sources provide reasonable test vectors for RSA OAEP decryption. On licensing, it looks like Apache and GPLv2 might be incompatible. I've been a bit sloppy when incorporating test code (e.g., for some time I had some testcode copied from openssl/libcrypto, to test compatibility glue). But in this case, I think a fully correct workaround would be to license the related test file LGPLv3 (no GPLv2 option); odd licensing for some of the test files shouldn't matter much for Nettle applications since the testcode isn't part of the library applications link. Proper attribution is of course important. But my original question was for testing of RSA *en*cryption, if there are some determinstic testvectors with known output, with tests wiring something non-random for the randomness input. >>> * 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? > > Made them internal functions. Thanks. (It was maybe a mistake we didn't do that for the pss_*_mgf1 functions when added years ago). >>> * 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? >> >> 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. > > I agree with that, considering potential optimization opportunities by > the compiler. Let's leave this as is, then. >>> * 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). > > Done. Nice. We'll still have another one allocated for each call to pss_mgf1, if I read the code correctly. >>> * 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? > > Done. What does the OAEP spec say about the ciphertet length? It would make the interface easier if we say that the ciphertext length *always* equals key->size; then one could delete passing and checking of the ciphertext_length argument. In the current MR, it looks like leading zero bytes are trimmed (behavior of nettle_mpz_sizeinbase_256_u), so that ciphertext may sometimes be shorter. 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
