Subject: Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG document

From: Alexey Melnikov <[email-masked]>
Date: Mon, 05 Jan 2015 19:55:43 +0000

On 14/12/2014 16:41, Alexey Melnikov wrote:
> Hi,
> This message starts 3 weeks adoption call for draft-ladd-spake2. 
> Please reply to this message or directly to CFRG chairs, stating one 
> of the following
>
> 1) that you are happy to adopt the draft as a starting point
> 2) that you are not happy to adopt this draft
> or
> 3) that you think the document needs more work before the RG should 
> consider adopting it
>
> While detailed document reviews are generally welcome, this not a call 
> to provide detailed comments on the document.
So far I have 4 people in favour of working on this and 3 against (some 
of these replied privately). I have emailed a few more, but I would like 
more feedback.

Thank you,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 05 Jan 2015 20:21:31 +0000

On 15/12/2014 18:19, Dan Harkins wrote:
> I'm in favor of another PAKE being documented but I'm not sure
> why SPAKE2 is the one.
I was asking about documenting SPAKE2. There is currently no intent in 
declaring it to be "the one". And if chairs decide to investigate 
declaring it the one, there would be another consensus call on the 
mailing list.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 5 Jan 2015 16:28:21 -0800 (PST)

> declaring it the one, there would be another consensus call on the

  Well if I am not already on the "work on this" side of the ledger
then please add me there; if you had placed me on the "don't work
on this" side then please move me.

  regards,

  Dan.

---

From: Paul Lambert <[email-masked]>
Date: Tue, 6 Jan 2015 10:30:48 -0800

Hi,
This message starts 3 weeks adoption call for draft-ladd-spake2. Please reply to this message or directly to CFRG chairs, stating one of the following

1) that you are happy to adopt the draft as a starting point
Starting point for what?  A definition of SPAKE2, or can we step back briefly and discuss requirements?
A PAKE is a building block … but not one with attributes that I’d recommend except for some very narrow use cases.

2) that you are not happy to adopt this draft
It might be a starting point for a PAKE, but is incomplete.  So, no.  However, it is worth discussing and improving if the goal is to provide a stable reference for SPAKE2.

3) that you think the document needs more work before the RG should consider adopting it
Yes. It’s missing:
 -  M and N definitions missing
 - Use of names and addresses in the calculation needs some work or rethink … again, what are requirements and what are we authenticating.
 - test vectors and wire formats
 - would be better if made into a more symmetric protocol and had a state machine definition

While detailed document reviews are generally welcome, this not a call to provide detailed comments on the document.
SPAKE2 has been used in industry.  Is the goal to document current practice?  That would lead to one set of comments.

Are we working to define a generally useful security protocol exchange with specific properties? That would be a different set of comments and perhaps more useful for long term impact.  I’d rather see energy spend on this topic than perpetuate PAKE based solutions, but this need not be mutually exclusive to defining SPAKE2.

Paul

Alexey,
On bahalf of CFRG chairs.

---

From: Tom Yu <[email-masked]>
Date: Tue, 13 Jan 2015 17:19:53 -0500

Alexey Melnikov <[email-masked]> writes:

>> This message starts 3 weeks adoption call for
>> draft-ladd-spake2. Please reply to this message or directly to CFRG
>> chairs, stating one of the following
>>
>> While detailed document reviews are generally welcome, this not a
>> call to provide detailed comments on the document.
> So far I have 4 people in favour of working on this and 3 against
> (some of these replied privately). I have emailed a few more, but I
> would like more feedback.

I'm sorry for not responding sooner.

I'm happy for the RG to adopt draft-ladd-spake2 as a starting point.  I
think it still needs additional work before publication, but not enough
to be a barrier to adoption.

To address some comments I've heard earlier, PAKE algorithms are still
interesting for protocols such as Kerberos, especially for zeroconf or
near-zeroconf situations.

-Tom

---

From: Andy Lutomirski <[email-masked]>
Date: Tue, 13 Jan 2015 14:21:28 -0800

> near-zeroconf situations.

I would like to see an augmented form published, too.  I don't know
whether it should be in this document or a different document.

--Andy

>
> -Tom
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

