Re: Cohen's paper on byte order

From: Mok-Kong Shen (
Date: 04/29/03

Date: Tue, 29 Apr 2003 16:59:42 +0200

Brian Gladman wrote:
> "Mok-Kong Shen" <> wrote:
> [snip]
> > > Now we all agree on how to cut these sequences into 8 bit groups so lets
> > > just concentrate on the first such group:
> > >
> > > 01234567 <- bit number
> > > 00000001 <- bit value
> > >
> > > Now let us assume that it is going to be treated as a little endian
> number -
> > > that is a number in which low numbered bits are least significant. In
> this
> > > case we obtain the number 10000000, which is 0x80 or 128 decimal.
> > >
> > > But if we assume that it is a big endian number with low numbered bits
> being
> > > more significant, we obtain 00000001, which is 0x01 or 1 decimal.
> >
> > I think and see this is the 'basic' point of debate.
> > Now, if we see on 'paper' a bit sequence 00000001 and
> > look at it a binary number, wouldn't we humans
> > (according to common convention, cf. writing of
> > decimal digits) interpret it differently than the
> > number with the value 1 and hence in hex notation
> > 0x01? This 'fact' indicates that, if there are 'now'
> > two possibibilites offered to us to interpret the
> > same, becauce we 'now' have a machine at out disposal,
> > we should prefer that interpretation that is 'also'
> > conform to our human interpretation, 'unless' there
> > were very 'essential' reasons for the opposite, e.g.
> > large efficiency difference between the two (which
> > I don't think could be the case). Is this argument
> > acceptable?
> If you are saying that there are good reasons to stick with established
> human conventions when writing things down, I agree. The FIPS does this by
> requiring that AES bit sequences are big-endian when interpreted as 8-bit
> byte integer values.
> The FIPS makes use of the well established conventions for writing down
> hexadecimal numbers to ensure that most people who read the FIPS are guided
> to the desired AES version without even realising that another version might
> be possible.

I am glad that we have rather essential agreement. On
the other hand, I am not yet sure that you could very
rigorously defend your point that 'The FIPS does this
by requiring that AES bit sequences are big-endian
when interpreted as 8-bit byte integer values'. The
numbering in Fig. 2 of bits in 'byte' (which also
agrees with some commonly employed numbering of bits
in a byte) could be considered as an 'indication' of
this, but a 'specific' statement doesn't seem to be
in the document and this is what has generated lots
of debates in my personal opinion.

I like to give one analogy to support my previously
stated view that some existing common conventions
should give certain contextual guidance to the
interpretation of matters that may not be 100%
unambiguously written because a pedandic attempt
to achieve 'completeness' in the description could
have the negative impact of rendering the description
long-winded or even boring. When one is in UK,
then the use of the term 'the Queen' in a general
context should be clear enough for knowing whom
it is meant, even though pedandically the term
could also refer to the Queen of Netherland or
to a queen of UK in the past.

BTW, my surfing about endian-ness bears some rather
unexpected fruits. It seems that there is (or was,
I don't know) a patent issue involved. The URL

has the following:

  US patent number 4,956,809 covers using a single
  standard byte ordering for transfer of data between
  machines whose normal byte ordering is different,
  if the machines are using a portable operating system.

This smells similar to Hitachi's rotation patent that
once intimidated all AES final round candidates, excepting
Rijndael. Worse, there was even a patent court process:

though from a casual reading I couldn't make out whether
this concerns the same patent numbered above or maybe
another related patent. Perhaps some knowledgeable person
would like to kindly tell us the real relevance of the
patent(s) to the issue of endian conversion being
discussed in the present thread.


M. K. Shen