Re: (long) An AES implementation for 32-bit platforms

From: \(lurking\) (a_at_a)
Date: 06/11/03 

Date: 10 Jun 2003 21:13:08 -0500

"Mok-Kong Shen" <mok-kong.shen@t-online.de> wrote in message news:3EE67743.3C899B49@t-online.de...
>
>
> "(lurking)" wrote:
> >
> [snip]
> > Yes, endian portability is another matter altogether.
> [snip]
>
> My personal (thru I can't certainly be very sure) way
> of thinking is as follows. If one has, say, 100 bytes
> on a diskette and have it read into a byte array
> b[100], then it is surely (if it is read in terms of
> bytes, nor words) going to be placed in that order
> in the big array without any reordering. Now with union
> one does an overlay of words on the successive groups
> of 4 bytes. (Note that one doesn't read in terms of
> words.) Hence if one assigns such a word in the union
> to another word, the 4 bytes are moved as such, also
> without reordering (why should there be reordering
> when a word is assigned to another?). The same is with
> xoring of two words. The 4 corresponding bytes are
> xored as they are in the words (their 'containers').
> Only when one needs the integer values of a word,
> does endian-ness manifest itself. Shifting with
> the '<<' and '>>' operator by 1 bit could be considered
> as multiplication with 2 or division with 2 and hence
> involves the integer value 'interpretation'. Consequently,
> a left shift of 8 bits, i.e. one byte, with the
> said operators works differently according to endian-ness.
> In my code, it happens fortunately that I don't need
> to use the shift operators and hence the endian-ness
> is transparent for my specific programming logic.
>
> M. K. Shen

Hello Mok-Kong,

I meant to decline commenting on endian portability one
way or the other because I have little recent real-world
experience with this matter. I did not mean to say I see
such portability problems with your code. Instead, I
mean to say I am not in a position to address that aspect
of portability.