Re: Cohen's paper on byte order

From: Mok-Kong Shen (mok-kong.shen@t-online.de)
Date: 04/20/03 

From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Date: Sun, 20 Apr 2003 10:40:35 +0200

"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > Sec. A.1 of the AES document has the following
> > Cipher Key = 2b 7e 15 16 28 ae ..........
>
> That *has* to be the values as seen in the AES
> bytes, which are internal entities. The example
> computations rely on that. If not, then there
> is a logical inconsistency in the AES use of
> bytes. (See two paragraphs down.)

'Where' in the document it is said that these are
'internal' values? When one talks of a key, that
is at 'first' an 'external' chosen quantity and has
then to be somehow input to an algorithm/program
to furnish an equivalent 'internal' quantity.
(When you transmit a 'key' to your partner, is
that at first external or internal?) So if 'any'
document provides test vectors, you would claim
that these are 'internal' entities, and, since no
formal way of turning any user provided external
entities to external entities are meticulously
provided, that document is hence incomplete??

>
> > Now what the user has specified is a sequence of
> > bytes 0x2b, 0x7e, ....
>
> No, according to the FIPS the user has specified
> bit sequences (indexed 0,1,2,3,...), not byte
> values. There are no external bytes insofar as
> the FIPS is concerned. That is the whole problem!

Read Sec. 3.2 which says (brackets mine):

  The basic unit for processing in the AES algorithm
  is a byte, a sequence of eight bits treated as a
  single entity. The input, output and Cipher Key bit
  sequences described in Sec. 3.1 are processed as
  arrays of bytes that are formed by dividing these
  sequences into groups of eight contiguous bits to
  form arrays of bytes (see Sec. 3.3). .......

  Hence the element {01100011} can be represented as {63},
  where the character denoting the four-bit group
  containing the higher numbered bits [of the byte] is
  again to the left.

As I pointed out in the previous post, the user
provides a sequence of bytes (in notation of 0xpq
is that o.k.?) and the programmer has to turn that
into the four words w_0, w_1, w_2, w_3 as shown. How
he does that (with whatever magic) I don't care, for
that's his job. As long as that is done correctly
as illustrated by the example in the document, he has
done the right job. (The difference is only that the
programmer on a big-endian machine has an easier job
than his colleague on a little-endian machine who
has to figure out how to achieve the same thing.)

>
> > Let's suppose that he puts
> > that as hex digits in a 'text' file, with each
> > digit being written as an ASCII character. (Is
> > this assumption for argumentation here acceptable
> > to you?)
>
> It's acceptable, but it would lead to the tests
> failing if bits are significance-swapped per
> Figure 2, which Brian Gladman seems to insist on,
> unless the test vectors are themselves expressed
> with bits in reverse order from the internal AES
> bytes, which is nowhere stated and would be a
> serious misuse of notation that was carefully
> defined only in the context of internal bytes.
> (It would also contradict use of the same
> notation in the preceding appendix.)

The test vectors are expressed as bytes as a user
will provide and write down on a piece of paper.
Is the 'sematics' of the sequence of bytes in that
form clear? If yes, then, as said above, I simply
don't care how the programmer is going to do with
the sequence, whether swaping something or doing
other weird stuff or not. I only require that the
four words w_0, w_1, w_2 and w_3 be correctly
obtained as depicted in the document. Does that
process of turning the external entity to the
internal entitity to be 'defined', even though
a clear example has been provided. If, as analogy,
in a numerical processing I give a number 123 to
be input to an integer variable j of the program,
do I have to tell the programmer how to turn
that 123 (as given on paper as characters) into
the binary in the computer?? (If he does it
wrong, then that's simply his fault!)

>
> > If a program ... Do you agree with that?
>
> I would agree only if that were a requirement stated
> in the spec (or some official augmentation thereof).
> But it's at least as reasonable (moreso in my view)
> to reproduce the test vector behavior with the byte
> values contained in the appropriate AES byte arrays,
> just as the key schedule byte values apparently are.
> (The key schedule values don't normally appear in
> external data.)

But the key 'exists' first on external media. The
document indicates an example case where such an
externally given key is turned into the internal
four words for further processing. See also above.
 
> > If I don't err, an
> > implementor with a big-endian machine (big-endian
> > both for the bits inside an octet and for the bytes
> > of integers that consist of multiple bytes) has a
> > rather simple job, because he doesn't have to bother
> > to do any 'conversion' in obtaining the above said
> > four words, while this is not the case for a
> > little-endian machine.
>
> Neither would a little-endian machine.
> But you're wrong about byte order for bytewise
> big-endian machines; they would have to shuffle
> bytes to get them accessed in the AES-specified
> order. However, that really is not an issue, since
> everybody except you is concerned only with data
> presented as octet arrays, not multibyte objects.

No. On big-endian machines one just read four
bytes and assemble them into a word in the 'same'
order (direction), without any swapping or
shuffling (permutation).

>
> > Now all this means that the standard is biased to
> > implementations on big-endian machines.
>
> Completely wrong, with either of the bit-order
> assignments to external storage octets that Brian
> and I have been arguing about.

Give solid counter-arguments to what I wrote above
and then we could better discuss this point.

M. K. Shen

Relevant Pages

  • Re: Cohens paper on byte order
    ... should AES care anything else actually? ... the task of the programmer to figure out himself ... and output bt to a file, don't I get an external octet? ... of the whole sequence of 128 bits as such, ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... > sequence of hexs ... ... If one adds *any* sensible mapping between the abstract ... AES bits and bits within storage bytes, ... That is really not a proper purpose of test vectors. ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... > the 2-nybble byte notation specifically in the context of ... > AES internal bytes, ... > sequence, and which therefore does not provide guidance ... notation, obtaining a sequence of hex digits, again ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... Big-endian is an order in which the ... > stored first (at the lowest storage address). ... > significant value in the sequence) is stored first. ... No. AES specification defines a term 'byte'. ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... A sequence of two bytes, ... Therefore the bytes in AES ... I meant by character by character.) ... posts of the groups with certain ...
    (sci.crypt)