Re: Cohen's paper on byte order
From: Mok-Kong Shen (mok-kong.shen_at_t-online.de)
Date: 05/12/03
- Next message: Paul Rubin: "Re: U. S. Patent 6,175,625"
- Previous message: Sasha: "Re: MD5 "S" constants?"
- In reply to: Douglas A. Gwyn: "Re: Cohen's paper on byte order"
- Next in thread: Douglas A. Gwyn: "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: Mon, 12 May 2003 10:41:39 +0200
"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > Perhaps consider this way: Let there be two hardware
> > manufacturer s and t who depict the bits of a byte
> > variable as follows
> > _ _ _ _ _ _ _ _ (manufacturer s)
> > sa sb sc sd se sf sg sh
> > _ _ _ _ _ _ _ _ (manufacturer t)
> > ta tb tc td te tf tg th
>
> Why not make manufacturer t's depiction look like this:
> _ _ _ _ _ _ _ _ (manufacturer t)
> th tg tf te td tc tb ta
> which would perhaps make the issue clearer to you.
The fanciful manufacturer t could in fact choose to
designate in his manual something like
_ _ _ _ _
cat tiger whale dog lion ..........
As I explained to you in a previous post, I'll assign
the bits just in the 'same' manner, namely placing
input[0], the first bit of my sequence, to the first
location (which in this case happens to be designated
as 'cat'). Is that clear? So what is your point??
>
> > Note that these are simply names, only their ordering
> > in the above arrangement matters. Now these have
> > a natural correspondce, right?
>
> Right: sa to ta, sb to tb, etc.
See above.
>
> > So assignment of the bits to one byte variable in
> > the way I mentioned should give a result that
> > correspond to to the other variable ...
>
> But they won't, assuming the usual convention where
> in each manufacturer's diagram the numerically most
> significant bit was on the left. It doesn't matter
> whether you intend to perform arithmetic or not;
> the relationship between bit order as determined by
> numeric significance and bit order as determined by
> labelling sequence determines the bitwise
> endianness, if you consider the "bit sequence"
> packed into the storage unit to be ordered by the
> bit labels. Or, if as you seem to insist on doing,
> you ignore the manufacturer's bit labelling sequence
> and consider the packed "bit sequence" to be ordered
> MSb first, clearly you're applying a big-endian
> convention.
Allow me first a analogy: Imagine for business you
are going to employ a typist. Do you care whether she
also plays piano? (If she does play piano well, she
might give you some nice impression, while typing, that
a piece of Brahms were being played. But do you really
care for purposes of your business anything other
than her typing performance in terms of average number
of characters per minute?)
The difference of endian-ness could be used to explain
the incompatibilty, when external medium is exchanged
between different hardware. That may indeed be valuable
or essential in CS. But, as repeatedly said, this issue
of endian-ness is a 'general' issue of data transfer
and as such is NOT in the proper domain of AES. Do
you want to discuss that 'general' issue in this thread?
If you agree that the issue is outside the proper
domain of AES, I'll cetainly be glad to discuss the
topic of endian-ness with you.
Once more, one is doing what is called 'alphanumerical'
processing, in contrast to 'numerical' processing here.
If you code something like this:
unsigned char bt;
bt='z';
would you ever say to yourself 'Moment, I have to check
with the manual to see where the MSB/LSB of my hardware
is, for otherwise I could have done an error'?? If you
do exploit the capability of C for the byte data type
of being used in the way as an integer (which is not
available in a number of other languages) in your
program and you set the bits individually into a byte
variable 'and' also do use it as an integer, then you
surely have to care about the particular way that
the designer of the hardware has arranged to have
the MSB/LSB. But you are 'not' doing 'numerical'
processing in the context being currently discussed!!
>
> > Whether there are 'endian' or perhaps other very
> > interesting properties in there I don't care, because
> > I don't 'need' them.
>
> It matters very much for interoperability when data
> is represented in multibit objects, most usually as
> octets.
As said above, the difference of MSB/LSB could be at
the base of interoperability being observed in practice.
But if I, as user, am going to purchase new hardware
and find that kind of problem in relation to the
hardware I already have, I would demand from the provider
a conversion software to enable a proper data exchange
on external medium, e.g. via diskettes. I can't do
anything more reasonable, can't I? Yes, I could expect
some price reduction in return for the inconvenience
of doing the conversion. (BTW, I mentioned the conversion
issue quite early in this thread.) Of course, I could
also tell the standardization committee concerned
with computer data transfer to take care of this nasty
problem in practice. But then, as repeatedly said, what
has this really to do with the 'proper' domain of the
AES document, which is simply one application among
a millard of computer applications that uses the byte
data type in programming? (I like to note that you
have repeatedly avoided to answer to this point.)
>
> > Now both hardware output the same
> > byte variable to physical media, say diskettes.
>
> No, you have not defined what constitutes "the same
> byte variable" when all you consider is an ordered
> set of (8) bits. In the real world, two octets have
> the same value if they are *numerically* equal.
> But you cannot ensure that the external representation
> of your set of 8 bits will have the same numerical
> value on all platforms without specifying the
> piece of the AES specification omitted from FIPS-197,
> namely the connection between bit sequence used as
> input/output for the computation and bit significance
> order in the external octets.
Hopefully, both manufacturers also provide debuggers.
As long as the bits of a byte variable, as seen by
the user, are the same, i.e. with the same value
in the same order, that content is evidently the
same (from the logical view of the user) on both
hardware (for his purpose here, which is in common
jagon bit-programming, not numerical programming),
isn't it? See also above.
>
> > Are these diskettes interchangeable? If yes, evidently
> > no problem. If no, that's a problem to be resolved
> > as a 'general' issue of data transfer (in the
> > particular case of byte/character variable) and
> > not a specific issue that the AES document (an abstract
> > crypto algorithm description) has to include in its
> > domain. Isn't that very clear?
>
> It's very clear that you have learned nothing from the
> previous discussion. This is not a "general" problem,
> because we have adequate standards to ensure that
> octets can be exchanged among hosts without corruption
> of their (binary) numeric values. A correct solution
> does not involve supplying an AES-specific bit-order
> specification in every other information interchange
> standard, but rather supplying a single specification
> for this in the AES standard. That's where it belongs.
A certain character, say 'O', has a definite code value
according to a character standard, e.g. 79 which is
01001111 in binary in the common notation. (BTW, do
you accept the common convention of reading decimals
and hence binaries for human communication at least?)
If that binary (the bits in that order) is correctly
transferred, I have no problem. If not, that problem
is certainly and clearly NOT one that 'singularly'
affects AES. I mentioned above also bit-programming.
Is AES the single program where bit-programming is
done? Lots of real-time applications do that. How
about the interoperability there? There are quite
a number of standards concering real-time applications.
Do these similarly have to be amended (individually)
in the way you would think that they should -- instead
of having the standardization organizations solve the
problem 'generally' somewhere in a standard document
that properly deals with data transfer in 'general'??
M. K. Shen
- Next message: Paul Rubin: "Re: U. S. Patent 6,175,625"
- Previous message: Sasha: "Re: MD5 "S" constants?"
- In reply to: Douglas A. Gwyn: "Re: Cohen's paper on byte order"
- Next in thread: Douglas A. Gwyn: "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
|
