Re: Cohen's paper on byte order
From: Mok-Kong Shen (mok-kong.shen@t-online.de)
Date: 04/15/03
- Next message: Matfys: "Re: What is the best way to break polyalphabetic ciper?"
- Previous message: Eugene Starokoltsev: "Re: Cohen's paper on byte order"
- In reply to: Eugene Starokoltsev: "Re: Cohen's paper on byte order"
- Next in thread: Eugene Starokoltsev: "Re: Cohen's paper on byte order"
- Reply: Eugene Starokoltsev: "Re: Cohen's paper on byte order"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: Mok-Kong Shen <mok-kong.shen@t-online.de> Date: Tue, 15 Apr 2003 10:22:58 +0200
Eugene Starokoltsev wrote:
>
> "Brian Gladman" <brg@gladman.plus.com> wrote:
> > > As the pseudocode is a part of FIPS it uses the definition of byte
> > > from FIPS. I don't see any umbiguity there.
> >
> > The problem is a rather technical one about abstraction. As written the
> > entity called a 'byte' is only strictly defined internally ( ...Bytes _in_
> > AES ...) but the interface makes this internal entity visible externally.
>
> To be precise, the AES pseudocode thought by somebody be a
> specification of AES interface.
>
> Indeed, I know now three different types of bytes: commonly used bytes
> (i. e. small unsigned integers in the range [0..255]), AES internal
> bytes and C standard bytes. It would be better do not name AES bytes
> as bytes but it is too late to change something.
>
> > The issue is a little easier to understand for multiple byte entities since
> > we have become used to dealing with it and know that there are two different
> > orderings. But we don't often have to sort out the nibble or bit order in a
> > byte and this makes us complacent about it.
> >
> > But when a situation comes up where this matters, a slightly disguised
> > version of the endian war breaks out.
>
> Absolutely right.
>
> > What is less clear (to me at least) is whether we can add an external octet
> > array interface on top of the current bit sequence interface in a way that
> > pleases everyone.
>
> As we have agreed there is no real problems with interface of AES
> implementations so we discuss now a possibility of formal
> specification of such interface only. The possible solutions I see
> are:
>
> 1. Let the situation as it is now. In spite of some critique the real
> practice is fine.
>
> 2. Insert into specification a recommendation for AES implementations
> external interface. I don't object to this in principle but I think
> that the addition must not be requirement (a recommendation only), it
> must clarify that the principal abstract interface of AES is specified
> on bit strings and it should recommend to specify correct mapping in
> specifications for external protocols using AES. While this addition
> is redundant it will not add restrictions or umbiguity. The possitive
> effect of the addition would be clarification of the situation with
> AES interface and standard implementations. The problem I see now is
> that a meaning of 'octet' (which we'd use for such interface) seems to
> be not well-specified. Do you know a complete and unambiguous standard
> definition of 'octet'? I don't.
>
> 3. To add a second equal in rights byte-level interface. I strongly
> oppose to this idea for reasons I have wrote a few times before.
[snip]
Could you please say what that 'interface' would mean
(with consideration of what I wrote in a follow-up
sent some 1/2 hour ago)? Thanks.
M. K. Shen
- Next message: Matfys: "Re: What is the best way to break polyalphabetic ciper?"
- Previous message: Eugene Starokoltsev: "Re: Cohen's paper on byte order"
- In reply to: Eugene Starokoltsev: "Re: Cohen's paper on byte order"
- Next in thread: Eugene Starokoltsev: "Re: Cohen's paper on byte order"
- Reply: Eugene Starokoltsev: "Re: Cohen's paper on byte order"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
