Re: Cohen's paper on byte order
From: Mok-Kong Shen (mok-kong.shen_at_t-online.de)
Date: 05/03/03
- Next message: Mok-Kong Shen: "Re: Cohen's paper on byte order"
- Previous message: Mok-Kong Shen: "Re: Cohen's paper on byte order"
- In reply to: Bryan Olson: "Re: Cohen's paper on byte order"
- Next in thread: Mok-Kong Shen: "Re: Cohen's paper on byte order"
- Reply: Mok-Kong Shen: "Re: Cohen's paper on byte order"
- Reply: Douglas A. Gwyn: "Re: Cohen's paper on byte order"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 03 May 2003 12:49:14 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
>
> > Right. That is exactly my view and I said that earlier
> > in this thread. So one has a group of, say the first 8
> > bits of the block as depicted in the first row of Fig.2.
> > (Forget the 'byte' in that figure.) Now that group
> > of bits, e.g. 01001111
>
> Under universally standard notation which most of learned in
> grade-school, '01001111' means the integer one million ten
> thousand one hundred eleven (though in some computer languages
> it might be interpreted as 262,729 written in octal). If you're
> talking about a sequence of bits, please state it as such,
> perhaps as "[0, 1, 0, 0, 1, 1, 1, 1]".
You are exercising pedantry. There is an evident context
in our discussion, isn't it?
>
> > can be expressed in the hex
> > notation as 0x4f
>
> The 0x4f generally means the integer seventy-eight. Is that
> what you mean? If you're specifically referencing the hex
> notation of FIPS-197 you need to say so.
We are discussing in the context of FIPS, don't we?
There is only one commonb hex notation in my view, none
specifically for FIPS.
>
> > and one does an assignment to a
> > byte variable in one's program, e.g. bta=0x4f;. If
> > one outputs that to a physical medium, one gets an
> > octet. But there will be different octets (as a
> > sequence of 8 physical bits on the medium), depending
> > on the type of machines. Do you agree?
>
> Different octets? That's absurd. What machines are you talking
> about, or are you just making stuff up again?
This is because, as already discussed, that the
ordering of bits (with diverse numerical significance)
in a byte on the physical medium is unknown to the user.
If there are the same, then all the better and there
is no problem at all with AES, contrary to what Gwyn
claims.
>
> [...]
> >>Look up a protocol for sending octets over a bit-stream. Does
> >>it say to send the first bit of the octet or the last bit of the
> >>octet first? Or is the order defined some other way?
> >
> >
> > I cited earlier Markus Kuhn the following:
> >
> > Bigendian computer scientists send the most significant
> > bit or byte (="end") first or store it at the earlier
> > (= lower) address.
> >
> > Note that it includes 'sending ... bit ... first ...'
> > On a given machine, the 8 bits of an octet has
> > numerical significance 2^i. In which sequence the
> > bits of diverse significance is to be transmitted
> > between partners has to be agreed in a transmission
> > protocol, right?
>
> So I gather that means you refuse to look up such a protocol.
> You seem to be asking me if I think they have to have an agreed
> protocol. Why do you think I suggested you look at one? You
> won't put forth the effort, and, well, there's nothing I can do
> about that.
I accept/believe that the common transmission protocol
is perfect. If one e.g. sends 0x4f, the receiver will
always get 0x4f. Why should I study the details of
protocols for purposes of this thread?
>
> > But this is in fact a conversion.
> > The bits may be ordered differently on the two
> > machines. The transmission protocol, in that it
> > prescibes the sequence sending the bits of diverse
> > significance, guarantees that the octet assembled
> > (from the individual bits) at the recipient machine,
> > when interpreted as an integer, has the same value
> > as on the sender machine (although the physical
> > ordering of the bits may be different on the
> > machines, which we don't care). Do you agree with
> > this?
>
> You have right and wrong ideas mixed together. I agree with
> what I and others have told you so many times before: our
> communication (or storage/retrieval) systems transport the octet
> value intact.
Yes, the octect 'value'. Hence the transport ensures
that a bit sequence, e.g. 01001111, sent with the
value 0x4f, will get to the receiver in the same
form and result in the same bit sequence 01001111. I
don't have any objection to this.
>
> Contrary to your previous claims (which I assume you still mean
> by "conversion"), a machine outputs a byte the same way
> regardless of the kind of machine that will read it, and a
> machine reads a byte the same way regardless of what machine
> wrote it. What "conversion" step do you think there is between
> different types of machines that doesn't happen between two
> similar machines?
If there is no conversion work that need to be done,
then all the better for my purpose (in arguing against
any amendment to AES document).
>
> >>[...]
> >> > But as a matter of 'fact' you do have two different
> >> > kinds of machines, don't you? The same 0xpq assigned
> >> > to a byte variable of the program code will be output
> >> > differently on different types of machines.
> >>
> >>Oh, find out; don't just guess or make stuff up. Again, look up
> >>a protocol that represents octets with a bit-stream.
> >
> > I meant that, if one doesn't have or know the common
> > convention of transmission protocol, then there is
> > a way to help oneself.
>
> I meant what I wrote: don't just guess or make stuff up.
Like you, I (also) meant what I wrote.
M. K. Shen
- Next message: Mok-Kong Shen: "Re: Cohen's paper on byte order"
- Previous message: Mok-Kong Shen: "Re: Cohen's paper on byte order"
- In reply to: Bryan Olson: "Re: Cohen's paper on byte order"
- Next in thread: Mok-Kong Shen: "Re: Cohen's paper on byte order"
- Reply: Mok-Kong Shen: "Re: Cohen's paper on byte order"
- Reply: Douglas A. Gwyn: "Re: Cohen's paper on byte order"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
