Hi, I've tried to make a rough sketch of the requirements needed to support TLS 1.3 in gnutls. I've split the task in sub-tasks on [0]. Some need to be handled in gnutls and some need to be handled in nettle. Do you think I've missed something, or there are tasks that can be further split? About the nettle additions, is there anyone already working or willing to work on these? On the gnutls part is there anyone already working or willing to work on the missing parts?
regards, Nikos
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
Nettle additions:
* HKDF (RFC 5869): Should be reasonably straight forward. Any use besides TLS 1.3?
* 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. Andy Lawrence expressed some interest on the Nettle list last December, but I don't know what's happened since.
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?
* 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.
Regards, /Niels
On Mon, 2016-09-05 at 18:15 +0200, Niels Möller wrote:
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
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@lists.lysator.liu.se
-
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se