[gnutls-devel] TLS 1.3 in gnutls

[Nikos Mavrogiannopoulos]

On Mon, 2016-09-05 at 18:15 +0200, Niels Möller wrote:
> Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> 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