Subject: Re: [Cfrg] Point format endian

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 19 Jan 2015 13:09:20 +0000

I managed to pick the wrong posting to followup, hence the wrong reference in header (now removed).

That's fine, I wanted to be clear if this was deliberate. It's not without cost, but nothing is.

-- 
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

-----Original Message-----
From: Alyssa Rowan [mailto:[email-masked]] 
Sent: 19 January 2015 12:27
To: Dearlove, Christopher (UK); Alexey Melnikov; [email-masked]
Subject: Re: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

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

********************************************************************
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: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 26 Jan 2015 11:08:50 +0000

Alyssa Rowan
> They are NOT bignums. As per TLS WG discussion, all new curves' wire formats are opaque octet strings.

They may be opaque to TLS, but here people actually need to manipulate them, and  the draft that's being discussed here actually uses the words little endian. That's a number.

Having opened this can of worms, it was to ask if this was a deliberate decision. It was. Open to people to agree or disagree, I just was a little surprised and wanted to check.

There are several layers to representation,  when not able to consider it as opaque. Mathematical entity, octet pattern (including endianness, but also things like rules for leading zeros) and framing (e.g. the 04 in SEC1 for uncompressed elliptic curve points in affine form). Here we need all of those (I'm not suggesting we don't have them).