Re: Cohen's paper on byte order

From: Mok-Kong Shen (mok-kong.shen_at_t-online.de)
Date: 05/04/03 

Date: Sun, 04 May 2003 16:46:47 +0200

"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > FIPS's 'own' hex notation? I am not aware of that.
> > I could err but could you please tell 'where' is
> > that (formal) specification and, more importantly,
> > how does it 'differ' from the similarly looking hex
> > notation that one commonly employs in CS?
>
> It is impossible to miss if you read the spec.
> There is even a table showing all 16 nybble bit
> patterns.
>
> The "difference" is that the bit patterns being
> represented in FIPS-197 by hex notation are not
> representations of numbers but of finite-field
> elements (polynomials). But once the hex
> notation is established, it is natural to use
> it to assign integer values to the AES bytes,
> if a context arises where one needs to do that.

In my view FIPS is simply helpful in giving a table
for the common hex notation, which it applies there
to denote the integer values of the 8-bit 'byte'
that it uses, among other situations, in the context
of GF. The bit numbering of byte in Fig. 2 would have
been sufficient for the purposes of GF involved here.
Since that hex notation doesn't differ from the common
convention in any respect, what's is the reason that
the 'same' hex notation, which is universal in CS,
'cannot' be applied when the 'byte' is employed in
other contexts? (Does AES explicitly forbid something
in this issue?)

>
> > How do you write a binary integer that is eqivalent
> > to the decimal integer e.g. 79?
>
> The same way as everybody else.
>
> > Now there is given a sequence of bits
> > that is the same, namely 01001111.
>
> There are two sequences of bits that naturally
> correspond to the binary representation of an
> integer, depending on whether one starts at the
> LSb or the MSb. The former is numerically
> natural, the latter is Western-linguistically
> natural. There is no particular reason to read
> the FIPS as requiring either one in the layout
> of external multibit objects (which aren't even
> required to exist), but if one does believe that
> the FIPS must somehow have meant to specify this
> (which I very much doubt), there are two different
> reasonable interpretations of the FIPS words and
> diagrams that suggest opposite bit orders.

You certainly have noted that my arguments essentially
depend on the applicability of the common hex notation.
See above. So this applicability issue has to be settled
in the course of our future discussion, i.e. debated to
a clear and definite end.

>
> > There are lots of things in real life that are
> > implicit and to be inferred from defaults or common
> > conventions.
>
> Too bad there is no common convention covering bit
> sequence within multibit objects. If you really
> want to insist on one, then you'll have to use
> little-endian bit order, contrary to current AES
> implementations, because that is more "common".
>
> I am not being pedantic; there is a real lack of
> specification that risks real incompatibility
> between independent implementations of AES on
> real platforms.
>
> It is ironic that the better an implementor
> understands the basics and the more carefully
> he reads the FIPS, the more likely he is to
> implement AES differently from what appears to
> be the majority of current implementations.
>
> This could be avoided by specifying the use of
> the same bit sequence within external multibit
> objects as that majority has already assumed.
> I don't much care which direction is specified
> so long as there *is* a somewhat official spec
> where an implementor is likely to see it, e.g.
> in a future FIPS-197-1. (A few other more minor
> issues could be fixed in the -1 revision, also.)

If I don't err, Markus Kuhn's paper principally
discusses the byte ordering problem in relation to
AES. In several posts of yours, you stressed however
that byte ordering isn't a problem for anyone. How
do you explain that? Is Kuhn then 'entirely' wrong
in his paper?

Further, in

http://www.xray.mpe.mpg.de/mailing-lists/perl-unicode/1999-12/msg00011.html

there is the following from him:

  The terms were first introduced in computer science in the
  classic paper

    Danny Cohen: On Holy Wars and a Plea for Peace. Computer,
    Vol. 14, No. 10, IEEE Computer Society, October 1981,
    pp. 48--54.

  Bigendian computer scientists send the most significant
  bit or byte (="end") first or store it at the earlier
  (= lower) address. ......

Note that the last quoted sentences implies, as one
would expect, that whether the most significant bit is
first sent matters. But then in his AES paper he says

  The conventions for the transmission of 8-bit byte
  sequences are usually well established for each type
  of interface.

Taking both the above together, my interpretation is
that the common communication protocol guarantees
correct transport of bytes, leaving the programmer
the task of taking care of the byte ordering issue,
which he discusses in some detail. So, assuming that
your points are right, he must have been wrong
somewhere. But where? Could you please tell?

Note that, in another follow-up I questioned whether
I/O of byte arrays via diskettes could be a problem
(since there doesn't appear to be an appropriate
communication protocol involved in such situation).
Do you happen to have knowledge in that issue?
(This is an important way of data transport in
practice in my view.)

M. K. Shen

Relevant Pages

  • Re: Cohens paper on byte order
    ... >> There is only one commonb hex notation in my view, ... FIPS's 'own' hex notation? ... >> is no problem at all with AES, ... implicit and to be inferred from defaults or common ...
    (sci.crypt)
  • Re: Card tricks with Ruby
    ... error-prone IMO since it's following a common (math) notation. ... It gives me the same feeling as ...
    (comp.lang.ruby)
  • Re: [Discussion] Sign Prediction for DCT coefficients
    ... The notation I use is confused also. ... The MPEG hijacke a confusing EBU notation, ... I had figured were the only 'common' ones. ... It's not a huge amount of complexity. ...
    (comp.compression)
  • Re: First piece?
    ... Like messing with the temp and dynamics. ... I figured it was common since they had it on that VT site. ... And how does one play "alluringly"? ... Stone's Musical notation book). ...
    (rec.music.theory)
Loading