Re: Cohen's paper on byte order

From: Eugene Starokoltsev (eugene_o@gmx.net)
Date: 04/14/03 

From: eugene_o@gmx.net (Eugene Starokoltsev)
Date: 14 Apr 2003 05:00:50 -0700

"Douglas A. Gwyn" <DAGwyn@null.net> wrote in message news:<3E9A4392.2030701@null.net>...
> Brian Gladman wrote:
> > The people who consider bytes to be bit sequences (lets call them 'bsters')
> > will claim that we can move bytes as bit sequences between machines without
> > changing their values. They are right too.
>
> Well, no, that's the problem. In order to accomplish that, one
> needs an additional "layer" of specification that tells how to
> take a byte from storage and locate its nth bit (n=0..7). If
> you had said: they can reliably exchange bit sequences, with no
> reference to bytes, then that would be true. The problem is
> that almost all the computing environment, including the most
> likely programming languages, handles data as sequences of
> bytes, not bits. Decades of evolution have produced this
> framework and ensured that all participants can reliably
> exchange data on that basis. For example, the byte-endianness
> issue (for multi-octet values) has been resolved for network
> protocols. For an information-exchange standard to be complete
> it needs to relate to this existing structure. You might think
> of that as an "octet-sequence binding", if you're familiar with
> the notion of various specific bindings to general standards,
> e.g. a C-language binding to the IEEE/IEC floating-point spec.

You are right, the specification must exist somewhere. I object to
place it into AES FIPS as a requirement for implementation interface.

In any case as it was pointed by Dr. Gladman it is not a real problem
as all known free C implementations use the same mapping and it is not
easy to create different implementation. But for the questions of
formal correctness/completness your arguments about decades of
evolution are not relevant. They are relevant to the question of
importance of octets for this world, but nobody oppose to you.

AES is not information-exchange standard as it does not specify how
the encrypted blocks are transmitted from output of encryption routine
to the input of decryption. And it is possible to use it for purporses
other than just data exchange, like pseudorandom numbers generation.

The real problem in this discussion is that your posittion is unclear
still. It is waste of time to speak about problems with integration of
AES with communication protocols without analysis of the communication
protocol specifications.

BTW you argue there about bytes as octets but as a member of C
standartization commitee you oppose to thinking that the byte is 8
bits exactly, don't you?

Relevant Pages

  • Re: Cohens paper on byte order
    ... Brian Gladman wrote: ... > binary polynomials. ... > ordered bit sequences. ... completes a specification of how to apply AES to blocks of 16 ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... > for correct communication of the formatted data. ... Indeed AES is just a solid block to create ... AES is defined on a sequences of 128 bits only as data and a sequence ... and consistent - exectly what I need from a standard. ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... > In my view AES implementations in software are tested using the external ... > byte array interface at which the bit sequence test vectors are applied or ... Hence the bit sequences referred to in the document ... an 8-bit units which AES calls a 'byte' in Fig.2 ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... than early implementers of AES seem to have decided, ... of bit sequences. ... You further confused the issue in your rehash by ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... sequences - there are sequences of bits written left to right and numbered ... Now let us assume that it is going to be treated as a little endian number - ... All that people want is that the FIPS should actually make it clear that AES ...
    (sci.crypt)