Re: Cohen's paper on byte order

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

Date: Wed, 14 May 2003 02:54:32 +0200

"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > For 'endian' is completely irrevant here, because we
> > don't have any integer in this context!
>
> Wrong again. Does the code work or not? It was meant
> to show precisely where a choice of endianness *has*
> to occur, no matter what MKS wants to call it.

How could I verify that without the two (or more) kinds
of different hardware available for me to do a test?
I have only a PC with an Intel processor and thus only
one kind of 'endian'. Hence I have to settle the issues
'theoretically' via argumentation with you, sorry.

Since there has been a huge amount of discussion
materials (and further I had also revised in the
course of time part of my opinions) and you haven't
in my view properly dealt with a number of my points,
I like to present (also in the interest of the general
readers) my arguments once again, hopefully this time
very clearly (though necessarily quite verbosly) in
the following. If indeed you are right with your
points, you should be able to refute mine clearly and
definitely point by point (or even sentence by sentence).
Please kindly formulate your counter-arguments this
time as best as you can, so that we could soon terminate
our overly extended long discussion in this thread.

(1) A normal user (a programmer working with a common
PL without any hardware knowledge) has only a 'logical'
view of the variables in his code. This logical view
of a byte variable consists of 8 bits ordered as
follows: (The location designations here are arbitrary
tags, serving to name them; these could also e.g. be
'rose', 'lilly', etc. Of interest to us is only the
existence of an ordering, the first bit being the
leftmost one, here 'a', as one would normally look on
such sequences e.g. on a *** of paper.)

   _ _ _ _ _ _ _ _
   a b c d e f g h

This is also what a manual would depict or what a
debugger/hexdump would show (in the case of hex, the
equivalence of one hex digit to 4 bits is to be
performed in the well-known common convention). Now
for a pair of communication partners, their 'common'
view of a byte variable is just that. They have no
idea of how the 8 logical bits above are mapped
and arranged 'actually' on the physical medium/memory
of their respective hardware. Therefore their programs
will be in the present context (by definition)
interoperable, if, for example, with the code

   unsigned char bt;
   bt=0x4f;

the sender could output bt to e.g. a diskette and
the recipient could input the resulting octet to a
similarly declared variable
   
   unsigned char btr;

and the condition btr==0x4f is found to be true. In
the other case, there is an interoperability problem,
that needs to be dealt with e.g. with some conversion
code. (We note that in the above the assignment of
0x4f to bt means that it will contain 01001111 in the
'logical' view of 'both' users.)

(2) The question is: Does that interoperability problem
exist for the users considered? There are two cases:

(2a) That problem doesn't exist. In this case one is
fine. For one could in the case of the (abstract)
block of AES let each chunk of 8 consecutive bits (as
depicted in Fig. 2 of the document) be placed in a
byte variable (in the same left to right order as seen
by the user in his 'logical' view) and have the bits
subsequently correctly retrieved in the same order in
the program of the recipient. Repeating the process
16 times results in successful transport the entire
128-bit block.

(2b) That problem exists. From what is commonly known,
this can only be caused by a different mapping of
the individual physical bits of the octet to the
logical bits (the user's 'logical' view, see (1)) of
the byte variable of the sender on the one hand and
of the byte variable of the recipient on the other and,
with the example above btr would then have 11110010
(in the logical view), i.e. it is btr==0xf2 instead.
In this case one evidently 'needs' a conversion code
(somewhere in the entire path of transport, whether
it is 'incorporated' in the program code of the users
or done via some communication protocols isn't
relevant here) to do a reversal of the bit ordering
such that the recipient could obtain in his code
btr==0x4f, as it should be for getting a successful
transmission of the AES block.

(3) If case (2b) occurs in practice, what is to be
done in relation to standardization efforts? We note
that this is 'obviously' a 'general' problem that
affects 'all' computer applications that do the
so-called bit-programming, which include, among others,
text processing, low-level database programming,
realtime programming, etc. etc. Yes, even the mundane
text processing is affected, for in the above the
statement bt=0x4f; is equivalent to bt='O'; with 'O'
being the alphabetical character that has in the ISO
standard Latin-1 the code number 079 in decimal or
4f in hex. In other words, it is NOT a 'specific'
problem that 'only' (singularly) affects AES but one
that causes trouble to a 'multitude' of other computer
applications. Consequently, if that problem is deemed
to be in need of treatment on the level of
standardization (maybe in the sense of having some
defined 'standard' functions for doing the conversion
mentioned in (2b)), one has to see to it whether
certain standard documents on (general) data transfer
could be appropriagely extended/amended to take care
of the issue. The AES document, which treats a
(abstract) crypto algorithm, is on the other hand
definitely NOT the right document to deal with this
kind of (entirely 'foreign') stuff.

Thanks in advance.

M. K. Shen