Re: Add RSA-OAEP encryption/decryption to Nettle
Niels Möller writes: > Daiki Ueno writes: > >> 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? > > According to the closest LICENSE file, > https://github.com/pyca/cryptography/blob/main/vectors/LICENSE, it's dual > licensed apache/BSD (our choice), so I think that is fine. And if > we copy just the test vectors and not any surrounding code, it seems > questionable if that is even copyrightable. > > So I think copying from there, with proper attribution, is perfectly > fine. Formally, we'll be exercising the BSD option. OK, thanks for the confirmation. I've expanded the KAT tests further using the vector and also added a license notice. >> Yes, the length should match key->size; I've omitted the >> ciphertext_length argument. > > Thanks. Please remove everywhere, it looks like it's still present in > some form in the test code. (You may still want to allocate an extra > byte at the end and check that it isn't modified. Alternatively, rely on > valgrind for detecting overwrites instead). Added `mark_bytes_undefined (1, [key->size]);` to the test cases doing encryption. 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
Re: Add RSA-OAEP encryption/decryption to Nettle
Daiki Ueno writes: > 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? According to the closest LICENSE file, https://github.com/pyca/cryptography/blob/main/vectors/LICENSE, it's dual licensed apache/BSD (our choice), so I think that is fine. And if we copy just the test vectors and not any surrounding code, it seems questionable if that is even copyrightable. So I think copying from there, with proper attribution, is perfectly fine. Formally, we'll be exercising the BSD option. > Yes, the length should match key->size; I've omitted the > ciphertext_length argument. Thanks. Please remove everywhere, it looks like it's still present in some form in the test code. (You may still want to allocate an extra byte at the end and check that it isn't modified. Alternatively, rely on valgrind for detecting overwrites instead). > I'm not sure about the leading zeros > though; as far as I read, nettle_mpz_to_octets seems to keep them. I think nettle_mpz_to_octets is fine. The problem was when the length passed to this function was computed using nettle_mpz_sizeinbase_256_u, like it was in a previous revision. 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: Add RSA-OAEP encryption/decryption to Nettle
Hello, Niels Möller writes: > Daiki Ueno 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
