Re: Cohen's paper on byte order

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

From: "Brian Gladman" <brg@gladman.plus.com>
Date: Tue, 8 Apr 2003 08:05:35 +0100

"David Hopwood" <david.hopwood@zetnet.co.uk> wrote in message
news:3E92331B.4A8363CE@zetnet.co.uk...
> Brian Gladman wrote:
> > If an _external_ octet oriented interface is needed (and this is what
thread
> > is all about) it surely has to be mapped in some way to the existing
> > external interface as described in section 3.1?
>
> Yes. That's what I've been saying all along:
> <http://groups.google.com/groups?selm=3C324734.BF5CB90C%40zetnet.co.uk>

Ok David, I separate you from Doug. You are saying that it is a matter of
convenience and utility, its Doug Gwynn who is saying it is ambiguous in a
way that impacts on interoperability.

> # In any case, given that the AES FIPS has already been published with a
> # bit-sequence interface, the least bad option now is to define an
> # octet-sequence interface to AES as well. Clearly this should be the
> # interface that is already being used by Rijndael implementations, i.e.
> # the one where 'HL' maps to 0xHL.
>
> (There's an error in that post; RIPEMD-160 is big-bit-endian. A note has
been
> added to P1363a about the problem with hash function bit order.)
>
> > So the gap that David and Doug assert is in section 3.2 is not there at
> > all - if there is a gap it is in section 3.1.
>
> I'm sure that I have never said which section would need to be changed.
> However, looking at the FIPS now, both 3.1 and 3.2 would require changes,
> since both refer to the input, output, and key *only* as bit sequences.

Only if the new interface were to replace the existing one.

> > And here it is an issue of convenience and utility rather than ambiguity
>
> Of course it is. As Paul Crowley said in an earlier thread:

> # The AES FIPS is not ambiguous per se, but the interface it defines is
> # not very useful, since overwhelmingly computer communication and
> # storage is done in octets; it would be far more useful if a mapping
> # between octet strings and bit strings was specified, using one of the
> # methods David Hopwood describes.

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 think the fact that many people are now using an alternative interface
might make it sensible to _augment_ 3.1 with an alternative external
interface for software implementations. But we have this interface anyway
so we would just be standardising custom and practice (no bad thing).

> > (but I would, now, add 'ordered' to 'bit sequences' here).
>
> A sequence is necessarily ordered. Saying "ordered sequence" may clarify
> what is meant for some people, but it's strictly a tautology.

I agree that this is not strictly necessary but the length of this debate
and the interesting ambiguities in existing standards it has thown up leads
me to believe that a little tautology may be of benefit here.

So whether we continue to disagree depends on whether you want to replace
the current external interface or whether you want to augment it with an
additional, equivalent octet based interface.

    Brian Gladman

Relevant Pages

  • Re: Are Java and JavaScript really so malicious for Windows system
    ... >>> functionality (writing scripts with a user interface). ... >> Which is what I thought I was saying. ... compartmentalized applications like FireFox. ... * The French Security Incident Res: ...
    (microsoft.public.security)
  • Re: Phil Gordon addresses 2006 BARGE
    ... newgroup itself continues to exist as one huge unmoderated group (as many ... but there is an interface that implements the ... If he is saying what I believe he is saying, which is what I have been ... Writing software is what I do, and I don't think a reader like I've ...
    (rec.gambling.poker)
  • Re: Operator overloading in C
    ... Eric Sosman wrote: ... saying ... If the mere fact that Doug disagrees with your proposal is ... a library that we could use, but it had only a C interface, ...
    (comp.std.c)
  • Re: eMac, 9.2 and WiFi ?
    ... The user interface was quite clearly the Macintosh interface, ... Ah but are we saying that everything pre X was rubbish, ... What do you think we were doing while Windows users hadn't even imagined ... Mac OS 9 is about seven years old. ...
    (uk.comp.sys.mac)
  • Re: Cohens paper on byte order
    ... but the interface makes this internal entity visible externally. ... external medium is to have a fixed correspondence ... byte of the AES document. ... For the octet, it is ...
    (sci.crypt)
Quantcast