Subject: [Cfrg] Elliptic Curves - byte order (ends on March 25th)

From: Alexey Melnikov <[email-masked]>
Date: Thu, 19 Mar 2015 18:33:41 +0000

CFRG chairs are starting discussion of the next topic:

Q5: Implementations of curve 25519 are using little-endian byte order 
(http://en.wikipedia.org/wiki/Endianness). This is a poll where you can 
choose one of the following 3 options:

1) Use little-ending byte order for both curve 448 and curve 25519
2) Use little-ending byte order for curve 25519, but use big-endian 
(a.k.a. network byte order) for curve 448
3) Use big-endian for both curves 25519 and 448.

You can motivate your choice, but please be brief.

Please don't discuss any other topic in this thread.

---

From: Michael Hamburg <[email-masked]>
Date: Thu, 19 Mar 2015 11:35:11 -0700

I prefer little-endian order for both.

> On Mar 19, 2015, at 11:33 AM, Alexey Melnikov <[email-masked]> wrote:
> 
> Q5: Implementations of curve 25519 are using little-endian byte order (http://en.wikipedia.org/wiki/Endianness). This is a poll where you can choose one of the following 3 options:
> 
> 2) Use little-ending byte order for curve 25519, but use big-endian (a.k.a. network byte order) for curve 448
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: Watson Ladd <[email-masked]>
Date: Thu, 19 Mar 2015 11:36:48 -0700

1 or 2 is fine with me. 3 is right out.

On Mar 19, 2015 11:35 AM, "Michael Hamburg" <[email-masked]> wrote:
> > Q5: Implementations of curve 25519 are using little-endian byte order (
http://en.wikipedia.org/wiki/Endianness). This is a poll where you can

---

From: Tony Arcieri <[email-masked]>
Date: Thu, 19 Mar 2015 11:42:03 -0700

> I prefer little-endian order for both.

+1 for #1

-- 
Tony Arcieri

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 19 Mar 2015 20:50:18 +0200

> You can motivate your choice, but please be brief.

1. Little-endian for both.

- Existing high-quality implementations of 25519 are little-endian.
- (existing 448 implementations seem to be little-endian too).
- Majority of systems connected to the Internet are natively little-
  endian nowadays.
- Little-endian seems more natural when actually implementing (things
  chain to higher indices).
- You really don't want to use bigints, as you tend to get side
  channels out the wazoo. Oh, and also rare failures.

-Ilari

---

From: Alyssa Rowan <[email-masked]>
Date: Thu, 19 Mar 2015 19:22:04 +0000

> 1) Use little-ending byte order for both curve 448 and curve 25519

1, little-endian.

• Existing practice for Curve25519.
• Last I checked every core I had around was little-endian or bi-endian.

- -- 
/akr

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Mar 2015 19:36:42 +0000

> 2) Use little-ending byte order for curve 25519, but use big-endian

I choose 2.5) Use little-endian for 25519 to not pointlessly break
stuff, and I don't care for 448 since I think there's no significant
running code to break

S

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 19 Mar 2015 20:54:21 +0100

Hi,

> 1) Use little-ending byte order for both curve 448 and curve 25519

+1.

Aaron

---

From: Adam Langley <[email-masked]>
Date: Thu, 19 Mar 2015 13:04:32 -0700

> You can motivate your choice, but please be brief.

#1 : Little-endian has, in practice, won and existing curve25519
practice requires little-endian in that case. Using little-endian for
Goldilocks is then both sensible de-novo and parsimonious.

Cheers

AGL

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

---

From: Sean Turner <[email-masked]>
Date: Thu, 19 Mar 2015 16:21:05 -0400

> stuff, and I don't care for 448 since I think there's no significant

This pretty much sums up my feelings.

spt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Mar 2015 16:29:48 -0400

> stuff, and I don't care for 448 since I think there's no significant

Me too..

Though I don't quite see how this is a CFRG issue since the math does
not have an endian-ness issue and the order of bits on the wire is a
TLS decision.

When we get to signatures and certificates, the PKIX standard says
big-endian and that is the end of the matter. So we really need to
limit the damage and follow the IETF and X.509 standard for 448 to
keep things consistent.

---

From: Adam Langley <[email-masked]>
Date: Thu, 19 Mar 2015 13:46:04 -0700

> not have an endian-ness issue and the order of bits on the wire is a

We're not cutting the abstraction layer at the level of integers,
rather this specification takes bytestring inputs and outputs. That's
why it's a decision here rather than in CFRG.

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Thu, 19 Mar 2015 13:46:25 -0700

> why it's a decision here rather than in CFRG.

s/CFRG/TLS/, of course.

AGL

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Mar 2015 20:55:40 +0000

> #1 : Little-endian has, in practice, won and existing curve25519 practice
> requires little-endian in that case. Using little-endian for Goldilocks is then
> both sensible de-novo and parsimonious.

Ooh, somebody just got a dictionary app.

But +1

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 19 Mar 2015 14:00:15 -0700

On Thu, Mar 19, 2015 at 1:46 PM, Adam Langley <[email-masked]>
wrote:

> [Joe] yup, it would be good if different protocols do things in the same
way.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 19 Mar 2015 21:03:07 +0000

On Thu, Mar 19, 2015 at 01:46:25PM -0700, Adam Langley wrote:

> > why it's a decision here rather than in [TLS].

Thanks, that's how I see it too.  And in particular, the signature
and public key format in certificates remains open for discussion.

