Re: Cohen's paper on byte order

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

  • Next message: Martin4: "Re: Comparison of crytography methods"
    Date: Tue, 29 Apr 2003 06:17:00 +0200
    
    

    Mok-Kong Shen wrote:
    >
    > Brian Gladman wrote:
    > >
    > > "Mok-Kong Shen" <mok-kong.shen@t-online.de> wrote:
    >
    > > > Allow me to ask a few questions (to all who are
    > > > interested in the AES interoperability issue). Isn't
    > > > it reasonable to require the following: An AES block,
    > > > as defined as a bit sequence of 128 bits should be
    > > > written (for purpose of data exchange) to an external
    > > > medium always as a block of contiguous 128 bits in
    > > > the sense of a mirror image to Fig. 2, with the bit
    > > > corresponding to input_0 placed nearer the lower end
    > > > of the address space. Isn't this a 'natural' mapping?
    > >
    > > To do this you would need a bit addressable medium. This could be provided
    > > and would work but it would be inefficient when compared with using an array
    > > of bytes.
    > >
    > > However, there is no point in inventing solutions that exchange bit
    > > sequences since everyone agrees that this part of AES works. The issue is
    > > how can we pass 128 bit blocks in arrays of sixteen 8 bit bytes.
    > >
    > > In fact everyone agrees that the way to do this is to use a byte array
    > > interface with address order down to byte level and then to map bit
    > > addresses onto 8 bit numbers in order to overcome the lack of bit addresses.
    > > So all we have to do here is to say within bytes whether low bit numbers map
    > > to bits with low numeric significance or vice versa.
    > [snip]
    >
    > I am afraid that I am yet far from capturing the
    > real problem.
    >
    > Assuming thus that one communicates in units of bytes,
    > let's, for example, have a user specified key written
    > in hex as 0x01020304111213142122232341424344, or
    > equvalently as bit sequence
    > 0000 0001 0000 0010 0000 0011 0000 0100 0001 0001 .....
    > Evidently the notation of Fig. 2 can be applied to
    > this sequence such that input_0 refers to the leftmost
    > bit above, etc. Now we chop up the bit sequence into
    > a sequence of bytes, written in hex:
    > 0x01 0x02 0x03 0x04 0x11 0x12 0x13 0x14 0x21 ......
    > Is this acceptable? If yes, we transmit the bytes
    > one by one in this order. Can we assume that, if one
    > tells the communication system to transmit a byte 0xpq,
    > it will always deliver the byte correctly to the
    > recipient, namely 0xpq? If yes, then the sequence of
    > bytes can be concatenated by the recipient and that
    > will give exactly the bit sequence of the user.
    > If not, this would mean that one is not even able to
    > transmit a single ASCII character (which is a byte
    > of the form 0xpq) always correctly, which I would very
    > seriously doubt. (One would then also have had
    > problems in reading e-mails or posts of internet
    > groups, wouldn't one?)
    >
    > Thanks.

    Addendum:

    I don't think that any non-interoperability could
    arise in either (1) bit array or (2) byte array
    interfaces. (1) is trivial. (2) is clear as well,
    if one assumes that individual bytes (0xpq) can be
    correctly transmitted. Some URLs I read do mention
    the issue of which bit of a byte should be sent
    first over a channel. But that's clearly a problem
    of the communication protocol that is at a level
    that we (who work at the level of e.g. C codes)
    shouldn't be concerned with, if I don't err.
    Therefore, difficulty could in my view only arise
    when one starts to operate with larger units than
    8 bits, e.g. unsigned int. Here, of course, the
    issue of big-endian vs little-endian sets in. To
    repeat: I don't yet see how a byte array interface
    could cause problems (I could see only possible
    problems with an 'unsigned int' array interface.)

    M. K. Shen


  • Next message: Martin4: "Re: Comparison of crytography methods"

    Relevant Pages

    • Re: The code of co-workers
      ... -all of the pointers have to be valid (dereferencing an invalid pointer ... -*i+1 and *j+1 must be valid indices into the array that a points into ... these are modified between the same pair of sequence points (modifying ... To avoid burying any useful diagnostics in useless ones, ...
      (comp.programming)
    • Re: Cohens paper on byte order
      ... > you changed from a bit sequence to what appears to be ... an array of unsigned char to represent a bit array, ... in the reverse order instead? ... But the user input IS at the beginning a bit array ...
      (sci.crypt)
    • Re: storage for temporaries
      ... In an expression the array rvalue ... > is converted to a pointer to its first member. ... > storage for the structure value. ... access it after the next sequence point, ...
      (comp.lang.c)
    • Re: Check for Common character sequence ( I will pay)?
      ... Yes you are returning an array of FoundString objects. ... in more than one string. ... This means that you have to identify sequences 1 character at a time, ... Again, obviously, if the 3-character sequence doesn't match, neither will ...
      (microsoft.public.dotnet.framework)
    • Re: convert FM signal into bit sequence
      ... I am basically trying to successfully transmit ... To transmit a sequence of bits ... I generate an AM wave* (it is similar to a square wave ... The transition between should take many cycles of the carrier to avoid generating "splatter". ...
      (comp.dsp)