Re: Cohen's paper on byte order

From: Mok-Kong Shen (mok-kong.shen@t-online.de)
Date: 04/15/03 

From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Date: Tue, 15 Apr 2003 23:28:07 +0200

Eugene Starokoltsev wrote:
>
> Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
> > "Douglas A. Gwyn" wrote:
> > >
> > > Mok-Kong Shen wrote:
> > > > http://whatis.techtarget.com/definition/0,,sid9_gci211659,00.html
> > > > Note that within both big-endian and little-endian byte
> > > > orders, the bits within each byte are big-endian. That is,
> > > > there is no attempt to be big- or little-endian about the
> > > > entire bit stream represented by a given number of stored
> > > > bytes. For example, whether hexadecimal 4F is put in
> > > > storage first or last with other bytes in a given storage
> > > > address range, the bit order within the byte will be:
> > > > 01001111
> > > > It is possible to be big-endian or little-endian about
> > > > the bit order, but CPUs and programs are almost always
> > > > designed for a big-endian bit order. In data transmission,
> > > > however, it is possible to have either bit order.
> > >
> > > That is wrong (except about the possibility of either bit
> > > order in data transmission), and it even contradicts
> > > itself: the bits cannot simultaneously be (big-endian)
> > > and (neither big- nor little-endian).
> > >
> > > Hexadecimal notation such as "4F" is understood to be
> > > written with the most significant nybble to the left,
> > > consistent with decimal notation used throughout most
> > > of the planet. However, that is neither-endian, it's
> > > just representing a particular integral value (79 as
> > > represented in the usual "Arabic" decimal notation).
> > > To be "endian" there would have to be an assumed
> > > *sequence* imposed on the bits, and there is no
> > > particular reason to think that the bit sequence would
> > > be left-to-right in the expression 01001111; that
> > > could equally well be read right-to-left, just as
> > > bytes are within multibyte words in little-endian
> > > documentation. Indeed in some cultures text is read
> > > from right to left (or even from top to bottom). With
> > > no specification for bit sequencing, one simply doesn't
> > > know what sequence is meant.
> >
> > These physical bits must somehow be stored in a
> > sequential order, right? What the page said is
>
> Wrong. It's possible to store them in parallel (on a punched tape, for
> example).

O.k. But do you give one specific ordering to them
when you interpret the group of bits thus parallelly
ordered or do you consider them unordered in the sense
of a mathematical set? Once you give them an order
in the group of 8, the whole bunch of bits on the
paper tape is ordered is ordered, isn't it?

>
> > that 4F is stored as 01001111 (with the first 0
> > bit located nearer the lower end of the whole
> > memory, i.e. where byte or word 0 is). The endian
>
> I don't know what is a 'lower end' of a RAM chips. You speak about a
> physical storage, don't you?
>
> BTW meaning of your term 'physical bit' is unclear. How it differ from
> an 'abstract bit'?

If you identify the abstract bits one to one with
the physical bits and implement the AES, i.e. without
even taken the 'notion' of octect into consideration,
then this would be no problem of the kind being debated
in this thread. Otherwise what I meant by an abstract
bit is what is depicted in Fig. 2 of the document and
people have discussed in this thread the diverse
manners in which these are mapped to the bits of an
octet. Is that clearer?

>
> > issue is in the 'interpretation' of a sequence of
> > bytes as a numerical value (integer) only. If a
> > sequence of ,say, 10000 stored bytes are 8-bit
> > ASCII, then they will be interpreted character by
> > charecter sequentially, in the 'same' way by both
> > kinds of machines. The same will occur when this
> > sequence of bytes are to be trasmitted over and
> > stored. (How does one transport a text file?) In
> > crypto we are dealing with 'texts', hence no
> > problem should occur.
>
> I don't understand what do you want to say.

A sequence of two bytes (both 8 bit units), when
considered as an 'integer' are interpreted on
the two architectures differently, i.e. considered
to be integers of unequal value. But the issue
of big-endian vs little-endian doesn't 'extend'
down to the level of bits inside one 'single' byte.
See also the URL cited. Therefore the bytes in AES
(being not collectively considered to be a big integer)
are to be considered individually. (This is what
I meant by character by character.)

>
> > Anyway could you cite materials negating what is
> > said in the first quoted URL, namely the bits
> > in a byte are stored in big-endian order (that is,
> > name a hardware that does differently)?
>
> "almost always designed" - the article. The author of the dictionary
> have not wrote "always designed".

Fine, then I like to know the name of one. If this
is only for a single machine designed e.g. in a
lab of university for experimentation purpose and
never used in practice, then we could entirely
ignore that for the purposes of this thread, right?

>
> > > Again, the fact that you can't get this right and
> > > are even finding contradictions (which seem to
> > > escape your notice) are strong indications that
> > > there is a real, practical problem with the absence
> > > of specification for how the bits are sequenced
> > > within a byte in this application.
> >
> > I yet remain of the opinion (until there is very clear
> > evidence to the opposite) that we are discussing
> > a phantom problem.
>
> I agree with Dr. Gwyn what the problem exists but think it is
> theoretical only. Formally the specifications of communication
> protocols referencing AES without specifying bit order is incomplete.
> But practically there in no problem.

What I have been arguing is that there is not even
a 'theoretical' problem!

I have a particular question to you: Are you connected
to the internet via an ISP or are you accessing it
thru Google or something equivalent that show the
posts of the groups with certain (under circumstances)
appreciable time delays as far as I am aware. For I
notice that you are always responding to some rather
old posts of mine and seem not to have read the most
recent posts sent to the group by me. (Currently
the one immediately preceding the present one is my
follow-up to Brian Gladman with the time
Tue, 15 Apr 2003 22:54:21 +0200. But there are several
preceding that which you apparently have not seen
at the time you wrote the above.)

M. K. Shen

Relevant Pages

  • Re: Cohens paper on byte order
    ... that the mapping in question is an implementation ... issue and shouldn't be of any concern for the AES ... Naturally where the first character is, ... Now a block in AES has a sequence of bytes ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... >> Now what the user has specified is a sequence of ... The basic unit for processing in the AES algorithm ... programmer on a big-endian machine has an easier job ... > unless the test vectors are themselves expressed ...
    (sci.crypt)
  • Re: user defined function that converts string to float
    ... > I need user defined function that converts string to float in c. ... initial, possibly empty, sequence of white-space characters (as ... point character, then an optional exponent part as defined in ... then a nonempty sequence of hexadecimal digits ...
    (comp.lang.c)
  • Re: Check for Common character sequence ( I will pay)?
    ... Dude, programming is all problem-solving. ... You need to identify character sequences of 3 or more characters that appear ... in more than one string. ... and test each 3-character sequence that results. ...
    (microsoft.public.dotnet.framework)
  • Re: Check for Common character sequence ( I will pay)?
    ... Do I need to return an array? ... You need to identify character sequences of 3 or more characters that appear ... in more than one string. ... and test each 3-character sequence that results. ...
    (microsoft.public.dotnet.framework)