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

[Dmitry Eremin-Solenikov]

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.

> 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.

> 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 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).

[skipped]

>>> As you only refer to 8.2.1, why not considering 8.2.2 as well?
>>
>>Because TLS uses 8.2.1 version of IV generation.
>
> Thanks for the hint.
>
> (PS: yes, I know: all are pointing out the issues, without telling that
> you did a good job in creating the GCM implementation in the first place
> :-) )

That is not a problem, I'm used to community reviews of patches.

There is one issue/topic, I'd like to especially ask for review/suggestions:
Is my usage/extension of handler fields correct, or I should somehow
improve that?

-- 
With best wishes
Dmitry