Re: Cohen's paper on byte order
From: Eugene Starokoltsev (email@example.com)
From: firstname.lastname@example.org (Eugene Starokoltsev) Date: 15 Apr 2003 04:38:11 -0700
reMok-Kong Shen <email@example.com> wrote in message news:<3E9AB49B.21F11932@t-online.de>...
> Brian Gladman wrote:
> > The problem is a rather technical one about abstraction. As written the
> > entity called a 'byte' is only strictly defined internally ( ...Bytes _in_
> > AES ...) but the interface makes this internal entity visible externally.
> Fig. 2 of FIPS-197 defines the relation of the
> 128 (abstract) bits to the (abstract) bytes. If an
> implementation were (I don't think any real implementation
> does that) to use a bit arrary to realize the algorithm,
> then there would certainly be no interface problem.
> What one has to do in the real-life case of using
> octets (simply a precise term for 8-bit bytes) on
> external medium is to have a fixed correspondence
> (mapping) between a (physical) octet and an abstract
> byte of the AES document. But then isn't it
> self-evident that an array of octets with increasing
> indices should correspond to the 16 (abstract) bytes
> of AES with increasing numbers? (True, the document
> doesn't explicitly say that, but wouldn't a specific
> mentioning of that be unnecessary pedantry? One
> would certainly also not mention there e.g. that in
> numerical computations the Peano Axioms are assumed,
> would one?) The AES byte has bit number 0 on the
> right side, in conformity with the common convention
> of writing a binary number. For the octet, it is
> (according to a post of Olson, among others) an
> integer. An integer must have (somewhere) a least
> significant bit. That bit evidently corresponds
> to bit number 0 of the AES document. Any other
> correspondences would be fancy, weird, artificial,
> unreasonalbe and hence is invalid in my conviction.
> Note that this argument does not even marginally
> touch the question of how the hardware stores the
> 8 bits of an octet in their positions with respect
> to one another. (It could distribute them in any
> way it likes, provided that on access it delivers
> the said integer in [0, 255] and consequently one
> could use an appropriate mask to access e.g. the
> LSB of it.) When such an octet is transmitted from
> one machine to another of different architecture,
> the transport protocol should bother to ensure that
> the octet arrived and stored on the target machine
> would deliver the same integer as on the source
> machine, thus preserving the information content.
> But that's the business of the transmission protocol
> and transferring a text file would 'in general' have
> the 'same' issue to be taken into consideration.
> If there is defect in such transmission protocol
> (I don't know, but I don't think so), the remedy
> should be done there, not in AES.
You would be right if AES does specify identity of AES internal bytes
and external octets.
We discuss formal aspects of the problem there so your argumentation
about self-evidence is not relevant for the question. Other mappings
are allowed by the specification while you think they are
unreasonalbe. But as it does natural to identify bytes stored in RAM
with internal AES bytes _if_ the opposite is not specified there is no
problems with real AES implementations.
I know at least one system storing plain bit stream (having no meaning
for the system itself) in memory array starting from LSB of the byte
with the lowest address and transmitting it by a specialized serial
link. If somebody adds an encryption of the bit stream to the system
(I don't think anybody needs, but what if), which mapping of memory
bytes into AES bit stream should he/she use?