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:51 +0200

"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > Fig. 2 does introduce a grouping of 8 bits, which
> > is termed 'byte'. This 'byte' as such, like the
> > 'bit' of Fig. 2, is internal.
>
> The very definition for "byte" given in the FIPS
> makes it clear that the term has internal meaning
> (within the computation) only. "Bit" is used in
> both internal and external contexts; external bits
> are *indexed* (a FIPS-defined term) in sequence
> while internal bits are numbered in a quite
> different way (opposite direction, for example).

Don't you think that 'indexed' and 'numbered' are
lignuistically 'equivalent' in the present context?
In my opinion Fig. 2 defines only internal bits and
internal bytes and that it is FIPS' view that
the correspondence (through an implementation) of
these internal entities to the external entities
should be trivial. Let's look carefully what Fig. 2
says. It says that the 128 bits of a block are
sequentially ordered and further that there is
standard groupping of size 8, namely what it terms
'byte' and these are (naturally) also ordered. Now,
what do we require, if two AES applications are to
interoperate? The fundamental requirement is clearly
'only' that the 128 (internal) bits of a block be
transported from the sender side to the recipient
side intact, i.e. with the same values and the same
sequential ordering. As long as the programmer
manages 'somehow' to achieve that correctly, why
should AES care anything else actually? (Should
AES care about all the programming techniques/details
that he employs?) Now, sending the array of bits
individually and in the sequential order of Fig. 2
evidently ensures correct transport. This is the
bit array implementation, which needn't be discussed.
For the byte array implementation, the requirement
is 'only' that, if the 16 units with the name
'byte', of 8 bits each, are sequentially sent (via
their 'incarnation' as appropriate external entities)
and then received and concatenated to form a bit
array of size 128, the sequential ordering of bits
in that array is the same as that of the sender,
right? How is one actually going to fulfill that
requirement with suitable programs is in my view
not within the domain of AES but it is (instead)
the task of the programmer to figure out himself
how he could, using his knowledge of hardware and
software and of communication protocols, send
(instead of individual bits, which would incur
inefficiency) the 16 groups of 8 bits each such
that the above said requirement posed by AES is
fulfilled. I don't think, as expressed previously
several times, that one could accuse AES of not
providing some prescriptions helpful to the
programmers. (I mean one shouldn't sort of
'spoonfeed' the programmers and one should let
them sufficient freedom to do their job -- there
may be, as usual, diverse ways to achieve the same
programming goal, some good, others poor -- and
hence also earn their money as their professional
performance actually deserves.)

>
> > Now there are two ways
> > of implementing AES. One is to employ 'bit' array
> > (in which case the notion of 'byte' could be forgotten
> > in our context). The other is to employ 'byte' array.
> > The hex notation employed in the document is clearly
> > nothing else than the common hex notation for a binary
> > integer corresponding to the 4 bits (with the LSB
> > on the right). Two such hexs correspond to a 'byte'.
> > This 'confers' on the group of 8 bits a numerical
> > value, namely the value 0xpq. This 0xpq is at this
> > point yet internal. What is desired is to transfer
> > that internal entity of the sender's program code
> > to the recipient's program code.
>
> Yes, so far. Interoperability requires this.
>
> > Now an (external)
> > octet at the sender's side can have the same
> > numerical value as 0xpq.
>
> There are not necessarily octets externally. For
> the common situation where external data *is*
> organized as octets, there are two obvious choices
> for the relationship between the external octet
> value and the corresponding internal byte hex code.
> One should find a specification for this in the I/O
> section of the standard. However, one doesn't.
> What one does find there is a pure bit-sequence
> model for the external data, and a diagram that
> could be taken as suggesting that bit order should
> be reversed in groups of 8 during I/O.

If I have

  unsigned char bt;
  bt=0x4f;

and output bt to a file, don't I get an external octet?

Now the 0x4f has a correspondence to the internal
entity 'byte' of 8 bits with the common hex convention.
So outputting a 'byte' to become an external octet
doesn't seem to be an issue, right? I assume here,
of course, that the common hex convention can be
universally applied (a point that you seem yet
to disagree), unless specifically forbidden, but AES
doesn't forbit anything of that sort.

>
> The *internal* notation 0xpq is not intended to
> denote an integer, but rather a bit pattern for
> finite-field representation (where the "leftmost"
> bit is the coefficient of the highest power in the
> polynomial). It is fairly natural to use this
> notation to designate a corresponding integer
> value according to common hexadecimal usage,
> but there is certainly nothing in the FIPS saying
> that such a value has to be represented externally
> by the same numeric value. Some implementors have
> chosen to implement AES that way, instead of taking
> the bit-reversal suggestion at face value, and this
> has the merit of being (probably) slightly more
> efficient, so it would be a good way to specify
> the mapping. But it is wrong to pretend that the
> mapping *is* specified in this way. In fact that
> is not a workable approach to such a supplemental
> specification, because it applies only when the
> external data is organized in precisely 8-bit units;
> common as that may be, it is not the only possible
> environment, which is why I suggested a more general
> specification that would apply to any unit width.

We could forget in our context the mapping to GF
and concentrate on the issue of correct transport
of the whole sequence of 128 bits as such, i.e.
maintaining the correct values and sequential ordering
(of the bit array of size 128). See above.

M. K. Shen

Relevant Pages

  • Re: Cohens paper on byte order
    ... >> Now what the user has specified is a sequence of ... The basic unit for processing in the AES algorithm ... programmer on a big-endian machine has an easier job ... > unless the test vectors are themselves expressed ...
    (sci.crypt)
  • 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. ...
    (sci.crypt)
  • Re: Any way to upgrade CMOS clock??
    ... Any way to upgrade CMOS clock?? ... Timecode is a good start, but it needs a sequence number added to it, at ... You claim to be a programmer and make wild assumptions. ...
    (alt.sys.pc-clone.dell)
  • Re: Why COBOL is losing the POWER struggle
    ... This was in response to my post about how ... Do you think it is possible that programmer "interests" change over time as ... writing a program to display the simple Fibonacci sequence in BASIC. ...
    (comp.lang.cobol)
  • Re: Naive, possibly silly question
    ... >> But programming is best done with abstraction, ... > order to be a decent programmer. ... but the sequence was guided by the abstract need for a ... "for" loop. ...
    (comp.object)
Loading