-- 
Andy Lutomirski
AMA Capital Management, LLC

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 19 Jan 2015 11:56:27 +0000

A minor point compared to choice of curve. Commenting on draft draft-agl-cfrgcurve-00, it indicates, in section 8 the use of little-endian order. RFC 5480 (obvious prior art in IETF) does not appear to specify big/little endianness, but delegates that to its reference SEC1. That document (http://www.secg.org/sec1-v2.pdf) in section 2.3.7 reverses the order of its x and M coefficients to produce a big-endian representation of an integer. Big endian format is also used by, for example, OpenSSL. Is the use of little endian format here a deliberate design decision?

-- 
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Alyssa Rowan <[email-masked]>
Date: Mon, 19 Jan 2015 12:27:15 +0000

On 19 January 2015 11:56:27 GMT+00:00, "Dearlove, Christopher (UK)" <[email-masked]> wrote:
> […] Is the use of little endian format here a deliberate design decision?

Probably yes, to match every existing implementation of Curve25519 already in the wild (and most commonly-used architectures)?

TLS WG give new curves free reign on point format, explicitly not SEC1 constrained. They preferred little endian (weakly) for the above reason, I believe?

- --
/akr

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 22 Jan 2015 18:34:43 +0000

> would like more feedback.
There a few more responses in favour of working on this item, so there 
is now a critical mass to take on this work.

Watson, can you please post the latest version you have as 
draft-irtf-spake2-00.txt.

Thank you,
Alexey

P.S. I got a private message that the PAKE requirement draft is being 
worked on. I don't know when this will appear, but there is some work 
being done.

P.P.S. CFRG chairs will shortly review and post results of the CFRG call 
about draft-agl-cfrgcurve-00. Stay tuned.

---

From: Adam Langley <[email-masked]>
Date: Thu, 22 Jan 2015 11:35:09 -0800

> A minor point compared to choice of curve. Commenting on draft draft-agl-cfrgcurve-00, it indicates, in section 8 the use of little-endian order. RFC 5480 (obvious prior art in IETF) does not appea…

(This appears to be a comment on draft-agl-cfrgcurve-00, but this
thread is otherwise about draft-ladd-spake2 which is why I didn't
notice it.)

Yes, the use of little-endian is a deliberate decision. It reflects
unanimous practice with the recommended curve. Also, I think there's a
general movement towards having crypto primitives specified as
functions on bytes strings rather than on more abstract concepts like
points (which I support).

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Paul Lambert <[email-masked]>
Date: Thu, 22 Jan 2015 11:59:01 -0800

On 1/22/15, 11:35 AM, "Adam Langley" <[email-masked]> wrote:

>> A minor point compared to choice of curve. Commenting on draft
>>draft-agl-cfrgcurve-00, it indicates, in section 8 the use of
>>little-endian order. RFC 5480 (obvious prior art in IETF) does not
>>appear to specify big/little endianness, but delegates that to its
>>reference SEC1. That document (http://www.secg.org/sec1-v2.pdf) in
>>section 2.3.7 reverses the order of its x and M coefficients to produce
>>a big-endian representation of an integer. Big endian format is also
>>used by, for example, OpenSSL. Is the use of little endian format here a
>>deliberate design decision?
>
+1
Yes, given the diversity of uses, protocols and formats. Opaque encodings
make the most sense.
The encoding/decoding would be a method tied to the specific
algorithm/protocol/cipher suite.

Paul

---

From: Paul Lambert <[email-masked]>
Date: Fri, 23 Jan 2015 13:44:00 -0800

The draft-irtf-cfrg-spake2-00.txt text says:

   Both A and B calculate a group element K. A calculates it as x(S-wN),
   while B calculates it as y(T-wM). A knows S because it has received
   it, and likewise B knows T.

How does A know to use N and B to use M?

The protocol is not symmetric and the different values define different roles in the protocol.

What happens if both sides pick the same value?

Can the protocol specification be made symmetric ...

Also in the draft:

   Note that
   the choice of M and N is critical: anyone who is aware of an x such
   that xN=M, or xG=N or M can break the scheme above.

By 'anyone', does that include party A in its choice of N?
If A picked x and knew that xG=N is it still a issue?

Paul

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 23 Jan 2015 14:44:10 -0800 (PST)

On Mon, January 19, 2015 4:27 am, Alyssa Rowan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Probably yes, to match every existing implementation of Curve25519 already
> in the wild (and most commonly-used architectures)?

  So a long-standing tradition of the on-the-wire format is changed because
of the way the first curve25519 library was written? That's a weak
justification.

  Dan.

> TLS WG give new curves free reign on point format, explicitly not SEC1
> constrained. They preferred little endian (weakly) for the above reason, I
> believe?
>
> - --
> /akr
> -----BEGIN PGP SIGNATURE-----
> Version: APG v1.1.1
>
> iQI3BAEBCgAhBQJUvPgjGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
> jtkWi2t6zMYP/1zfZqPArx93uuddYNhL3FoApKh8rUmpJydhlVfAenxK7pfT7FjC
> 17g2xFE5dHdA+RZEduf4YDqvQHN8DUWFe9v/pQtq/ev6Ety66CsBG1PV/sQ2hF7f
> 474TKgp9S5ADndNttzD+AZx7JG1xiwvPoXp5BtY86R8tPNG+sfnOB+4Vxl9F7XPC
> Cboi942fAlO4F5WxFxJhb8ZY0O9B0MDtfKZVg3SEkyZq+moGGjVwndlcBa26e5+S
> iKQeyEXl1yGthSt3Pp7WGFnhu86Ul6/2cC1FmlmOTpXu8RRW3idvwF8Au5VJaJ5s
> JEYRAN1FrT9U6Bdrjfs5VZHeQkhSK0jzRlnRFD2VsyBClRwmFDmuODiqJoWkiYHX
> qTuZOwvyyqLFgAXgwm+uovTkIjrgKWam66G2ptAUacV3cqhiX0/VdGJIk+Hw2xTd
> C95oSiIMw5vHQWuUWvCVh4s7G2kf5+nf930c3MRm4q1IdlFihvjVuLTP0uS8YMgb
> 5EI/kpCEso6d3foVUTkTbLbe9rXm1AJtL9N7QJ1KdKGXtsHmhMkFjPijE1B3qvB4
> aRzjEGoVV48j3yxM68SjyV38TgqvMwzi2qmoXZGeBocynIq+jT05F+d8K3ibUCgV
> 2ZrKaWIinQs4JQ5Meu3UE0IMcpBQQ0/YE/XE4Y6AUWjyde/mR6nHE+F5
> =RTzy
> -----END PGP SIGNATURE-----
>

---

From: Watson Ladd <[email-masked]>
Date: Fri, 23 Jan 2015 17:10:12 -0800

On Jan 23, 2015 2:44 PM, "Dan Harkins" <[email-masked]> wrote:
> >> [â€¦] Is the use of little endian format here a deliberate design
> >> decision?
> >

And this breaks what exactly? Picking big endian means picking a different
name at a minimum to avoid confusion. It means that already deployed SSH
installations either change or confuse everyone. It means that all existing
implementations become unusable, despite extensive review and verification
efforts.

What is actually gained from using big-endian?

Sincerely,
Watson Ladd

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 24 Jan 2015 16:18:10 +0000

> of the way the first curve25519 library was written? That's a weak

Strongly disagree.  But this is a religious argument and the sides will probably never come to terms.  On the one hand we have tradition. On the other we have a large deployed base.  Within the IETF canon of rough consensus and running code, which argument will win?  Which argument should win?  The IETF should follow its tradition and drop its wire format tradition.

The reformation is coming:  fixed on the wire curve formats are gone; it is now up to each curve to specify its wire rep.

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 24 Jan 2015 21:14:12 -0800 (PST)

On Sat, January 24, 2015 8:18 am, Salz, Rich wrote:
> Strongly disagree.  But this is a religious argument and the sides will
> probably never come to terms.  On the one hand we have tradition. On the
> other we have a large deployed base.  Within the IETF canon of rough
> consensus and running code, which argument will win?  Which argument
> should win?  The IETF should follow its tradition and drop its wire format
> tradition.

  To me it's not a religious argument. But when you just say "strongly
disagree" without any justification for making such a statement then
perhaps I guess I can see how it is religious for you.

  Endianness is the lowest of low levels. It is handled by a function that
is #define'd around an #ifdef LITTLE_ENDIAN in some _common_ include
file. Then everything reading and writing to the network has ntoh_whatever()
routines that call the #define'd function. It makes for portable code.
The alternative is to put endianness knowledge into the crypto library
and have "if (religion) then if (big endian) then foo else bar fi else
ntoh_foo fi". Which is something to which I strongly disagree. Better to
just say "ntoh_foo".

  I remember when the discussion of curve25519 started one of the
proponents mentioned that the idea of many people writing code to
implement it was not necessary, and was unwise, and that everyone
should just use the existing library. And it's that idea that prompted my
statement. We should just change our endianness practices, which make
better looking and more maintainable code, because whoever wrote The
Definitive Reference Implementation of Curve25519 choose little endian
and everyone is just expected to use that. Why? Because.

> The reformation is coming:  fixed on the wire curve formats are gone; it
> is now up to each curve to specify its wire rep.

  And yet counter-reformation was much more grand and beautiful
and majestic as compared to the cold, boring, puritan, calvinist
reformation. Really, it's not anything that needs to be repeated.

  Dan.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 24 Jan 2015 22:00:43 -0800

> ntoh_foo fi". Which is something to which I strongly disagree. Better to

Really? Because if you look at DJB's code you will see that it is
host-endian independent. Maybe your code casts (*char) to (*int) in
contravention of the C standard (yes, really: the proper type punning
is via unions), but it is entirely possible to avoid needing to do
this via shifts and legitimate casts.

> and everyone is just expected to use that. Why? Because.

OpenBSD had no problem adopting this: I doubt they lower standards for
maintenance then you do. Besides, you probably don't know how to write
C as well as DJB, and you almost certainly don't know as much about
making secure implementations as he does. Your code will not receive
anything close to the man-decades of review and automated testing that
some Curve25519 implementations have.

> reformation. Really, it's not anything that needs to be repeated.

Edwards curves could have been shoehorned into the SEC1 formats by
using the isomorphic Weierstrass form. Is that what you want? Or do
you want some other curve format (like x-coordinate Montgomery
little-endian) for all the new curves (of which we only have 1 right
now)?

Sincerely,
Watson Ladd

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

---

From: "D. J. Bernstein" <[email-masked]>
Date: 25 Jan 2015 08:30:18 -0000

> a long-standing tradition of the on-the-wire format

Just to make sure that I understand, after reviewing a ton of tcpdump
output: You're referring to the HTTP tradition of variable-length ASCII
decimal encodings for integers on the wire (cache times, data lengths,
version numbers, etc.)? Does this mean that IETF pushed this HTTP
tradition into AES-GCM's internal integer encodings before deploying
AES-GCM, and plans to do the same for other cryptographic systems?

> better looking and more maintainable code

You're absolutely right: being able to reuse existing variable-length
ASCII decimal integer encoders and decoders has always been a critical
part, I daresay the most important part, of implementing, reading,
auditing, and maintaining cryptographic software. RFC 1321 (MD5) got
this totally wrong---the integers are _backwards_ and _non-decimal_ and
_non-ASCII_---and we all know what happened to MD5 as a result.

Now that you've reminded me of what really matters for cryptographic
code complexity and security, I would love to put together an ASCII
decimal version of Curve25519, but I have to admit that I'm not
_completely_ clear on the details of the HTTP tradition that you're
talking about. For example, are leading zeros allowed? This would allow
simpler integer encoding for some embedded systems, but it would cause
trouble for existing parsers that switch to octal for a leading 0, such
as base-0 strtol(). Also, can the integers exceed 2147483647?

---Dan

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 25 Jan 2015 09:48:14 -0800 (PST)

> AES-GCM, and plans to do the same for other cryptographic systems?

  No, you could not be more wrong in that assumption.

> as base-0 strtol(). Also, can the integers exceed 2147483647?

  Do you want to be taken seriously when you respond like this?

  Dan.

---

From: Mike Hamburg <[email-masked]>
Date: Sun, 25 Jan 2015 10:26:10 -0800

I think that this is actually an interesting question, so maybewe can
put aside religion and mockery thereof for little bit...

Does anyone know of existing code which processes cryptography over
multiple fields using a generic bignums package (hopefully with fixed-size
bignums for timing resistance), and would be complicated by inconsistent
endian practices in a new curve?  If so, it might be worth considering a
consistent endian.

Otherwise, I don't see why it really matters. Feel free to try to convince
me, but make sure you compose your post using Emacs and not vi.

However!  I think it's very strongly preferable that point formats and
signatures should contain a fixed number of bytes on a given curve.
(Perhaps allowing different sizes for compressed points, but leading zeros
*should not be stripped*.)  That way points and signatures can go into
structs instead of using some awful ASN.1 TLV format.

Cheers,
-- Mike

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 25 Jan 2015 19:47:45 +0000

> endian practices in a new curve?  If so, it might be worth considering a

OpenSSL.  I'm on the dev team.  But we want the interop and efficiency of the X25519 defined wire rep.

I apologize if I offended anyone (esp Dan)by my note.  I don't find tradition a compelling argument.  Especially since for X25519, you just do a buffer-copy from the network buffer into the crypto buffer.  Much less work.

---

From: Watson Ladd <[email-masked]>
Date: Sun, 25 Jan 2015 12:35:57 -0800

> endian practices in a new curve?  If so, it might be worth considering a

Both NSS and OpenSSL have a bignum library underlying ECC operations,
but I don't know how often that gets used in practice vs per curve
optimized implementations. But we're talking about swapping bytes in a
serialization function: it's a potential wart, but a small one. If we
do reverse endianness, then what SSH is already doing won't be
included.

The fact that actual developers making actual projects don't consider
this a problem should register.

> structs instead of using some awful ASN.1 TLV format.

SEC1 does this for points, but not signature elements. I agree that we
should used fixed-length whenever possible.

---

From: Andrey Jivsov <[email-masked]>
Date: Sun, 25 Jan 2015 12:51:16 -0800

> OpenSSL.  I'm on the dev team.  But we want the interop and efficiency of the X25519 defined wire rep.

I don't have strong opinion regarding the format, primarily because 
there is no efficiency argument here.

If you consider Curve25519, the two implemetnations I looked at 
curve25519-donna and more optimized X25519 from 
http://www.ietf.org/mail-archive/web/cfrg/current/msg05247.html unpack 
the public values byte-by-byte. An implementation with delayed reduction 
will have uneven boundaries between wire format and an internal 
representation, and so this is expected.

It would be trivial to tweak the implementation to assign input bytes to 
different target positions (and use different constants in shifts) for 
identical performance / code size.

If an implementation does something like 4-to-4, or 8-to-8 mapping, most 
platforms, x86 in particular, have instructions like bswap to take care 
of this.

Is there evidence that matching endianess has any performance impact?

---

From: Alyssa Rowan <[email-masked]>
Date: Sun, 25 Jan 2015 21:12:10 +0000

On 24/01/2015 16:18, Salz, Rich wrote:

>> [DH] So a long-standing tradition of the on-the-wire format is
>> changed because of the way the first curve25519 library was
>> written? That's a weak justification.

So all the running code in every X25519 library out there (there are
several) should change its on-the-wire format because of the way some
other earlier wire protocols (with explicitly no relation to this one,
as Rich mentions) were written? ¬_¬

> [RS] The IETF should follow its tradition and drop its wire format
> tradition.

Agreed. To the extent it matters, there's no justification for
changing the X25519 wire format to big-endian at all; it'd just be
gratuitous incompatibility with existing libraries for no reason if we
did. I might not put it quite as sarcastically as djb, but I am not a
fan of that. Running code wins: and that's little-endian.

- -- 
/akr

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 25 Jan 2015 21:49:48 +0000

> I don't have strong opinion regarding the format, primarily because there is
> no efficiency argument here.

Perhaps.  So if there is no efficiency, why break existing deployments?  So far I've heard tradition, and I've heard common code re-use.

---

From: Damien Miller <[email-masked]>
Date: Mon, 26 Jan 2015 14:55:50 +1100 (EST)

On Sun, 25 Jan 2015, Mike Hamburg wrote:

> multiple fields using a generic bignums package (hopefully with
> fixed-size bignums for timing resistance), and would be complicated by
> inconsistent endian practices in a new curve? If so, it might be worth
> considering a consistent endian.

We (OpenSSH) adopted the little-endian encoding from djb's ECDH
curve25519 and Ed25519 as specified despite all other SSH wire bignums
being encoded as big endian. We were happy to be able to use the
existing high quality and well-reviewed implementations. This more than
justified the small inconsistency.

The inconsistency is really just minor aesthetics - the wire values
are opaque to everything but the implementation of the primitives
themselves; it doesn't matter to the application at all.

-d

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 25 Jan 2015 22:31:01 -0800 (PST)

On Sun, January 25, 2015 12:35 pm, Watson Ladd wrote:
>> fixed-size

  Yes Mike, there are numerous crypto libraries, both open source and
proprietary, that use a generic bignum package. And it is that "might be
worth considering" that is making me raise this issue.

> do reverse endianness, then what SSH is already doing won't be

  Warts are ugly. And if small warts are not a concern then let's just
leave SSH with a wart and everyone else can be wart-free.

> this a problem should register.

  Well this actual developer making actual projects considers this a
problem. The argument from Rich is that he's OK with curve25519
being a special case because of he wants to interop with some existing
implementations. And I guess that's the difference. Aside from SSH
(which will have "a potential ward, but a small one") I don't see
a large number of protocols implemented with this format that
make this change compelling.

  Dan.

---

From: Mike Hamburg <[email-masked]>
Date: Sun, 25 Jan 2015 22:42:21 -0800

> worth considering" that is making me raise this issue.
This is only half an answer.  I'm well aware that many crypto libraries 
use generic bignum packages.  But will the endian complicate the 
implementation of the new curves?  That is, do they lack little-endian 
serialization code?  Or is their EC point codec generic enough to handle 
Montgomery/Edwards point formats over whatever field, and yet not 
generic enough to pass a little-endian flag?

I mean, if some real library will need to byte-reverse a buffer, then 
that's a wart, if only a minor one.  If it will need to pass -1 instead 
of 1 to bn_export in a newly-written serialization routine, then this 
really just doesn't matter at all.

Cheers,
-- Mike

---

From: Watson Ladd <[email-masked]>
Date: Sun, 25 Jan 2015 22:56:15 -0800

> worth considering" that is making me raise this issue.

I've never seen a big-endian bignum library: everyone uses
little-endian internally for the calculations, so there already is a
forced reordering.

> leave SSH with a wart and everyone else can be wart-free.

You're ignoring the large costs of confusion between people who think
Curve25519 has big endian because the CFRG said so, and Curve25519 has
little-endian because tweetnacl.c or tweetnacl.js says so.

> make this change compelling.

I don't think this is a real problem for several reasons:

-Curve25519 defines a single scalar mult function. It's easy to fold
any endian conversions into this function at the beginning and end.
-If you don't export this function, but instead force a separate
deserialization and reserialization step before and after, you can put
those swaps there instead
-If deserialization and serialization don't know what curve they are
on, because you assume Weierstrass, your scalarmul code must know and
could change it.
-If your scalarmult code doesn't know, how is that possible? You can
write something with a and p as parameters, but this won't work for
Curve25519 even if we change the endianness.

Of course, you could simply use tweetnacl.c or the implementations in
NaCl and trust that someone else solved all those problems.

Sincerely,
Watson Ladd

---

From: Yoav Nir <[email-masked]>
Date: Mon, 26 Jan 2015 08:57:39 +0200

> On Jan 26, 2015, at 8:31 AM, Dan Harkins <[email-masked]> wrote:
> 
> 
> 

All other things being equal, yes, consistent is better than not. But really, it’s not difficult to add functions like BN_bin2bn_le() and BN_bn2bin_le() to OpenSSL which makes both kinds of on-the-wire encoding equally easy to implement. There is little benefit in carrying over an optimization from the days when the dominant platform for doing things on the Internet was Solaris running on Sparc CPUs. By far the most dominant hardware platforms today are Intel and ARM, and both of them are little-endian. No, ntohl() is not a resource-intensive operation, but to avoid needing it is better than to not avoid it. Also, calling this function (or macro) that was short-sighted. It assumed that everything on the network would be big-endian. It should have been called big2internal(). 

> leave SSH with a wart and everyone else can be wart-free.

converting from wire format to local format is always a wart. You can only be wart-free if you have a unified design for everything from the start. That’s not the way the Internet came to be as evidenced by the fact that we’re still writing RFCs. There are warts everywhere, and this one doesn’t make it worse.

> make this change compelling.

In a 3-month project to add curve25519, this represents less than an hour of extra work. It’s in the noise.

Yoav

---

From: Michael Clark <[email-masked]>
Date: Mon, 26 Jan 2015 17:37:11 +0800

On 26/1/15 5:12 am, Alyssa Rowan wrote:
> So all the running code in every X25519 library out there (there
> are several) should change its on-the-wire format because of the
> way some other earlier wire protocols (with explicitly no relation
> to this one, as Rich mentions) were written? ¬_¬
> 
>> [RS] The IETF should follow its tradition and drop its wire
>> format tradition.
> 
> gratuitous incompatibility with existing libraries for no reason if
> we did. I might not put it quite as sarcastically as djb, but I am
> not a fan of that. Running code wins: and that's little-endian.

Can't we just define point formats with '_le' suffix?

software still needs to consider endianness as these libraries are
likely to be ported to big endian systems (< power8, < sparc9, etc),
but nowadays big endian should perhaps pay the bswap price (however
sadly the older systems are the slower ones). "network byte order"
loses some meaning. format names should then become endian explicit.

the bignum libraries would typically have limbs in host-endianness,
and it makes sense for scalar growth that they store vectors of limbs
little end first, but they could be either big or little endian host
words packed little word first in memory. it is host dependent.

(example 128)

32-bit limbs on a little-endian system (memory representation):

  (limb0_le32), (limb1_le32), (limb2_le32), (limb3_le32)
   0x80000000 ,  0x00000000 ,  0x00000000 ,  0x00000000

32-bit limbs on a big-endian system (memory representation):

  (limb0_be32), (limb1_be32), (limb2_be32), (limb3_le32)
   0x00000080 ,  0x00000000 ,  0x00000000 ,  0x00000000

the natural composition of little endian limbs and little limb first
(2nd order bignum endianness) on a little endian system ends up being
byte-level little endian big nums, so yes little endian representation
is more efficient on modern systems.

on the other hand, with fixed-size bignums (for timing resistance)
where you know the size in advance, it would be possible to use big
word/limb first but the memory access pattern might be non-optimal.
suspect most bignum code is designed with little word/limb first for
scalar growth (and fixed size is essentially a subset or variable size).

this however is besides the point. as people indicate, these are
internal implementation details, and an implementation can serialize
and deserialize numbers before and after any computation.

big-endian still exists however it makes a reasonable amount of sense
for a new wire-format to make the (now less common) big-endian systems
pay the bswap price and use little endian on the network.

the other thing to remember is there is also base 2 little endian; or
bit reflection, versus what we call little endian (byte-level little
endian). see {Bit Reflection Peculiarity of GCM}. However in the case
of GCM, this is opaque so is not an issue. Just want to point out
there is another endianness. In bit reflection (or base 2 le) the
above example would = 1 not 128.

the swizzle code is already there, just it doesn't have a conditional
on it. If there are _le point formats then all the bswaps will eval to
nothing on the systems that are the most common today.

X25519 will likely be ported to big-endian systems?

if it isn't "network byte order" then endianness should be explicit in
a point format name i.e. add "_le" suffix. rationale for old names :-D

as developers, we will still need the bswaps in there either way, even
in the little-endian case where they the macros will evaluable to
nothing, assuming the code gets ported to < power8, < sparc9, etc

a shrewd strategy is send the endianness of your platform and have le
point format. You pay no price for this strategy unless the other end
is big endian. So make little endian point formats.

endianness is a pain. We need a <stdenian.h> in ISO C17, and
<cstdenian> in C++17. WIP. This still needs to emit BSWAP asm on MSC.

  http://austingroupbugs.net/view.php?id=162
  https://gist.github.com/michaeljclark/3b4fd912f6fa8bb598b3

endianness will need to be dealt with for some time to come,
especially in network code where everything is still "network byte order"