Re: [TLS] Curve25519 in TLS and Additional Curves in TLS

[Alyssa Rowan <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/04/2014 09:22, Nikos Mavrogiannopoulos wrote:

> And how does this affect an ephemeral key exchange?

Assuming all side-channel attacks require repetition seems like the
kind of rather dangerous thinking that has bought TLS very unpleasant
surprises in the past. We've had quite enough of those already, I think.

Curve25519 was designed _specifically_ so that it can use a lovely,
extremely fast, constant-time Montgomery ladder: if you're not using
that, frankly, you're doing it wrong. (Section 5 of the draft already
addresses that, on my reading.)

> That's why I asked input from other who plan to implement it.

OK. Try _not_ to make your own implementation, especially not using a
generic bignum library: you'll both have side-channel problems, and
your performance will suck compared to the existing implementations.

Several liberally-licensed, extremely good, highly-optimised, correct
implementations of Curve25519 already exist: libsodium, for example.
They're probably better in every way than one you (or I) could write.

Practical implementation on most platforms in software therefore
pretty much consists of taking a good implementation; carefully
building scaffolding around it to plug it in; very thoroughly testing
that; and that's it.

This draft is, very simply, the standards part of that 'scaffolding'.

Given big-endian is the 'wrong way round' from what comes out of and
goes into literally every one of these implementations, it seems a bit
silly to ask basically everyone to byte-swap for no reason when we
could just... not.

That's why I say use the existing little-endian format. It's not a
holy war, it just feels utterly pragmatic in this case, just because
it's simpler that way.

Given bugs like Heartbleed, goto fail, the recent GnuTLS one (that
doesn't have a cute name as far as I know?), and doubtless, many more
to come - the simpler we can make that scaffolding, the less
opportunity there is overall to screw it up.

That's my take on it, anyway.

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTRv7eAAoJEOyEjtkWi2t6Ef0P/jA3q3ahnLwY92wSByDmYVtD
xZSXJFXFaJ/mF3h9ix94b55T5+Oyzr2pcOdbItW5AriG8PP3Rs702N7PXaIZWS8l
SAEHMBB2bNWFlbwttpVLfrGqWdYIcjXhD/IDsiU+hRXs5K7Gb1DHM8Y8RLylNDTz
xGpHGs1lJAc8ubLIKU3axXMavTbJWfHo8icou4EWiIqoFz1uR1rxUwhcSPg2CT7N
IJNDD/Ap+4Mkcuo/L3r8jjzD9EN5PkuQUGGLgmT3WyZNMx/XMLbkrn/1eKOafjMc
QpFbLA7dq0dGAtpW47U1kNcivO/eAX/Xq6LftTcQ15dZZgcEORIG60BxS5rsaudZ
0+frOMuTd0Dxv7g/1Zr4+ADK4C8vibSZUSMv19A1uA5chKzEqsjssndiNpfqy/WZ
yGn/edoemDwE+jdVhHEQh4qZxycXJdqfAyg1M8FhUxahzFxEFnv/RlW54kgqULaQ
He0OTB+lwMWbHQDXp9Aj2PcDdyFyA5QHWwjF8+zpDKhIB87aV30LEw1P3upwvtYG
CZJ9XLqJz39GwRGGN+liugakBpWAyNFoOGnb5WvpUEdq1INEdUFHul2eQV0nF374
KXaHadVV32I1tQ7ECVVrv69/1xqWBAm0eC+LGgf9Cz+wT7chvAWf85/5u7QkvBJo
KRCoFogKpVV9DXmCcUp+
=++Qz
-----END PGP SIGNATURE-----