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

[Stephan Mueller]

Am Montag, 5. August 2013, 20:06:39 schrieb Dmitry Eremin-Solenikov:

Hi Dmitry,

>Hi Stephan,
>
>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:
>>>What about the following construction:
>>>* setiv() permits any iv, but then sets a special flag 'explicit IV'
>>>(?) * We add a special API like gcry_cipher_generate_nonce(), which
>>>will generate noonce. In case of GCM it will use additional data and
>>>a
>>>counter (or clock_gettime(?))
>>>
>>>  to generate IV according to SP800-38D, 8.2.1).
>>>
>>>* GCM decrypt() works with any IV set or generated.
>>>
>> The enc/dec function are not affected by the issue, because the setiv
>> function handles the IV. And I guess setiv would need the enforcement
>> logic to comply with 800-38D.
>
>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.

In general: how do you propose you want to construct or verify the 
"fixed field" and the "invocation field"?

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?

Moreover, there is a specific length requirement for the IV.
>
>>>* In FIPS mode GCM encrypt() fails, if 'explicit IV' flag is set (and
>>>works if IV was generated).
>>>
>> It is definitely ok to limit the solution to FIPS mode, from FIPS
>> perspective.
>
>Good!
>
>> However, even in FIPS mode, I guess you want to accept IVs
>> from the outside (e.g. when you set up an encryption channel where
>> two
>> sides need to agree on IVs). Therefore, there are valid reasons why
>> an
>> externally generated IV may make sense in FIPS mode. Thus, the
>> enforcement of the flag in FIPS mode may cripple the implementation
>> in a way that it may not be useful (just thinking aloud here).
>
>See above.
>
>> 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 
:-) )

Ciao
Stephan
-- 
| Cui bono? |