Hello, ni...@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}. The typical choices of the length are between 0 and the digest size of the underlying hash function." Hanno Böck <ha...@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, -- Daiki Ueno _______________________________________________ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
