Re: [STDS-802-16] Clause 7.5 Changes in Cor1
Jeff,
Wrt 2:
The NIST spec treats the ICV as something like a number. They write is
as a big hex number (hence msb on the left, equating to byte index 15).
I have taken the msb to be the thing on the left of the number in the
NIST spec.
Nevertheless I agree that this is just an resonable interpretation and
not a hard and fast rule, so read strictly it could be considered
ambiguous.
I think the solution is to avoid lots of waffly text and instead include
a couple of example PDUs, both plaintext and correctly encrypted. This
would disambiguate anything in the text to do with byte order or nonce
construction.
DJ
-----Original Message-----
From: owner-stds-802-16@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-16@LISTSERV.IEEE.ORG] On Behalf Of Jeff Mandin
Sent: Wednesday, March 23, 2005 3:31 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] Clause 7.5 Changes in Cor1
1. Yes - the original PN text was unambiguous so I'm not sure why the
endian-ness change was introduced. It should be changed back to
little-endian ASAP as currently there is no clear standard for
interoperability.
2. It's not obvious what it means for the ICV to have endian-ness as
it's a bit string rather than a numeric value. It should be sufficient
for the text to say that the highest order bytes of the CBC output are
the ones that are truncated to create the ICV.
- Jeff
On Wed, 23 Mar 2005 10:13:32 -0800, Johnston, Dj <dj.johnston@intel.com>
wrote:
>
> The changes in 7.5.1.2.1 and 7.5.1.2.2 in Cor1 appear to be out of
scope.
>
> The effect is to reverse the byte order of the ICV and PN fields.
> However the text in 802.16-2004 is neither erroneous, ambiguous nor
inconsistent.
> The specification works fine with the endianess either way around, so
it is
> not within the scope of Cor1 to make this change.
>
> Also, it introduces an ambiguity with the diagrams that have not been
> updated to reflect the text change.
>
> DJ
>