Re: Cohen's paper on byte order

• Previous message: jsavard_at_ecn.ab.ca: "Re: Another history question was Re: Tunny and SIGABA"
• In reply to: Brian Gladman: "Re: Cohen's paper on byte order"
• Next in thread: Brian Gladman: "Re: Cohen's paper on byte order"
• Reply: Brian Gladman: "Re: Cohen's paper on byte order"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Sun, 25 May 2003 10:12:22 +0200

Brian Gladman wrote:
>
> "Mok-Kong Shen" <mok-kong.shen@t-online.de> wrote:

> > Why do you need my coorperation? I don't assume that
> > you should take the time to write the byte reversal
> > routine yourself in order to explain that to me.
> > But if in any piece of code or pseudo-code you
> > write byte_reversal(w1,w2), that is perfectly o.k.
> > to make it understandable for me.
>
> But I would like to see your actual code for this and where you put it in
> each of the two subroutines. And I would like to see what values are
> printed out as a result. Is writing this simple routine too hard for you -
> would you like me to write it for you?
>
> > A general reader
> > of the group certainly would also have no difficulty
> > in that. If it were something concerning high math,
> > then that could eventually be an issue. After all, I
> > indicated that a clumsy way is to unpack and then do
> > a reversal of the elements of a byte array. Would
> > my providing an explicit for-statement to do that
> > help in any sense? I highly doubt that that could be
> > the case.
>
> Yes that would help and would allow us to move on to the next step.
>
> We need actual code for the little endian version before we can move on.

I don't think so. The functionalities of any concrete
function could be adequatedly described in abstract
terms and properly understood and used as such in
discussions without having to examine its actual code
in a particular programming language. Let me explain
what I have mentioned as the situations when what I
termed as the 'reference' code is used to communicate
between partners, who employ either the same type of
hardware or different types and whether a 'standard'
format is used or not. I assume that the 'standard'
format is biased towards big-endian, i.e. there is
less work to be done on the side employing big-endian
hardware. I consider only 32 bits and assume the
data to be originally in the bit-array form, which is
fundamental for the AES algorithm, each bit being
stored though in an 'unsigned char', since C has no
standard data type to store a single bit. I assume
that one does the reading with unit of word and that
this is first transformed to bytes and then to bits,
although a direct transformation from word to bits is
possible. (Similarly for writing.) The suffices
a and b refer to the two users. The functions used
are the same (i.e. the same C codes), with evident
semantics, excepting that the C-standard functions
fread and fwrite have been modified in syntax and
renamed according to hardware types as littleendianread,
bigendianread, littleendianwrite and bigendianwrite,
since for the same physical bit chunks on an external
mediam, e.g. diskette, their effects are different
on reading on the two types of hardware and similary
on writing. (Apology for not employing '_' in the names.)

  unsigned char bitsa[32]; unsigned char bitsb[32];
  unsigned char bytesa[4]; unsigned char bytesb[4];
  unsigned int worda,tempa; unsigned int wordb,tempb;

Situation 1: Both users use little-endian, no use
             of standard format.

  Sender:
  packbitstobytes(bitsa, bytesa);
  packbytestoword(bytesa,worda);
  littleendianwrite(worda);

  Recipient:
  littleendianread(wordb);
  unpackwordtobytes(wordb,bytesb);
  unpackbytestobits(bytesb,bitsb);

Situation 2: Both users use big-endian, no use of
             standard format.

  Sender:
  packbitstobytes(bitsa, bytesa);
  packbytestoword(bytesa,worda);
  bigendianwrite(worda);

  Recipient:
  bigendianread(wordb);
  unpackwordtobytes(wordb,bytesb);
  unpackbytestobits(bytesb,bitsb);

Situation 3: Sender uses little-endian, recipient uses
             big-endian, no use of standard format.

  Sender:
  packbitstobytes(bitsa, bytesa);
  packbytestoword(bytesa,worda);
  littledianwrite(worda);

  Recipient:
  bigendianread(tempb);
  reversebytesinword(tempb,wordb);
  unpackwordtobytes(wordb,bytesb);
  unpackbytestobits(bytesb,bitsb);

Situation 4: Sender uses big-endian, recipient uses
             little-endian, no use of standard format.

  Sender:
  packbitstobytes(bitsa, bytesa);
  packbytestoword(bytesa,worda);
  bigedianwrite(worda);

  Recipient:
  littleendianread(tempb);
  reversebytesinword(tempb,wordb);
  unpackwordtobytes(wordb,bytesb);
  unpackbytestobits(bytesb,bitsb);

Situation 5: Both users use little-endian, use
             of standard format.

  Sender:
  packbitstobytes(bitsa, bytesa);
  packbytestoword(bytesa,worda);
  reversebytesinword(worda,tempa);
  littleendianwrite(tempa);

  Recipient:
  littleendianread(tempb);
  reversebytesinword(tempb,wordb);
  unpackwordtobytes(wordb,bytesb);
  unpackbytestobits(bytesb,bitsb);

Situation 6: Both users use big-endian, use of
             standard format.

  Sender:
  packbitstobytes(bitsa, bytesa);
  packbytestoword(bytesa,worda);
  bigendianwrite(worda);

  Recipient:
  bigendianread(wordb);
  unpackwordtobytes(wordb,bytesb);
  unpackbytestobits(bytesb,bitsb);

Situation 7: Sender uses little-endian, recipient uses
             big-endian, use of standard format.

  Sender:
  packbitstobytes(bitsa, bytesa);
  packbytestoword(bytesa,worda);
  reversebytesinword(worda,tempa);
  littledianwrite(tempa);

  Recipient:
  bigendianread(wordb);
  unpackwordtobytes(wordb,bytesb);
  unpackbytestobits(bytesb,bitsb);

Situation 8: Sender uses big-endian, recipient uses
             little-endian, use of standard format.

  Sender:
  packbitstobytes(bitsa, bytesa);
  packbytestoword(bytesa,worda);
  bigedianwrite(worda);

  Recipient:
  littleendianread(tempb);
  reversebytesinword(tempb,wordb);
  unpackwordtobytes(wordb,bytesb);
  unpackbytestobits(bytesb,bitsb);

Now you could say what would you like to do differently
in order to gain that claimed 15% efficiency, i.e.
which functions you would additionally employ and
which you would throw away, if any, and what properties
these additional functions have.

Thanks in advance.

M. K. Shen

• Previous message: jsavard_at_ecn.ab.ca: "Re: Another history question was Re: Tunny and SIGABA"
• In reply to: Brian Gladman: "Re: Cohen's paper on byte order"
• Next in thread: Brian Gladman: "Re: Cohen's paper on byte order"
• Reply: Brian Gladman: "Re: Cohen's paper on byte order"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]