Re: Cohen's paper on byte order

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

Date: Sat, 03 May 2003 11:59:51 +0200

"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > So the non-interoperability issue of AES, which led
> > Gwyn to consider the FIPS to be incomplete and to
> > continue to argue in that wein, simply doesn't exist
> > in your view. Is that right?
>
> It's hard to believe that you honestly don't know
> that by switching from the matter of bit sequence
> indexing to byte sequence indexing, you have changed
> the issue. Your most recent "operability" issue in
> this branch of the discussion was set up (by you) as
> a byte-ordering issue. Everybody else understands
> that the AES spec has no problem concerning byte
> ordering, because the whole world of computing knows
> how to transmit octet sequences without shuffling
> the sequence or altering individual octet values.
> Thus Olson's comment that there is not an
> operability issue in regard to what *you* had set up.
> But there is an operability issue in another regard:
> There is no such agreement on the order in which a
> bit sequence should be packed into octets, and
> FIPS-197 not only deliberately avoids specifying this,
> it even can be reasonably read as suggesting an
> order that is different from some existing
> implementations of AES. That is the actual problem.

Let me give an explanation of why I considered earlier
the byte ordering problem as well (i.e. in the more
general constellation). If one, for achieving processing
efficiency etc., pack 32 bits into an unsigned
int and write that out wordwise and read in also
wordwise, then there would be an interoperability
also at the byte level. Restricting oneself to
I/O with byte array of course obviates the problem
from byte ordering.

But why do you continue to refuse to accept the
convention that, e.g. 01001111 could be equivalently
written as 0x4f? (Even a decimal integer 123 can
be similarly written in the hex notation, can't it?)
Now if I take the first 8 bits of the first row
of Fig. 2 (which is at first as such 'logical'
(in meaning)) and assign it to a byte variable
with bta=0x4f; and write it out to be an octet on
a physical medium and that octet gets transmitted
with a standard transmission protocol (that
secifies the order of transmission of the diverse
bits according to the numerical significance on
the sender machine such that the octet assembled
from these bits will form an octet on the reciever
machine that means the 'same' 0x4f in value) to
the other machine, then everything is in order,
isn't it? So where is the problem that would
necessitate an amendment of the AES document?

Thanks.

M. K. Shen

Relevant Pages

  • Re: Cohens paper on byte order
    ... represented as a sequence of physical bits in the ... the value of the octet, 0xpq, is correctly transported. ... It's available on the internet from NIST. ... > fact true of almost all data storage and transmission ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... > depend on the applicability of the common hex notation. ... bit sequence, there is a bit-order-within-unit issue for ... *any* multibit storage units, not just octet units, and ... fact true of almost all data storage and transmission ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... > So the non-interoperability issue of AES, ... indexing to byte sequence indexing, ... the sequence or altering individual octet values. ... operability issue in regard to what *you* had set up. ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... An octet is an ordered set of 8 bits ... of bytes for numeric representation in the AES spec. ... nearly always the case, the external organization is ... than the AES byte sequence, ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... >> corresponding bits of the mapping to have the same ... > effect the approach adopted in the AES specification, ... >> Given an octet on a source machine, ... > AES bit sequence and bit significance within each octet. ...
    (sci.crypt)
Quantcast