Idle curiosity (ieee bitorder)

Tom St Denis wrote:

[snip]
> > If you look at the test vectors they specify an array of bytes.
> > If you load them that way into a register on ANY modern
> > processor the meaning is reversed. "right shift" multiplies by x.
> >
> > Where this becomes a problem is the byte array is LITTLE ENDIAN.
> > That is the first byte is the LSbyte (and the MSnible of that is
> > the LSnibble of the sequence).

I suspect that you are misreading bit sequence test vectors as byte
arrays. Are you assuming that the GCM specification requires that the
GCM bit sequences are (a) always split into 8-bit sub-sequences, and (b)
always mapped so that 11100001 (i.e. the bit sequence 'e1') becomes the
C byte 0xe1 rather than 0x87?

The GCM specification has no concept beyond bit sequences. On systems
that offer access to bytes [octets] I would _hope_ that people do map
GCM bit sequences in such a way that bits 8n..8n+7 go to byte[n] in the
'preferred' order of the two possible orders.

But I don't recall that this is a requirement of the GCM specification
and implementers are free to map the bit sequences in any order onto
units of any length if they wish to do so (on systems that don't offer
bytes they will have to do this).

[snip]
> > Most algorithms follow this convention. Rijndael, Twofish and most
> > LFSR implementations are this way. That's why it's called a
> > "convention". It isn't "right" just more natural.

In some cases it would be reasonable to claim that platform byte order
is the 'natural order'.
[snip]

> > Since really no platform purposefully loads bits in the wrong order.
> > They may be big endian but the bits are still the same order inside
> > each unit [octet].

Without naming bits in some way and carefully specifying what we mean by
'order', we have no way of knowing which 'order' bits are loaded in.

Because there is no agreed convention for naming bits within larger
units we are typically forced to use an indirect means of 'naming' bits
by referring to them in terms of the power of 2 that they represent when
the unit itself represents an integer.

But having named the bits in this way, we are still free to use these
bits to represent things in any way we wish unless a specification says
otherwise.

In the case of integers there is an obvious practical incentive to use
the mapping implied by this naming convention. But when other entities
are involved there are sometimes performance incentives that dictate
which mappings are the most sensible ones to use.

Brian Gladman


.

Relevant Pages