Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [P1619-2] bit-level vs. byte-level spec for EME2



Shai,
we had the same discussion for the specification of the GF 
multiplication in XCB, that in 1619.2-D2 has a "mixed" representation. 
The group agreed that we should use byte level specification there.

We should do the same for EME2, to get the draft consistent across modes.

If nobody objects, can you send me replacement text for that section 
when you have a chance?

Thanks,
Fabio


Shai Halevi wrote:
> I received the following comment from Brian Gladman, regarding the
> EME2 specification as in 1619.2-D2.
>
>> AES bit numbering puts bit sequence bits 8n .. 8n+7 in byte n and
>> puts bits with lower enumerations in _more_ numerically significant 
>> positions within bytes.  The field representation puts bit 8n .. 8n+7
>> in byte n and puts bits with lower enumerations in _less_ numerically 
>> significant positions within bytes.  EME2 hence uses two different
>> bit to byte mapping conventions and this makes it necessary to specify
>> which of these is used for EME2 data inputs and outputs (this impacts
>> on where the padding bits go).
>
> Looking at the EME2 spec, I believe that he is right. My intention was
> to have EME2 specified completely at the byte level, but this is not
> how the spec is written right now. So my proposal is to modify the EME2
> spec, eliminate all bit-level language and replacing it with byte-level
> description instead.
>
> Please note that this change means that EME2 will only be specified
> for byte strings (i.e., strings that consist of integral number of
> bytes). For example, it cannot be applied to a 129-bit string. I think
> that for the application domain of 1619.2, this is not a problem (but
> let me know if you think otherwise).
>
> The other alternative would be to keep the current bit-level
> description, but then we will have to specify the convention for
> bit<->byte transformation. For example, right now the Mult-by-alpha
> is defined on 16-byte strings, but it is applied for example to
> Key_3, which is described as a 128-bit string.
>
> -- Shai
>