While X.509 (ASN.1) integers are big-endian, X.509 bytestrings can
encapsulate opaque input to a signature verification algorithm,
which *that* algorithm may internally interpret as a little-endian
encoding of a pair of fixed length points, a compressed point, etc.
However, at the X.509 layer the data can remain opaque.

The signature algorithm (whose specifics are not yet under discussion)
might then be defined to expect bytestring inputs in certificate
public key and signature fields and generate bytestring outputs
for inclusion in such fields.

-- 
	Viktor.

---

From: Adam Langley <[email-masked]>
Date: Thu, 19 Mar 2015 14:05:46 -0700

> Ooh, somebody just got a dictionary app.

I protest that, as a British person, dictionaries are not required for
such quotidian vocabulary. There's a reason why we grow up listening
to Radio 4.

Cheers

AGL

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 19 Mar 2015 14:20:43 -0700 (PDT)

> 3) Use big-endian for both curves 25519 and 448.

  As much as I would like #3 for all the entirely sensible reasons I
already gave :-) I admit I've lost that battle, so I say #2.

  Dan.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Mar 2015 21:20:59 +0000

> I protest that, as a British person, dictionaries are not required for such
> quotidian vocabulary. There's a reason why we grow up listening to Radio 4.

Quotidian?  Now you're just showing off, which is very un-British.

The sun never sets...

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Mar 2015 17:25:03 -0400

> Quotidian?  Now you're just showing off, which is very un-British.

No, you are just one of the few Americans who can recognize how Brits show off.

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 Mar 2015 16:53:24 -0500

On Thu, Mar 19, 2015 at 06:33:41PM +0000, Alexey Melnikov wrote:
> Q5: Implementations of curve 25519 are using little-endian byte
> order (http://en.wikipedia.org/wiki/Endianness). This is a poll
> where you can choose one of the following 3 options:
> 

Little-endian for Curve25519 (because it's already in use and endianness
here is mostly about performance).

In all other cases we should pick whichever endianness gets the best
performance on the most devices.  That's mostly little-endian (because
of x86_64 and ARM), though I suppose there might be a great many
embedded devices in the future using CPUs that are neither bi-endian nor
little-endian, but that seems unlikely.

So, (1) little-endian across the board.

Nico
--

---

From: Alyssa Rowan <[email-masked]>
Date: Thu, 19 Mar 2015 22:06:24 +0000

On 2015-03-19 21:03, Viktor Dukhovni wrote:

> …X.509 bytestrings can encapsulate opaque input to a signature 
> verification algorithm, which *that* algorithm may internally 
> interpret […] However, at the X.509 layer the data can remain 
> opaque.
> 
> The signature algorithm (whose specifics are not yet under 
> discussion) might then be defined to expect bytestring inputs in 
> certificate public key and signature fields and generate
> bytestring outputs for inclusion in such fields.

Yes! Less X.509/ASN.1 junk in our crypto primitives is a Good Thing™!

Whatever our signature format will be, we should do this with it.

- -- 
/akr

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Mar 2015 15:23:43 -0700

1

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 Mar 2015 19:58:16 -0500

> Whatever our signature format will be, we should do this with it.

Yes, but we need to be able to cast the crypto primitives' keys into
something the application layer can deal with without having to special
case each curve.  The obvious thing to do is to say that these keys are
all octet arrays (fixed-length) or octet strings (variable length) and
then let the application layer do any necessary massaging into INTEGER
or BIT STRING or what have you types and encodings -- this need only
round-trip, and there is no need to make a CurveXYX public key appear to
be an INTEGER or anything else.

Nico
--

---

From: Damien Miller <[email-masked]>
Date: Fri, 20 Mar 2015 13:25:12 +1100 (AEDT)

On Thu, 19 Mar 2015, Alexey Melnikov wrote:

> (http://en.wikipedia.org/wiki/Endianness). This is a poll where you can choose
> one of the following 3 options:
> 

both little-endian.

motivation: little endian for compat with deployed c25519. little endian
for c448 for consistency with c25519.

---

From: Paul Lambert <[email-masked]>
Date: Thu, 19 Mar 2015 19:51:47 -0700

>> 3) Use big-endian for both curves 25519 and 448.

I prefer any-endian Š as long as they are both the same for this exercise,
so:

1 or 3

---

From: David Gil <[email-masked]>
Date: Fri, 20 Mar 2015 22:08:40 +0000 (UTC)

Little-endian.
 
- dlg 

On Thursday, March 19, 2015 11:35 AM, Alexey Melnikov <[email-masked]> wrote:
CFRG chairs are starting discussion of the next topic:

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 31 Mar 2015 04:15:03 +0100

On 19/03/2015 18:33, Alexey Melnikov wrote:
> (http://en.wikipedia.org/wiki/Endianness). This is a poll where you 
> can choose one of the following 3 options:
>
12 people in favour of this choice.
> (a.k.a. network byte order) for curve 448
2 people in favour of this choice.
> 3) Use big-endian for both curves 25519 and 448.
Nobody in favour of this choice.

Additionally, 4 people in favour of either 1) or 2)
1 person in favour of 1) or 3)

So in summary: there is clear enough preference for choice #1.

I would ask people to stop discussing this topic in another thread 
started by Phillip Hallam-Baker, as it seems at this point people just 
recycling arguments they've made earlier. And Stephen also commented 
that CFRG participants should not speculate on how IESG will respond to 
use of little-endian in TLS and other places.

Best Regards,
Alexey, on behalf of chairs.