Re: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)

[Andy Lutomirski <[e-mail]>]

On Tue, Jan 27, 2015 at 8:41 AM, Dan Harkins <[e-mail]> wrote:
>
>
> On Tue, January 27, 2015 3:16 am, Stephen Farrell wrote:
>>>>
>>>> But seriously, if in fact this makes little or no difference, which I
>>>> believe
>>>> is the case, and which I believe you are also arguing, then what is the
>>>> problem with going with the initial coder's choice here?
>>>
>>> Because, as I've already pointed out in an earlier message, if the
>>> universal
>>> standard is big-endian and the vast majority of your potential user base
>>> (via
>>> OpenSSL, not sure about MS CryptoAPI) only does big-endian, then
>>> choosing a
>>> format that's not big-endian is a really bad idea.
>>
>> You didn't say why. Why is it a bad idea? What is the downside?
>> ("only does big-endian" isn't it clearly, because if the little
>> endian form were adopted here that'd no longer be true so the
>> question is how that'd cause problems if the spec called for it
>> to be done.)
>>
>> I'm really asking there and not point-scoring btw. mostly because I
>> think this entire process has been quite fraught about even the
>> least important things, and I'd hope we don't do that to ourselves
>> again;-)
>
>   It's a bad idea because standards like X9.62 and ISO/IEC 15946
> and RFC 5090 have all defined the way to go from a bitstring to an
> integer to a field element and back that involve representation in
> big endian. This is the canonical conversion between bit strings
> and elements.

This is not a good thing.  I've worked on software that manipulates
P-256 public keys.  They're *variable length* because someone thought
that this was a good idea.

>
>   And this is not some arbitrary issue that can just be relegated to
> the bowels of the crypto library where we no longer care. Knowledge
> of the special-case-ness of curve25519 will percolate up to the
> application writer. For instance,
>
>   * After doing an ECDH you take the X-coordinate and pass it to
>     a KDF. But how? Well, there's those rules to go from field element
>     to integer to bitstring. Except now you have to have a special case.
>     So you do BN_bn2bin() unless it's curve25519 then you do
>     BN_bn2binle() (which doesn't exist now for a very good reason).

Sorry, but this is backwards.

As an application writer, I want to pass a string of bytes into the
bowels of the crypto library, and I want to get a string of bytes
back.  I despise the fact that, with current crypto, I have to parse
some ASN.1 crap to figure out *how many* bytes to pass to the crypto
library.

Given a choice between using ASN.1-encoded numbers (or sequences or
whatever) and strings of bytes of either endianness, I'll take the
byte strings any day.

(Also, it's 100% unambiguous how to pass octet strings into a KDF,
given that they all seem to operate, quite sensibly, on bytes.  It's
not at all unambiguous how to pass numbers to a KDF, on the other hand
-- are they big-endian zero-padded?  are they big-endian
variable-length with MSB zeros stripped?  maybe there's a length
prefix?  maybe that prefix is ASN.1?  if so, how is it encoded?)

--Andy