[RFC 2/2] FIXME: initial implementation of GCM

[Stephan Mueller]

Am Montag, 5. August 2013, 21:41:30 schrieb Dmitry Eremin-Solenikov:

Hi Dmitry,

>On Mon, Aug 5, 2013 at 9:12 PM, Stephan Mueller <smueller at chronox.de> 
wrote:
>> Am Montag, 5. August 2013, 20:06:39 schrieb Dmitry Eremin-Solenikov:
>>>On Mon, Aug 5, 2013 at 7:55 PM, Stephan Mueller <smueller at chronox.de>
>>>
>> wrote:
>>>> Am Montag, 5. August 2013, 19:17:58 schrieb Dmitry Eremin-
Solenikov:
>>>Let me rephrase the issue in a little bit different way, so that you
>>>see my point:
>>>'GCM should not use the same IV for encryption more than once with a
>>>given key'. 800-38D talks about calling 'authenticated encryption'
>>>function with same IV. 800-38D does not have any requirements about
>>>'authenticate decryption' function with respect to IV vectors.
>>>
>>>Thus we should not allow using 'bad' IV vectors for encryption only.
>>>Adding a check
>>>to gcm_encrypt() looks like a sufficient protection.
>>>
>> Of course, here I am with you. Covering the encrypt operation is
>> sufficient.
>> 
>> Yet I fail to understand your proposal to handle 8.2.1 compliance.
>> When you use clock_gettime, there is a chance greater than zero that
>> you get two identical values. Note, CLOCK_REALTIME/CLOCK_MONOTONIC
>> is affected by ntp drift and ntp updates, CLOCK_MONOTONIC_RAW may
>> not be available on every system.
>
>I forgot about clock_monotonic being affected by ntp :(
>In the end this can be as simple, as static counter, being incremented
>on each call to generate_iv().
>
>Or (if that would still satisfy 800-38D) have that counter in cipher
>context (oh, my, another one). Thus one can assume that if a key is
>set on the cipher context,
>all further generate_iv() invocations would increment that counter.

That solution is explicitly allowed in 8.2.1.

"The invocation field typically is either 1) an integer counter or 2) a 
linear feedback shift register
that is driven by a primitive polynomial to ensure a maximal cycle 
length. In either case, the
invocation field increments upon each invocation of the authenticated 
encryption function."
>
>> In general: how do you propose you want to construct or verify the
>> "fixed field" and the "invocation field"?
>
>"fixed field" can be specified during generate_iv() invocation.
>"invocation field" is a copy of a counter.

Well, shouldn't there be a service offered to generate an iv that even 
generates the field if the caller has no clue (e.g. provides NULL for 
the fixed field)? I mean, how shall a caller come up with a unique fixed 
field value?
>
>> The invocation field must be modified after each authentication. That
>> modification must still ensure that the invocation field is unique.
>> How shall that be done?
>
>Hmm. I would increment that during generation. You have to reset

right, or use a shift register as specified in 8.2.1.

>internal GCM counter to 0 values (so that your tag is correct).
>Currently it is done either via setiv() (reset() will zero a marks.iv
>flag, thus next encryption/decryption
>operation will call gcm_setiv() internally).
>
>> Moreover, there is a specific length requirement for the IV.
>
>I think there are not. Spec says, that for |IV| < 96 bits, one must use
>8.2.1, for |IV| >= 96, it should use one of 8.2.1 or 8.2.2 (but only
>one of them).

Right, scratch my remark.


[...]

Ciao
Stephan
-- 
| Cui bono? |