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

[Watson Ladd <[e-mail]>]

On Thu, Apr 10, 2014 at 1:22 AM, Nikos Mavrogiannopoulos
<[e-mail]> wrote:
> On Wed, 2014-04-09 at 08:00 -0700, Watson Ladd wrote:
>
>> In fact, because you are the GnuTLS developer, I know exactly what
>> your bignum library, gmp does. And it isn't pretty: operations can
>> take different paths depending on argument size, which includes
>> lopping off zero limbs. Modulo is computed by division, which involves
>> an instruction that is notoriously variable-time on many
>> architectures.
>
> And how does this affect an ephemeral key exchange? I'll reply for you.
> It has no effect, because it is an ephemeral key exchange.

Not so: if I have a side channel that leaks to a local attacker,
ephemeral keys are just as vulnerable as long term keys.
Furthermore, Curve25519 can be used with long-term DH keys also.

>
> Being constant time, _matters_ when you do operations on a long-term
> key, not when you do one operation on a one-time-key. So in the cases
> where it matters nettle (the crypto library used by gnutls), is constant
> time, and outperforms all other implementations so far.

Of Curve25519? Do you have publicly verifiable benchmark data for this?
For P256 I'd be a little surprised: AGL and Shay Gureon have put a lot
of work into optimized assembler implementations.

>
>> Your bignum implementation is also slow.
>
> See the point above. I'd be interested to know how you figured that gmp
> is slow.

GMP works for \mathbb{Z} very well. But it can't ever skip a reduction
or a carry because you might ask it a question that requires it to
have an answer fully reduced in the next step.

If I know that I'm working modulo Z/pZ for some p, then I can pick
representatives in any ring with a morphism to Z/pZ. This extra
freedom can only help, never hurt.

>
> btw. I never mentioned implementing curve25519 using gmp or otherwise,
> because I am not going to implement the low level part of it. That's why
> I asked input from other who plan to implement it.
>
>> If you do decide to persist in this folly, reversing the bytes won't
>> stop you, sadly. But I wish it could.
>
> Please keep your poison for yourself.

"You" refers to everyone who wants to do this themselves. I wouldn't
implement it myself either.
The point is that all curves need to be treated by largely separate
code for the field arithmetic for the optimum in performance.

A byte swap is really not going to keep anyone from implementing
Curve25519: I see no reason to fight this holy war.

Sincerely,
Watson Ladd

>
> regards,
> Nikos
>
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin