Re: Cohen's paper on byte order

• Previous message: Roger Schlafly: "Re: RIP proof secret splitting"
• In reply to: Mok-Kong Shen: "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"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
Date: Wed, 23 Apr 2003 21:01:17 GMT

Mok-Kong Shen wrote:
> "Douglas A. Gwyn" wrote:
> > Only in the sense that the I/O mapping is bitwise 1-1 onto,
> > which allows us to "identify" corresponding external and
> > internal bits.
> What do you meant by this?

It's standard mathematical terminology. When an isomorphism
is established, mathematicians like to use it to "identify"
corresponding elements as "essentially the same". This is
important since the elements are in fact *not* "the same".
A mapping is involved, and it plays a role in the
identification process.

> If a user has a certain
> key externally, then it is the programmers's job
> to have that same key exactly (i.e. semantically
> identical) in his algorithm/program.

There you go, ignoring the issue. What is "the same" key
expressed in two different formats, in the absence of a
known mapping between the domains? There are at least two
distinct ways the programmer could map between the external
and internal representations of the key. FIPS-197 does not
specify (at least, not explicitly and arguably not
implicitly) what that mapping is when the external
representation is other than a sequential bit stream.

You say it's the programmer's job, but deny him the
information he needs to do that job. The mapping needs
a specification.

> Why is any I/O issue relevant here?

How could you possibly not understand that after it
has been explained so many times? I/O is an issue
because in practice one must perform I/O in some way
(function parameters, etc.) to the module that
implements the AES algorithm. Interoperability
depends on different implementations performing that
mapping in compatible ways. Since the mapping is not
specified, interoperability is not ensured. That is
a flaw for such a standard.

> You argue that what is shown in Sec. A.1 as
> Cipher Key = 2b 7e 15 16 28 ae ..........
> denotes an 'internal' entitiy only, right?

Given that the notation used is derived from that
specified explicitly for internal byte values only,
and is in fact used for clearly internal-only
purposes throughout that Appendix and elsewhere in
the document, surely it is reasonable to infer that
this usage too refers to the clearly identified
element that enters as specified into the computation.

> Now, that internal entity has a representation also
> as a sequence of 128 bits as numbered in Fig. 2, ...

That particular element will indeed have a corresponding
set of "input" indexed bits.

> ... In my computation it should be ...

I'm not going to check that you properly translated
hex notation to binary notation. As I have said before,
*within* the I/O layer there is no issue! There is also
no issue, for those internal elements that are involved
in Input/Output, how the internal bit order maps to the
external bit-sequence indices. You're wasting time even
discussing this aspect.

> but IS simply the common universal convention of
> transcribing bit sequences to hexs and vice versa.

Nonsense. There is no common universal convention for
notating bit sequences within multibit objects. That
is why the FIPS had to specify its convention *even for
the internal use that follows the scheme you think is
universal*. But it clearly adopted a different, bit-
stream oriented, notation for input/output sequences.

> ... So that bit sequence can presently be considered
> to be external, ...

Why is this helpful? The FIPS provides a clear mapping
between internal and external bit sequences (involving
octetwise bit swapping).

> ... Now, being external to AES, one can
> surely apply the universal convention of transcription
> to hexs.

Even assuming for the sake of argument (but contrary to
reality) that your notion of that convention is "universal",
if you do that, you would mandate end-for-end bit swapping
at the I/O interface, which is not what Brian Gladman says
is the intention.

> Could you elaborate your arguments in view of the
> above? In particular, you said in a previous post
> about swapping of nibbles, if I don't err.

You err.

> See above.

Do you really think that your continual ploy of pretending
that you have satisfactorily addressed an issue elsewhere,
when all you have done is repeat the same questions and
make the same mistakes over and over, is fooling anybody
but yourself?

> No. The 'basic' notion is simply a block of 128 bits
> that is a 'sequence' and that has a sequential order.
> This is numbered 0-127 by the standard. Do you agree
> up till here? So, given such a block of bits externally,
> one has to (somehow, 'how' exactly I don't care) ...

Yes, indeed. I am convinced that you don't care.

• Previous message: Roger Schlafly: "Re: RIP proof secret splitting"
• In reply to: Mok-Kong Shen: "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"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]