[RFC 2/2] FIXME: initial implementation of GCM
Dmitry Eremin-Solenikov
dbaryshkov at gmail.com
Mon Aug 5 18:06:39 CEST 2013
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.
>
>>* 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.
--
With best wishes
Dmitry
More information about the Gcrypt-devel
mailing list