Re: Cohen's paper on byte order

From: Brian Gladman (fake@nowhere.org)
Date: 04/21/03 

From: "Brian Gladman" <fake@nowhere.org>
Date: Mon, 21 Apr 2003 09:16:43 +0100

"Douglas A. Gwyn" <DAGwyn@null.net> wrote in message
news:3EA37E3D.2050808@null.net...
> Mok-Kong Shen wrote:
> > 'Where' in the document it is said that these are
> > 'internal' values?
>
> What else could they be? FIPS-197 very carefully defines
> the 2-nybble byte notation specifically in the context of
> AES internal bytes (only), and also very carefully limits
> the external data model to a bit stream, with no reference
> to any other possible organization of the data externally.

Wrong. The pseudo code contains the byte array external interface. All
credible software engineers will identify the AES pseudo-code interface as
the same basic interface as that used by byte array versions of AES.

And all credible software engineers know that the input, output and cipher
keys applied to algorithms are external entities that an algorithm
specification cannot sensibly redefine.

If you choose to interpret this interface as exporting a definition of
finite fields so that the world can convert all its objects to finite field
objects in order to encrypt them, then that is _your_ choice. But its an
absurd interpretation since no sensible engineer would assume that this was
the NIST intention.

> > ... So if 'any'
> > document provides test vectors, you would claim
> > that these are 'internal' entities, ...
>
> No, I'm talking specifically about FIPS-197. Many
> (most?) comparable standards do specify external data
> format within each octet. FIPS-197 very intentionally
> does not.

Even in the absurd interpretation of a cipher key as only an internal
entity, section 3.2 does not apply since there are no braces on the byte
values. The FIPS is very careful to define the need for braces - {pq} -
whenever a byte represents a finite field in order to leave pq without
braces as an internal integer byte literal (integers do have internal uses
elsewhere).

It is clear that now that you have a choice either of holding on to your
absurd interpretation of the FIPS or of maintaining your credibility as an
experienced and sensible engiineer, it is the latter that you prefer to give
up.

I find this choice an odd one but I am never surprised by what people do
when they let their emotions override their common sense.

   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
    ... 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)
  • 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)
  • 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)