Integer endianness

[BasileiosKal]

As noted by @mikelodder7, in the document we don't yet discuss the integers (i.e., scalars mod r) serialization. More specifically, since we have a description for the byte length of those integers (octet_scalar_length), what is missing is the byte order.

In general i thing little-endian is preferred (it is mostly used in bls libs like the rust crate and blst) but an issue is that I2OSP uses big-endian if im not mistaken.

There are 3 options i can think of;

1. We describe them as 32 bytes (or octet_scalar_length in general) in little-endian, with a note for I2OSP.
2. We describe them in a way similar to some libs (i.e., four 64 bit parts in little-endian order), but i don't think something like that is suitable.
3. We leave it up for implementers with some notes for guidance.

At the moment I'm leaning more towards option 3. Implementations may elect to use any kind of optimization and this will allow for that.

Also for what i know of, other specs like ecdsa and eddsa elect to define the integer's endianness but specs like bls-sigs and h2c adopt option 3, so it does not seem to be any "absolutely correct" way to do that.

[BasileiosKal]

Discussed in the WG call on 2022-06-27. The direction decided is to check available implementations and either ad a note in the definition of OS2IP and I2OSP, describing that they operate in big-endian order (like H2C) or define a scalar_to_octets operation, that on input a scalar will return an octet string in litle-endian order (just a definition possible with no explicit procedure).

[tplooker]

Discussed on WG call 8th of august, there is currently ambiguity around the endianness of scalar_to_octets that needs to be resolved.

[tmarkovski]

I ran into this issue as I was going through spec implementation and validating against the provided fixtures. Has there been a decision made? I think at minimum, the fixtures should specify the byte order of the scalar.

[mikelodder7]

In practice, not a decision here, whenever hexits or base64 are given it represents big endian.

[mikelodder7]

If we give the actual bytes then little endian is preferable

[tmarkovski]

If we give the actual bytes then little endian is preferable

The SignatureToOctets does give the actual bytes and for scalars it refers to i2osp which specifies them as big-endian. Do you propose that we use little-endian instead for the signature and proof composition?

[mikelodder7]

Let me clarify, in a spec if they give the actual byte sequence it’s almost always little endian, but when encoded like hex or base64, it’s big endian. Since we rarely give the actual byte sequence, I’d propose to use big endian hexits

[tplooker]

Related to updates in #221