Re: Cohen's paper on byte order

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

Date: Sat, 26 Apr 2003 01:14:31 +0200

Brian Gladman wrote:
>
> "Mok-Kong Shen" <mok-kong.shen@t-online.de> wrote:

> [snip]
>
> > Further, Brian Gladman in his follow-up (to me) of
> > Mon, 21 Apr 2003 09:37:26 +0100 wrote in this connection:
> >
> > Yes, this eliminates any second version since a
> > cipher key is an external entity applied to the
> > key input interface of an algorithm.
> >
> > He said 'explicitly' that the 'cipher key' is [also]
> > an 'external' entity. I don't yet see that you found
> > his opinions to be gravely in error and hence offered
> > any corrections or counter-arguments to his opinions.
> > Could you please kindly 'directly' follow-up to his
> > post now? He has done lots of work on actual software implementation of
> > AES and was also involved in the
> > documentation process, if I don't err. So very
> > certainly you would get good discussions with him on
> > this very essential point and many readers would
> > thereby profit from the ensuing discussion results.
> > (I certainly don't assume that you have any intention
> > to avoid debating with him on that issue.)
>
> Doug Gwyn and I disagree on this point but I am not sure whether this really
> matters much since we do agree that, if the specification had been a perfect
> bit sequence specification, two non-interoperable but FIPS compliant byte
> array versions of AES would be possible.
>
> Although the byte array interface is in the FIPS (in the pseudo code), it is
> not formally described in the early part of the FIPS where the algorithm
> interface is formally specified. I do consider this an omission which it is
> desirable to correct.
>
> In my view it would be more productive to discuss the ways in which this can
> be resolved rather than keep discussing the nature of the problem since no
> serious commentator denies that there is an issue here. In principle we can
> do one of several things:
>
> 1) do nothing.
> 2) add the byte array interface in the I/O interface section of the FIPS.
> 2a) do nothing more.
> 2b) state that implementations must specify which version they offer.
> 2c) state a preferred version explicitly (i.e. ratify the current FIPS
> implicit bias).
> 2d) mandate only one version (the one used now).
> 2e) do something else.
> 3) do something else.

I argued, in particular in one long follow-up to Gwyn
(sent some 1/2 hour ago) that one has 'only' to take
into consideration that, when transporting a block of
128 bits, the indices of the individual bits are to
be preserved. This is equivalent to preserving the
indices of the 'byte' of Fig. 2, if, in addition, the
indices of the 'byte's are preserved. (This criteria
is in fact trivial and can be used as a simple check
of correctness of any transport protocol for AES.)
Why should one 'think' in an AES application that a
group of 8 bits could (also) be interpreted as a
binary integer and hence LSB/MSB? AES makes no use
of that integer value, as far as I am aware. If a
data transport agent could in some way make use of
such an interpretation to 'facilitate' its work,
then fine, but then it has to take corresponding
care to do its job in such a way that the semantics
of AES indexing of its block of bits as given in
Fig. 2 (whether the first row or the second row
is immaterial) is preserved. Equivalently, this
means that the left-to-right order of an 8-bit
chunk is to be re-established when the chunk is
finally delivered at the target location, no
matter what manipulations have been done in transit.
(To take an extreme example, it could do a
dictionary look-up to find a (unique) word for
the chunk and transmit that word instead and at
the receiver end do a second dictionary look-up
to deliver the right chunk. There isn't then
any LSB/MSB in the mentioned sense.)

I take the standpoint that there is no incompleteness
of specification with respect to issues being discussed
in this thread. Hence in my conviction 'do nothing' is
the only right solution. But my discussion with Gwyn
continues and I certainly can't prematurely tell
whether I am indeed right. So one needs to wait till
that comes to a definite and clear end.

M. K. Shen

Relevant Pages

  • Re: Cohens paper on byte order
    ... I don't see any umbiguity there. ... > AES ...) ... but the interface makes this internal entity visible externally. ... Insert into specification a recommendation for AES implementations ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... > from FIPS. ... but the interface makes this internal entity visible externally. ... >> The view that this is not specifically an AES issue is partly but not ... candidate algorithms than it did to code the algorithms. ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... At the moment the FIPS specifies only a bit sequence interface. ... seriously discussed is a byte array interface but this is actually only one ... During the AES effort people used arrays of 8, 16, ... 32 and 64 bit units with an overlapping mix of address and numeric ordering. ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... AES external interface is defined in terms of bit sequences only. ... ASN.1 X.690 semantics as bitstrings and hence I assume that they can ... plaintext side, if sensible data goes in, sensible data will come out unless ...
    (sci.crypt)
Quantcast