Re: Cohen's paper on byte order

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

From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Date: Mon, 21 Apr 2003 10:27:08 +0200

"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > 'Where' in the document it is said that these are
> > 'internal' values?
>
> What else could they be? FIPS-197 very carefully defines
> the 2-nybble byte notation specifically in the context of
> AES internal bytes (only), and also very carefully limits
> the external data model to a bit stream, with no reference
> to any other possible organization of the data externally.
>
> > ... So if 'any'
> > document provides test vectors, you would claim
> > that these are 'internal' entities, ...
>
> No, I'm talking specifically about FIPS-197. Many
> (most?) comparable standards do specify external data
> format within each octet. FIPS-197 very intentionally
> does not.
>
> Note that FIPS-197 gives similar test vectors for the
> key schedule, which very clearly pertains only to
> internal values.
>
> >>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). .......
>
> It also defines "byte" specifically as an internal
> notion, which is appropriate for describing the
> computational algorithm. The I/O/key processing
> does involve groups of 8 bits, collected into an
> internal AES "byte", which the FIPS further describes.
> The FIPS-197 I/O process very specifically maps into/
> from internal byte values according to a scheme
> (Figure 2) that comes into contact withe external data
> representation *only* in the form of indexed bit
> sequence, and which therefore does not provide guidance
> about any multibit external object layout. This has
> been advertised previously as deliberate. My complaint
> is that it was inappropriate, since what we need in
> nearly all applications (excepting only inherently
> bit-stream systems) is to encrypt/decrypt arrays of
> octets with associated numeric values (for example,
> standard character codes).
>
> > As I pointed out in the previous post, the user
> > provides a sequence of bytes (in notation of 0xpq
>
> How does he get them there? That notation is for
> use in the standard to describe internal operations,
> not an I/O spec. That is very clear from the wording
> in the actual standard.
>
> You keep trying to "finesse" the whole issue by
> ignoring it. That doesn't solve anything.
[snip]

I am surprised by the first of the two sentences
in the last paragraph above. Now let me try to argue
in some great details (which should actually have been
unnecessary in my humble view).

(1) The AES algorithm is fundamentally (at the end)
based on the notion of blocks of 128 (individual)
bits which are designated with sequential numbering
0 to 127 in Fig. 2. There are terms applied to groups
of bits in the document, the one relevant in the
current debate being 'byte'. But these are for
convenience/simplification of descriptions only.
That is, one could 'in principle' 'rewirte' the
algorithm entirely in terms of the 128 numbered bits
(directly) without affecting the semantics in
any way. Do you argree? (If I don't err, you said
something in conformity with this previously.)

(2) In order to be able to run the algorithm to do
encryption, the user has to supply blocks of
plaintext as well as the key on an external medium
to be read by a piece of program code that implements
AES. Let's suppose that he flips a coin and writes
down the key as a sequence of 128 bits, starting from
the left end as one commonly does. Does this sequence
'correspond' to Fig. 2 in the sense that the first
(leftmost) bit of the user is to be identified with
input_0 of Fig. 2 etc. in that sequential order (i.e.
without any swapping, shuffling or other permutations)?

(3) According to common convention, groups of bits
can be designated in the hexadecimal notation, so e.g.
'010' can be written as the hex '2'. Thus the user
can choose to express his key in the hexadecimal
notation, obtaining a sequence of hex digits, again
written left to right, with the first hex digit
corresponding to the first three bits of the original
bit sequence, etc. Is that o.k.? Note that the
hex digits are to be obtained from the bit sequence
in strict sequential order from left to right. In
particular, there is no swapping of hex digits, nor
swapping of any larger units (e.g. groups of two hex
digits).

(4) Now look at Sec. A.1 of the document where there
is an example:

    Cipher Key = 2b 7e 15 16 28 ae ..........

Doesn't this 'identify', in this example case,
exactly the user-given key as expressed as hex digits
in (3) above and, being the 'same' is, in particular,
(trivially) in the same sequential order?

(5) The Sec. A.1 then said that from that key one
should obtain four words w_0, w_1, w_2 and w_3
with contents (also expressed in hex digits) as
depicted there. If an implementation that correctly
realizes that, then it has done it in a way in
conformity to the AES standard. Do you agree?

I have formulated the above in such a way as to
be able to clearly see where 'exactly' there are
'concrete' points of dispute. After your kind
answering to these (a Yes is sufficient without
further explanations, in case No please provide
some clear and concrete counter-arguments), we
could further discuss.

Thanks in advance.

M. K. Shen

Relevant Pages

  • Re: Cohens paper on byte order
    ... > A mapping is involved, and it plays a role in the ... has hex digits, but actually in the memory there ... mean in another notation ... 'transferring' a bit sequence of 128 bit of the key ...
    (sci.crypt)
  • 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: How Chapman-Kolmogorov implies Markov ??
    ... Perhaps the notation "f_i" is supposed to imply there is ... something equivalent about all of these random variables, ... concept, that we index the index set iself, or else write a finite ... sequence in it, explicitly using the integers as our indices. ...
    (sci.physics)
  • Re: [Collatz] was : Re: Status of Waring-problem - Collatz - Sorry
    ... >>From the notation there is no specific restriction on numbers x. ... all depends on the transform structure. ... >for a certain sequence of exponents only one solution for x is possible; ... The slope of the line up to the excursion is steep, ...
    (sci.math)
  • Re: Cohens paper on byte order
    ... conventions used in the FIPS, ... > down the key as a sequence of 128 bits, ... > notation, obtaining a sequence of hex digits, again ... that the first byte of the internal key byte array must ...
    (sci.crypt)