Re: Cohen's paper on byte order

• Previous message: Bryan Olson: "Re: Cohen's paper on byte order"
• In reply to: Bryan Olson: "Re: Cohen's paper on byte order"
• Next in thread: Bryan Olson: "Re: Cohen's paper on byte order"
• Reply: Bryan Olson: "Re: Cohen's paper on byte order"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Date: Wed, 09 Apr 2003 23:56:36 +0200

Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
> > Bryan Olson wrote:
> >>Mok-Kong Shen wrote:
> >> > In any machine, the byte has a lower order bit and
> >> > a higher order bit (one near the lower end and the
> >> > higher end of the computer storage). Using a mask, one
> >> > can access the bits from one end of the byte to the
> >> > other. So where is the problem??
> >>
> >>The problem is Shen guessing at stuff and posting it as fact. We
> >>can now add "low order bit" to the long list of terms he uses
> >>without knowing what they mean.
> >>
> >>Incidentally, low order-bit-first is backwards from the way most
> >>crypto algorithms do things (including Rijndael), and would
> >>result in failing tests or failure to interoperate.
> >
> >
> > What does that 'first' in 'low order-bit-first' mean?
>
> It means when converting between an octet and a string of eight
> bits, map the octet's least-significant bit to the strings first
> bit. As we saw, the MD5 spec specifies the other way - most
> significant bit first.

Why do you need that notion in the present context?
I detailed that there is no problem of ambiguity
in any mapping of the chunk of 8 bits from its location
in a file to a variable in one's program under any
situations (with any weird OS, compiler, etc.) If
you use a specific conversion scheme, yes, you may
happen to need the notion of 'least significant'
or 'first' etc. But that's not the point of the
present discussion. The point is existence of ambiguity
or not and I have shown in the last post that there
can't be any ambiguity in any situations, no more
nor less.

>
> > If an 8-bit chunk is input, say, from a file into
> > a variable in program, all 8 bits are there. What is
> > then 'first'?
>
> It's exactly as I've said before. An octet is an eight-bit
> unsigned integer. It has a most-significant bit and a least
> significant bit. It does not a well-defined first bit and last
> bit.

I don't care whether a chunk of 8 bits in a file has
the significance of numerical value as an integer or
not. I only assume that there are such a group of
bits. That's the weakest assumption. Why do you
'want' stronger assumptions??

> > You mentioned in a previous post of
> > possible dependence even on compiler. o.k.
>
> Specifically, when Shen falsely claimed that C structs have a
> bit with a lowest address, I pointed out that he was talking
> nonsense. Layout of bit fields is up to the compiler and C
> doesn't assume any bit even has its own address.

The following is what I wrote:

  As an addendum to my previous post, I like to mention
  that the fact that in C one could define a data structure
  to access the individual bits clearly indicates that
  the physical bits in hardware has a natural numerical
  ordering. Therefore in any 8-bit chunk of hardware
  there is a bit with the lowerest address. This bit is
  clearly the unique candidate to be designated as the
  bit 0 of the chunk in my conviction.

That means I can access the bits in hardware in a
definite and orderly way. If follows that the bits
in hardware are not like a mathematical set where
the elements have no order among them but that
there exists a certain natural numerical order.
Note that I didn't say anything about 'address' of
bits in C. But the above means that in the hardware
(the file) the bits can be considered to be
addressable in numerical order from the program
(in certain definite way). What's wrong with that
actually? (I don't understand you here.)

>
> > But the
> > file has clearly a beginning and an end. Thus the
> > chunk in the file has a bit near the beginning of the
> > file and this is naturally the lower order bit of the
> > chunk, name it bit-0. Now this bit, depending on OS,
> > compiler, or what not, will occupy a certain fixed
> > position in the set of 8 bits after arrival in the
> > said variable. Therefore one can know where to
> > extract that bit with a corresponding mask. The other
> > bits may be similarly extracted, no matter how weird
> > or unreasonable/surprising the OS, compiler or what
> > not has mapped the bits from the file to the variable.
> > This shows that there cannot exist in any conceivable
> > situation any problem of ambiguity (i.e. not knowing
> > exactly where the individual bits are after their
> > being loaded in). So is there anything troublesome
> > 'unsolvable' problem need to be treated in this respect?
> > (I am surprised to learn of phantom problems.)
>
> So that's one of the two reasonable ways to define how bit
> strings map to octets. Most crypto algorithms (that need such a
> mapping) use the other. FIPS-197 doesn't strictly-speaking say,
> though its use of hex constants certainly suggests equivalence
> to the Rijndael spec.

I have in this thread never considered the issue of
which mapping is more desirable (efficiency etc.)
I only wanted to point out that there is clearly a
way to implement the AES correctly based on the
document as it is, i.e. without being misled by
any ambiguity (for there is in fact no ambiguity at
all). I'll thus be satisfied, if it is agreed that
there is no ambiguity issue.

M. K. Shen

• Previous message: Bryan Olson: "Re: Cohen's paper on byte order"
• In reply to: Bryan Olson: "Re: Cohen's paper on byte order"
• Next in thread: Bryan Olson: "Re: Cohen's paper on byte order"
• Reply: Bryan Olson: "Re: Cohen's paper on byte order"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]