On Mon, 2016-09-05 at 18:15 +0200, Niels Möller wrote: > Nikos Mavrogiannopoulos <[email protected]> writes: > > > > > [0]. https://gitlab.com/gnutls/gnutls/milestones/8 > Nettle additions: > > * HKDF (RFC 5869): Should be reasonably straight forward. Any use > besides TLS 1.3?
I'm not aware of any other, but I didn't really searched. I expect that since it is well-specified and standardized by TLS 1.3, it will be used by other protocols, but that's more of a speculation. > * RSA-PSS. I take it's mandatory? I had the impression that pss was > almost dead (specified more than a decade ago, and very rarely > used, > hard to do constant time). We'll have to support it, I guess. The latest draft has fallback to PKCS#1 1.5. It however states: "A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256." so having it is a "must". The constant time point is worrying. > Andy Lawrence expressed some interest on the Nettle list last > December, but I don't know what's happened since. Andy do you have any update on that? > If I quote Peter Gutmann on the secsh mailing list: > > : However, PSS has seen so little interest from both the crypto > : community and implementers that we can't really say much about > it. For > : example for some years the NIST test vectors for RSA-PSS were > completely wrong > : (every single test except the SHA-224 ones failed), and no-one > noticed. > : > : I'll just let that sink in for a second. The published test > vectors from a > : major, effectively global in reach, standards body for RSA-PSS > were wrong, and > : no-one noticed. How much attention do you think that indicates > PSS has got in > : practice? PKCS#1 1.5 worked well for signing. There were no real-world attacks known so I guess there was no incentive to switch to PSS. I only saw PSS signatures in some certificates issues by governments for inclusion in passports. > * x448. Should be able to reuse some of the curve25519 code, but not > all. for curve25519, multiplying a point by a scalar is doen using > a > Montgomery ladder (see curve25519-mul.c), and I'd expect it to be > reasonably straight forward to generalize to x448. On the other > hand, > multiplying the fixed generator by a scalar is done on the > corresponding (twisted) edwards curve, using Pippenger's algorithm, > and then transformed back by a change of coordinates, see below. > * ed448. This curve has slightly different structure from ed25519 > (not > twisted). Current point add code for ed25519 is suboptimal, it uses > formulas for non-twisted curve with appropriate only sign changes, > and > it could save a mod mul by taking better advantage of the twist. So > ed448 needs its own point addition code. These are of lower priority. We already have x25519 and the ECDSA curves, so there is something to start with. regards, Nikos _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
