Re: Cohen's paper on byte order

From: Eugene Starokoltsev (eugene_o@gmx.net)
Date: 04/09/03 

From: eugene_o@gmx.net (Eugene Starokoltsev)
Date: 9 Apr 2003 08:18:17 -0700

"Douglas A. Gwyn" <DAGwyn@null.net> wrote in message news:<3E932C30.7040009@null.net>...
> Eugene Starokoltsev wrote:
> > ... But this mapping will help only in situations where
> > data is represented by plain strings of bytes like Unix files but not
> > for Mac files for example.
>
> So long as there is no "resource fork" those files are
> essentially the same. People who download from the Web
> can save the file under MacOS or Unix and upload it
> again without change.
>
> By far the most common organization for generic data
> these days is as an array of octets with a known and
> enforced interpretation of each octet as an unsigned
> integer. The fact that you can read what I typed in
> this message is crucially dependent on that fact.
>
> > It is strange to expect from [AES] something else.
>
> No, it isn't. AES was *meant* to be a building block
> in systems that need to communicate securely across
> multiple platforms. The minimum interface requirement
> necessary to connect such a building block into a system
> so that all implementations can correctly communicate
> using AES (given the appropriate keys) is specification
> of which bits go where in each octet in the array. It
> is evident how to order the blocks within a file and,
> probably, the octets within each block. We're only
> missing the specification for ordering the bits in an
> octet.

So the community needs to define some standard way to use different
cryptografic algorithms having bit-stream external interface with
byte-stream communication protocols. I suspect some standard exists
already but we do not know it. It is not AES-specific problem. And
FIPS-197 is not the place to add such specification because modes of
operation are specified in terms of bit streams.