Re: Cohen's paper on byte order

From: Paul Crowley (paul@JUNKCATCHER.ciphergoth.org)
Date: 04/08/03 

From: Paul Crowley <paul@JUNKCATCHER.ciphergoth.org>
Date: Tue, 08 Apr 2003 12:25:25 GMT

"Brian Gladman" <brg@gladman.plus.com> writes:
> Ok, we agree but some have definitely said that the FIPS is
> ambiguous in a way that prevents interoperability. I apologise for
> wrongly associating you with their stance.

I'm not sure that "ambiguous in a way that prevents interoperability"
is a thing it would make sense to say about the AES FIPS.

You could say it about, say, a standard for USB nose hair trimmer
controls. You have to be able to plug it in and see it go. If the
standard is specific enough, it will work; if it's ambiguous, it may
fail.

But the AES FIPS isn't useful by itself; it's only useful when
referenced in another standard, one that defines a communication or
storage protocol. That standard will have to specify some things
about how AES is used, such as perhaps selection of chaining modes or
where the IV is and so forth. In that sense, AES implementations
can't interoperate - only standards based on AES can interoperate.

So I think what the uint8-ists are saying among us is that
overwhelmingly, those standards that reference the AES FIPS will be
handling uint8s on every level - the data they handle will be uint8s,
the communication mechanism will carry uint8s, and so forth. As
things stand, if those protocols don't say anything about the ordering
of the bits in a uint8, then they are strictly ambiguous -
implementors will be relying on informed guesses and common practice
to get it right. If someone makes an implementation that goes the
other way, there won't be a part of either standard anyone can quote
to say that the implementation is wrong, which runs counter to the
whole purpose of standards.

In other words, as things stand, the burden of defining the
bits<->uint8 mapping has been pushed onto every standard that uses the
AES FIPS. It doesn't seem unreasonable to hope that a future revision
of the FIPS could fix this situation by defining the mapping itself.

We would be in almost exactly the same situation if AES were defined
on, say, sequences of 32-bit unsigned integers: it wouldn't be
ambiguous as such, but every standard that used it would have to
define a mapping betwen 32-bit ints and the data they had to encode,
which would probably be uint8s.

Obviously different standards will have different needs, and AES can't
be expected to meet all of them. But it's a fact about the world that
uint8s are the *overwhelmingly* prevalent lingua franca, and so a
standard that specifies how to use them is vastly more useful. 

-- 
  __  Paul Crowley
\/ o\ sig@paul.ciphergoth.org
/\__/ http://www.ciphergoth.org/

Relevant Pages

  • Re: Cohens paper on byte order
    ... Nothing in the whole standard appears to me to try to talk ... > are external to the FIPS but which are used to test the validity of AES ... valid although obscure reasons, ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... NIST - implements AES in accrdance with the FIPS specification! ... byte array interface, in principle, we then have two non-interoperable ... there is a really good chance that this will set a wider standard. ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... > Why not make manufacturer t's depiction look like this: ... between different hardware. ... and as such is NOT in the proper domain of AES. ... > for this in the AES standard. ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... A normal user (a programmer working with a common ... the program of the recipient. ... transmission of the AES block. ... defined 'standard' functions for doing the conversion ...
    (sci.crypt)
  • Re: Cohens paper on byte order
    ... > not have any defined bit sequence within an octet; ... > of the FIPS as a guide to how to organize the external ... AES with an octet array interface that is consistent with the AES-FIPS ...
    (sci.crypt)
Loading