Re: Cohen's paper on byte order

From: Douglas A. Gwyn (DAGwyn_at_null.net)
Date: 05/09/03 

Date: Fri, 09 May 2003 00:57:08 -0400

Mok-Kong Shen wrote:
> Look also in the following way. In my code I use
> an array of unsigned char to represent a bit array,
> since C doesn't have bit as basic data type. This
> is waste of storage space. If one looks into that
> array one would see
> 00000000 00000001 00000000 00000000 00000001 .......
> Now do a compression on it and one obtains 01001111,
> which is exactly what I have in the variable bt.
> Do you think that one should have 11110010, namely
> in the reverse order instead?

That's plain silly. You *created* that array as a
representation of a bit sequence, and are now trying
to shoehorn it into 8-bit byte, perhaps using the
FIPS as guidance. But it has been maintained all
along that there is no ambiguity in the FIPS method
of converting a bit sequence to AES internal bytes!
Your code is simply *not relevant* to the issue of
mapping of external multibit patterns into the bit
array as used in the AES computation according to
the FIPS.

If you continue to be confused about this, I suppose
I could post example C code to show exactly where
the gap in the specification occurs; you seem to
prefer to work with concrete source code than with
abstract concepts. But the problem has been stated
plainly, many times, and if you'd try to understand
it instead of refute it you'd make better progress.

> But the user input IS at the beginning a bit array
> of size 128. Do you agree or not?

No, as has been repeated many times, if the input is
presented as a bit array there is no problem. In most
cases, however, the input is going to be presented as
a sequence of multibit units (usually octets), not
single bits.

> BTW, do you find any problems with the art of
> presentation of the AES algorithm as is done in
> W. Stallings' paper in Cryptologia?

I have no opinion about that yet. So far I'm just
trying to get agreement on a supplement to the
standard to bridge a crucial gap in the specification.

Relevant Pages

  • Re: Cohens paper on byte order
    ... >> of AES? ... >> octet array test vectors. ... are external to the FIPS but which are used to test the validity of AES ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... interoperability among independent AES ... It builds a bit array ... addressable* C data object) from external data, ... FIPS, invokes a function that implements the ...
    (sci.crypt)
  • 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)
  • Re: The code of co-workers
    ... -all of the pointers have to be valid (dereferencing an invalid pointer ... -*i+1 and *j+1 must be valid indices into the array that a points into ... these are modified between the same pair of sequence points (modifying ... To avoid burying any useful diagnostics in useless ones, ...
    (comp.programming)
  • Re: Cohens paper on byte order
    ... > you changed from a bit sequence to what appears to be ... an array of unsigned char to represent a bit array, ... in the reverse order instead? ... But the user input IS at the beginning a bit array ...
    (sci.crypt)