Re: Cohen's paper on byte order

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

Date: Mon, 28 Apr 2003 23:22:02 +0200

Brian Gladman wrote:
>
> "Douglas A. Gwyn" <DAGwyn@null.net> wrote in message
> news:3EAC7F88.2040501@null.net...
> > Mok-Kong Shen wrote:
> > > Do you mean by 'index' the first row of Fig. 2?
> >
> > I mean by "index" exactly what FIPS-197 specifies
> > that it means by "index". Indeed the indices are
> > used in the top row of Figure 2.
> >
> > > ... But the ensemble of 128 bits
> > > doesn't represent a huge integer for AES.
> >
> > I never said it did; you're the one who introduced
> > that bogus notion in an apparent attempt to further
> > muddle the argument.
> >
> > > Similarly, the 8-bit units that are termed 'bytes'
> > > there don't represent integers.
> >
> > Actually they do, insofar as the hexadecimal
> > notation goes. (Figure 1, for example.) But
> > even without any internal numerical interpretation
> > the issue remains of how to map external storage
> > organized as multibit numerical values onto AES
> > internal storage. Brian Gladman and you have both
> > argued, at times, that the external numerical values
> > should map to equal numerical internal values (which
> > is problematic if the environment is organized into
> > storage units of width other than 1 or 8).
>
> I have suggested the mapping external_integer[0xpq] <->
> internal_finite_field{0xpq} only in the context of the AES byte array
> interface in which 'bytes' are 8 bit units.
>
> In my view the pseudo code in the FIPS implicitly establishes this external
> byte array interface and this mapping. This should have been referenced
> explicitly early on in the FIPS but I don't see this as an area where many
> misread the intent of the FIPS.

Allow me to ask a few questions (to all who are
interested in the AES interoperability issue). Isn't
it reasonable to require the following: An AES block,
as defined as a bit sequence of 128 bits should be
written (for purpose of data exchange) to an external
medium always as a block of contiguous 128 bits in
the sense of a mirror image to Fig. 2, with the bit
corresponding to input_0 placed nearer the lower end
of the address space. Isn't this a 'natural' mapping?
With this convention, hardware with big-endian byte
ordering and big-endian bit ordering (within byte)
will need no special care in writing its data out,
while with hardware of other architecture one will
have to do some conversion to satisfy this requirement
(and also to read in such a file for processing).
Isn't this acceptable? Or else what is a better and
cleaner practical solution and what exactly are the
rationales in favour of it?

Thanks.

M. K. Shen

Relevant Pages

  • Re: Cohens paper on byte order
    ... > organized as multibit numerical values onto AES ... Brian Gladman and you have both ... In my view the pseudo code in the FIPS implicitly establishes this external ... byte array interface and this mapping. ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... Brian Gladman wrote: ... > but had the FIPS been perfect there would have been two versions of AES. ... Which is a strange notion of "perfection". ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... > not have any defined bit sequence within an octet; ... > of the FIPS as a guide to how to organize the external ... AES with an octet array interface that is consistent with the AES-FIPS ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... NIST - implements AES in accrdance with the FIPS specification! ... byte array interface, in principle, we then have two non-interoperable ... there is a really good chance that this will set a wider standard. ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... >> of just AES are correct. ... >> function interface is out of scope of the FIPS clearly. ... The reason is that the FIPS ...
    (sci.crypt)