Re: Cohen's paper on byte order

From: Brian Gladman (brg@gladman.plus.com)
Date: 04/07/03 

From: "Brian Gladman" <brg@gladman.plus.com>
Date: Mon, 7 Apr 2003 21:26:04 +0100

From: "Roger Schlafly" <rogersc@mindspring.com>
Newsgroups: sci.crypt
Sent: Monday, April 07, 2003 7:40 PM
Subject: Re: Cohen's paper on byte order

> "Eugene Starokoltsev" <eugene_o@gmx.net> wrote
> > Yes. AES external interface is defined in terms of bit sequences only.
> > So to make the situation clear we should consider three alternatives:
> > 1. AES external interfase is defined in terms of bit sequences only
> > (what we see now).
> > 2. AES external interface is defined in terms of sequences of integers
> > in the range [0..255] only.
> > 3. AES external interface is defined in terms of bit _and_ byte
> > sequences.
> > The last possibility is the worst, as different current communication
> > protocols use different byte-to-bits mapping. ...
>
> The fact that some people number bits differently is all the more
> reason for AES to use a specific definition. Otherwise, some
> systems may fail to be interoperable.

But there _is_ a specific definition of the input, output and key values for
AES in the FIPS - see section 3.1.

Morover, the objects identified in section 3.1 of the FIPS can be encoded in
ASN.1 X.690 semantics as bitstrings (8.6) and hence I assume that they can
be exchanged without ambiguity. The specific bit numbering does not matter,
only the fact that they are ordered without left/right ambiguity (which I
assume is true of ASN.1 X.690 bitstrings).

For _encrypted_ AES blocks there is no valid concept of internal structure
since the only thing that has any meaning is the whole block. Hence a
bitstring representation is a sensible mapping for such entities. On the
plaintext side, if sensible data goes in, sensible data will come out unless
the encoding of the data on the two systems is different (and a failure here
cannot sensibly be blamed on the FIPS).

Although AES interface objects should technically be encoded and exchanged
as bitstrings, we seem to have evolved through _custom and practice_ a more
efficient and practical means of doing the same job using arrays of bytes.
There are small risks in this but I believe that these are bearable given
the convenience of this interface and the almost universal implicit
understanding of how it works.

If, on the other hand, people wish to bypass the specified AES interface
(3.1) and interface directly to objects that are defined only for internal
use (3.2), then they need to have access to the documentation of the
implementation in order to understand how these objects are represented
internally. And, of course, they are living dangerously in interfacing
directly to them.

   Brian Gladman

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
    ... >> key input interface of an algorithm. ... > array versions of AES would be possible. ... This is equivalent to preserving the ... chunk is to be re-established when the chunk is ...
    (sci.crypt)
Quantcast