[gnutls-devel] TLS 1.3 in gnutls
n.mavrogiannopoulos at gmail.com
Mon Sep 5 18:46:17 CEST 2016
On Mon, 2016-09-05 at 18:15 +0200, Niels Möller wrote:
> Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> writes:
> > . 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
> 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
> : 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
> * 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
> Montgomery ladder (see curve25519-mul.c), and I'd expect it to be
> reasonably straight forward to generalize to x448. On the other
> 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
> twisted). Current point add code for ed25519 is suboptimal, it uses
> formulas for non-twisted curve with appropriate only sign changes,
> 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.
More information about the Gnutls-devel