[Cfrg] On why point and APIs formats matter (Re: Submission of curve25519 to NIST from CFRG -> was RE: On "non-NIST")

[Watson Ladd <[e-mail]>]

On Tue, Mar 10, 2015 at 6:14 PM, Paul Lambert <[e-mail]> wrote:
> It would be a mistake to delay an opportunity to send a recommendation from
> this
>
> committee to NIST. Please note the quote:
>
>      "NIST encourages presentations and reports
>
>       on preliminary work that participants plan
>
>       to publish elsewhere."
>
> Your concerns about endianness are a trivial in comparison to the
>
> overall industry change to new public key algorithms.  Please have some
> focus
>
> and do not add noise to the topic.

No, they aren't: they are actually much more important than the
question of which curve to use. Periodically some TLS implementation
will investigate a rare failure of their NIST ECC implementation when
negotiating a handshake. And what will have happened is that they
encoded the x coordinate as a DHE result is encoded, without leading
null bytes. But this is incorrect: the x coordinate is zero padded in
ECDHE results.

These bugs and many like them are the result of poor internal design
of cryptography libraries, that treat all public key primitives as
accepting bignums. If you make that design choice, then yes, using
little-endian makes the Curve25519 implementation more difficult. But
that design choice makes using the library much more difficult:
instead of a single function call, the user has to make multiple calls
to encode and decode data, before and after cryptography. For extra
credit, ensure the decoding function cannot be used to properly
validate PKCS 1.5 signatures, and the calls expose failures that
shouldn't be revealed.

Of course, NIST standards (actually NSA, laundered through SEC1 and
ANSI X.9) do properly specify this. But they define *multiple*
separate encoding for public keys, mean that one has to specify two
separate encodings in a protocol using NIST curves, namely one for the
keys on the wire and a second for the ECDH result. Signatures have
their own ASN.1 inspired encoding, forcing multiple variations on
bignum encoding and decoding.

Furthermore, the choice of how to represent public keys has security
implications. Montgomery x-coordinate has, as everyone has noted, very
large improvements in simplicity, and hence security. The fact that
there is a unique encoding means that the API can be extremely simple
and difficult to misuse.

By contrast, which curve to choose (out of a set with the same shape)
doesn't have nearly the same impact on security or performance.  Given
the preliminary nature of NISTs efforts, it's far more useful to talk
about the important choices then the unimportant ones.

>
>
>
> The topic was a request to the Chairs to relay a position from this task
> group
>
> to NIST before the March 15th deadline.

And that position should reflect the choices that impact security and
interoperability, most of which haven't been officially made, rather
than the ones which don't, which have been made. I don't see what we
have to add on the subject that would represent a consensus view.

Sincerely,
Watson Ladd

>
>
>
> Paul
>
>
>
>
>
> From: Watson Ladd [mailto:[e-mail]]
> Sent: Tuesday, March 10, 2015 4:20 PM
> To: Paul Lambert
> Cc: [e-mail]; Tony Arcieri; [e-mail]
> Subject: RE: [Cfrg] Submission of curve25519 to NIST from CFRG -> was RE: On
> "non-NIST"
>
>
>
>
> On Mar 10, 2015 3:34 PM, "Paul Lambert" <[e-mail]> wrote:
>>
>> > Standards fragmentation is a fact of life. But we should strive to
>> > minimize it.
>> >And we shouldn't make it worse by varying endianess or encoding for
>>
>> Could we please desist with the off-topic rants.  This was a request to
>> the Chairs
>> to work more directly with NIST to propagate this task groups
>> recommendations.
>
> This group only has a recommendation of a curve right now. But that's not
> enough: you need to specify what gets sent on the wire, and that's where
> NIST potentially picks differently. So it's not enough to say use these
> primes and these curves to NIST: that won't necessarily have the effect you
> intend, precisely because that doesn't specify the coordinates and encoding,
> even if they take our suggestion as opposed to others.
>
> That's the worst possible outcome, especially if the names are the same.
>
>>
>> There was NO mention of endian! Such irrelevant points only add noise to
>> the mailing list.
>>
>> >something that for 8 years was done a different way: there's no
>> >benefit to doing it needlessly.
>>
>> Duh … and what about the 15+ years everyone else has setup the
>> bytes the other way round… (please do not answer on list, I don’t
>> care about the byte order today, my point is on irrelevant noise
>>
>> and arguments).  If you wish to debate endian … start your
>> own new subject line.
>>
>>
>>
>> Paul
>>
>>
>>
>>
>>
>> From: Watson Ladd [mailto:[e-mail]]
>> Sent: Tuesday, March 10, 2015 3:22 PM
>> To: Tony Arcieri
>> Cc:[e-mail]; Paul Lambert;[e-mail]
>>
>> Subject: Re: [Cfrg] Submission of curve25519 to NIST from CFRG -> was RE:
>> On "non-NIST"
>>
>>
>>
>>
>> On Mar 10, 2015 3:17 PM, "Tony Arcieri" <[e-mail]> wrote:
>> >
>> > I am very curious about this as well. It would make for a very confusing
>> > situation if NIST adopted different curves from the CFRG curves.
>> >
>>
>> and Brainpool, and the French and Chinese governments, and the Russians,
>> and the Brazilians.
>>
>> Standards fragmentation is a fact of life. But we should strive to
>> minimize it. And we shouldn't make it worse by varying endianess or encoding
>> for something that for 8 years was done a different way: there's no benefit
>> to doing it needlessly.
>>
>> > --
>> > Tony Arcieri
>> >
>> > _______________________________________________
>> > Cfrg mailing list
>> >[e-mail]
>> >http://www.irtf.org/mailman/listinfo/cfrg
>> >



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