Re: Release 1.1 (beta) of my AES implementation

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

Date: Sun, 29 Jun 2003 12:03:18 +0200

Eric Lee Green wrote:
>
> Mok-Kong Shen wrote:
> > Note that I have written the copyright notice expressly
> > in such a way that I would have a fairly good chance of
> > knowing the non-portability/non-interoperability, in
> > case such, contrary to my conviction, does happen.
>
> Not having looked at the code, are you properly accounting for big endian vs.
> little endian-ness? Bit shifting code works whether an architecture is
> big-endian or little-endian. Unions used to access individual bytes do not.
>
> Intel is the most common little-endian architecture. Sun SPARC is the most
> common big-endian architecture.

I don't use any bit-shifting of the (32-bit) words. Thus
endian-ness doesn't matter. Further, as said in a previous
post, thanks to two readers of the group, it has been
experimantally confirmed that my code (actually the
relase 1.0 stuff with some corrections) runs on big-endian
machines. I assume on the other hand 8-bit byte. On
a 32-bit machine, where this assumption is not fulfilled
(which should be comparatively rare), my code wouldn't run.

There is, I guess, one problem that could give rise to
non-interoperability, namely the so-called 'bit-sex',
i.e. the different ordering of bits 'within' an
8-bit byte. If a ciphertext generated by one machine
and output to an external medium, e.g. diskette, and
read in by machine of different bit-sex, then in my
understanding one would need conversion (which is
however not difficult). This is related to the issue
of network standard format, if I don't err. But this
kind of non-interoperability would certainly affect
other implementations of AES just as well and is
clearly not a specific problem of my implementation
alone.

M. K. Shen

Relevant Pages

  • OoO VAX (was: Code density and performance?)
    ... What architectural feature of the VAX would be a problem in the ... >some UNIX, they just couldn't compete. ... 386 architecture, too. ... >> either with pre-decode bits (as used in various 386 implementations), ...
    (comp.arch)
  • RE: generic strncpy - off-by-one error
    ... > To: Peter Kjellerstedt ... Cannot do that as the first loop modifies count. ... In my later implementations this is not possible any longer. ... Remember that many architectures already have their own architecture ...
    (Linux-Kernel)
  • Re: PHP site development
    ... of application implementations for this architecture. ... a feel for the front-end design using your architecture. ... "Tony Marston" wrote in message ...
    (comp.lang.php)
  • Re: Implementations of VLIW
    ... Sounds like a homework problem to me. ... Anyhow, if the implementations aren't binary-compatible with each other, ... they aren't the same architecture, ... expect two implementations of the same VLIW architecture to be binary ...
    (comp.arch.embedded)
  • Re: Implementations of VLIW
    ... Anyhow, if the implementations aren't binary-compatible with each other, ... they aren't the same architecture, ... implementations have SSE3 instructions, as one example. ... expect two implementations of the same VLIW architecture to be binary ...
    (comp.arch.embedded)