Re: Cohen's paper on byte order

From: Mok-Kong Shen (
Date: 05/17/03

Date: Sat, 17 May 2003 10:50:03 +0200

"Douglas A. Gwyn" wrote:
> Mok-Kong Shen wrote:
> > In our human society there are in 'all' matters always
> > a few pedants/paranoids who 'see' certain 'stuff' and
> > 'problems' that the majority don't 'see'/'experience'.
> Now you're calling me a pedant/paranoid? Just because
> you refuse to understand the issue doesn't mean that
> the fault lies with others.

Yes. You continue to argue in pedantic ways and are,
as shown previously and also in this post, wrong. I
was for a long time confused by the issue of different
ordering of bits in an hardware byte (on an external
medium), for that conceivably could give rise to
non-interoperability and would need conversion and I
hence repeatedly wrote about the conversion issue until
I finally noticed that what your code does is just to
order the bits in a byte variable (in user's code) in
the opposite order of what is done in my code and,
therefore, the above said conversion issue will apply
to your code as well, if it applies to my code. Now
the concatenation of the logical view of the bits in
the byte variables (there are 16 in an AES block)
with your code will not reproduce the original ordering
of bits in Fig. 2, for each 8-bit chunk gets reversed
inside it. This is clearly and definitely wrong! You
said previously that your code could also assemble
larger units than 8 bits. If you do that with the
example of Sec. A.1 to assemble 32 bits into a word,
you will find that w_0, when printed out, will be
entirely different from the hexs shown in the document!

> > I am taking this opportunity to post in the attachment
> > a piece of code with comments to illustrate the problem
> > being debated, not for you but for those general readers
> > who have not read all the relevant posts on the topic.
> Such readers would be better served by looking at my
> code example just a couple of days previous in this
> thread, which shows precisely what the issue with the
> AES specification in FIPS-197 actually is. Your code
> is merely part of a continuing attempt to obfuscate
> the issue by moving the discussion to a different
> context where there was never an issue.

As said, you reverse the bits in a byte and is wrong
according to the document. Sec. A.1 leaves no other
interpretation than what Gladman says '.... bytes
within which bits with lower indexes [of the first
row of Fig. 2] have higher numeric significance'
(brackets mine), which means 01001111 has to be in
the byte just like that, left to right, and not as
in your code which would be 11110010. If one prints
out, my code will give 4f, as expected, while yours
will give f2, which is wrong according to what is
depicted in Sec.A.1. Note that actually Sec.A.1
demands more, namely there also may not be swapping
of bytes within a word (which is what the term
'little endian' commonly refers to).

[An essential note to Dr. Gladman: I interpreted
what you wrote in the above. I believe I have done
it right, for it is also based on your post of
Sat, 17 May 2003 00:52:33 +0100, where you wrote
' ..... it allows test vectors to be presented in
strict big-endian notation'. (This clearly refers
to stuff like Sec.A.1.) If, contrary to my belief,
I had interpreted you wrongly, please do kindly and
energetically protest, for that's a 'very' important
point in the present discussion. Another thing I
like to repeat is that Sec. A.1 renders an explicit
mention of the text you proposed unnecessary in my
view. Your comment on this will also be appreciated.]

Finally, I like to repost in the attachment my code
of a previous post, with some little extension and
also some improvements of the comments in it. Any
reader can run the code and verify the result, which
will be, as expected from reading the code alone:

   0 1 0 0 1 1 1 1
  4f 79 0
  4f 79 0
   0 1 0 0 1 1 1 1

This means correct transport of the bit-array, which is
at the fundament of the AES algorithm. (Any byte-array
implementation must ensure that the semantics provided
by an bit-array description is maintained.)

M. K. Shen

#include <iostream.h>
#include <stdio.h>

int main()
{ unsigned char bita[8];
  unsigned char bt;
  int i;
  FILE *fp;

// Given a sequence of bits 01001111, each bit being
// stored as the rightmost bit of the elements of the
// array bita:
  bita[0]=0; bita[1]=1; bita[2]=bita[3]=0;

// Print the bit array.
  for (i=0; i<8; i++) printf(" %1u",bita[i]); printf("\n");

// Place that group of bits into the byte variable bt
// according to the given sequential (left to right)
// ordering (this is the user's logical view of the byte
// variable). See also Sec.A.1 of AES document, which
// depicts user's logical view of the ensemble of four
// bytes in a word and further implies that the bytes
// in a word are, among themselves, ordered big-endian
// (the term endian refers commonly to the ordering of
// bytes in a word), though this issue is not touched by
// the present code, which considers only the issue of
// byte-array implementation, thus neglecting the problem
// of I/O in units of words (in place of units of bytes).
  for (i=0; i<8; i++) bt|=bita[i]<<(7-i);

// Print it out in the hex and decimal notation and as
// a character.
  printf("%2x %3u %c\n",bt,bt,bt);

// Write bt into a text file.

// Read from a text file into bt.

// Print it out in the hex and decimal notation and as
// a character.
  printf("%2x %3u %c\n",bt,bt,bt);

// Retrieve the bits from bt into the array bita.
  for (i=7; i>=0; i--) { bita[i]=bt&0x01; bt>>=1; }

// Print the bit array.
  for (i=0; i<8; i++) printf(" %1u",bita[i]); printf("\n");

// The result printed will confirm that the code has done
// its job correctly.

// Here, since we are working with the same type of hardware
// (actually the same computer), the result is of course
// the same as what has been output originally into the file.
// A question that needs to be considered is whether with
// hardware of different types (different endians with
// respect to bits within a byte -- note that endian is
// commonly a term used with respect to bytes within a word
// instead) the recipient would get a different and hence
// wrong result. I have no experience of that, since I have
// only one type of hardware. Could anyone kindly give
// an example of a pair of hardware in practice where such
// a difference does occur? In that case a conversion would
// be necessary, but that would be something that obviously
// concerns text processing (and a multitude of other
// applications that employ 8-bit units in their program
// codes) in general and is not any specific problem of
// AES in its (abstract) algorithmic specification. In
// other words, that conversion would be generally
// necessary as a result of the programming technique
// (here packing of bits into a byte variable and use of
// such a variable, in contrast to handling the bits
// individually) chosen and is not in anyway related to
// anything inherent to the AES algorithm as such. Note
// finally that the conversion is simple and functions
// to do bit reversal in bytes are available on the
// internet, see
// See also about
// the need of conversion in another context.

  return 0;

Relevant Pages

  • Re: Cohens paper on byte order
    ... AES implementation myself, let me hypothetically ... assume that I am the programmer responsible for AES ... has a number of different hardware and that I don't ... I know that no conversion is needed. ...
  • Re: Cohens paper on byte order
    ... > octets. ... So the non-interoperability issue of AES, ... and that conversion can be simply done and that, ... one's hardware but one could just as well implement ...
  • Re: Cohens paper on byte order
    ... > I've said over and over that the minor issue with AES exists. ... conversion if communication of byte array is between ... machines involved are of the two different types. ... The byte arrays of AES output ...
  • Re: Cohens paper on byte order
    ... that has nothing to do with the AES specification ... > of such differences in hardware formats and ensure that ... > the value of the octet, 0xpq, is correctly transported. ... with the ability to exchange external data. ...
  • Re: More blather about atom
    ... Apple is making far more off software than it is off hardware. ... AES runs at 200 Mbit/s on a 1996-vintage 200 Mhz PentiumPro, scaling pretty effortlessly to 2+ GHz on a single core of a 3-4 year old laptop computer. ... This corresponds to full duplex Gbit Ethernet. ...