Hello, Niels Möller <ni...@lysator.liu.se> writes:
> 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. I did a bit of a research and realized that, when we added OAEP in libgcrypt, we apparently picked the test vector from: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1d2-vec.zip https://lists.gnupg.org/pipermail/gcrypt-devel/2011-June/001802.html The zip file is no longer accessible, but I still keep a copy and it seems identical to the one at: https://github.com/pyca/cryptography/tree/main/vectors/cryptography_vectors/asymmetric/RSA/pkcs-1v2-1d2-vec Is it OK to use the vector assuming it is public domain? In any case I incorporated one test from the vector. > 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. Yes, the length should match key->size; I've omitted the ciphertext_length argument. I'm not sure about the leading zeros though; as far as I read, nettle_mpz_to_octets seems to keep them. Regards, -- Daiki Ueno _______________________________________________ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
