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

On Wed, Apr 9, 2014 at 6:00 AM, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
> On Wed, 2014-04-09 at 13:17 +0100, Alyssa Rowan wrote:
>
>> >I believe you have already made your point several times. I think it is
>> >important to see comments from people who plan or work on implementing
>> >this draft, how each format affects them and whether there is a need
>> >for
>> >little-endian.
>> Don't we already seem to have consensus on little-endian, and that is what will be in the revised draft-04?
>
> I believe that you summarized the issue very nicely in a previous
> e-mail, but my reading of having a consensus for little-endian is
> different than yours.
>
> As far as I am concerned, I do not see why an implementation which will
> not use the existing code, must treat the endianness of points from
> curve25519 differently than the points of any other curve in TLS. In any
> case, the arguments are already presented and that's what I mentioned to
> Rich. I think we need more input from other people who plan or are
> already implementing this curve in TLS.

Your code should not use the bignum library you already have. It
should call into libnacl or the guts that are in libsodium, both quite
liberally licensed.

This is because DJB writes and distributes perfect code, and you do
not. Your bignum implementation has data-dependent branches and so
leaks information to an attacker on the same hardware, as well as
taking different times depending on branch state. If particularly bad,
you have data dependent loops in reduction modulo a prime. libnacl
avoids all these problems.

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.

Your bignum implementation is also slow. This is because it has to
permit arbitrary chains of addition between multiplications, which
don't happen in ECC. As a result it needs to reduce each sum, which is
unnecessary and slow. The libnacl implementations defer this reduction
until the end, and partially reduce products for additional speed,
taking advantage of the prime.

The gap between the implementation you will write, and the
implementation you can just use, in security, speed, and safety, is
enormous.

If you do decide to persist in this folly, reversing the bytes won't
stop you, sadly. But I wish it could.

Sincerely,
Watson Ladd

>
> regards,
> Nikos
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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