Hello,
nisse@lysator.liu.se (Niels Möller) writes:
I hope you're ok if we do this piecewise. Here are comments on some on the pieces.
Sure, I really appreciate that :-)
I have incorporated the suggested changes here: https://gitlab.com/dueno/nettle/commits/wip/dueno/rsa-padding
If you prefer, I can post those to the list.
Maybe rename it pkcs1-mgf1.h, then? I feel "mgf1.h" is a bit too obscure for a short name.
Renamed.
+#define NETTLE_MAX_HASH_CONTEXT_SIZE 512
It's not so nice with a literal constant, since sizes are somewhat platform dependent. I'm considering the patch at the end of this message instead. It uses sizeof(sha3_224_ctx), which turns out to be the largest one by a quite large margin (and 352 bytes, on x86_64). The drawback is that code using this constant needs to include sha3.h to get the size, but I think that's ok for implementation files.
Yes, that seems like a good idea.
I'd suggest
VALGRIND_MAKE_MEM_DEFINED(m, sizeof(*m)); VALGRIND_MAKE_MEM_DEFINED(m->_mp_d, sizeof(mp_limb_t) * mpz_size(m));
The first is a bit tricky since the mpz_t is a typedef:ed array, I hope I got it right.
Fixed, thanks for pointing that out.
+While the above functions for the RSA signature operations use the +@cite{PKCS#1} padding scheme, Nettle also provides the variants based on +the PSS padding scheme, specified in @cite{RFC 3447}.
+Creating an RSA signature with the PSS padding scheme is done with one +of the following functions:
It would be nice if the documentation gave some explanation of the purpose of the salt input, and some guidance on how to select the salt length and contents.
I have added the following:
"These variants take advantage of a randomly choosen salt value, which could enhance the security by causing output to be different for equivalent inputs.
However, assuming the same security level as inverting the @acronym{RSA} algorithm, a longer salt value does not always mean a better security @uref{http://www.iacr.org/archive/eurocrypt2002/23320268/coron.pdf%7D. The typical choices of the length are between 0 and the digest size of the underlying hash function."
Hanno Böck hanno@hboeck.de writes:
I'd recommend adding test cases for key sizes like 2049 bits, 2047 bits that are not divisible by 8. Such keys aren't common, but they do sometimes appear in the wild in TLS certificates. So this could easily lead to bugs that rarely show up and are hard to debug.
Thank you for the suggestion. The current test includes a case for a 777-bit key, though it is self-generated. Would this be sufficient, or is there any test vector for such keys?
By the way, I have added (partial) verification support for gnutls: https://gitlab.com/dueno/gnutls/commits/wip/dueno/rsa-padding
For testing RSA-PSS certificate verification, one can do: $ certtool --verify --load-ca-certificate ca.crt --infile ca.crt
Regards,