Re: Cohen's paper on byte order
From: Eugene Starokoltsev (email@example.com)
From: firstname.lastname@example.org (Eugene Starokoltsev) Date: 14 Apr 2003 05:00:50 -0700
"Douglas A. Gwyn" <DAGwyn@null.net> wrote in message news:<3E9A4392.email@example.com>...
> 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
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?