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

[Dmitry Eremin-Solenikov]

On Mon, Aug 5, 2013 at 6:01 PM, Werner Koch <wk at gnupg.org> wrote:
> On Mon,  5 Aug 2013 14:28, dbaryshkov at gmail.com said:
>
>> I will probably add a note that to be fully compatible with NIST
>> recommendations,
>> one have to generate IV according to the specification.
>
> If the standard requires a certain way to generate an IV we need to make
> sure that it is done in this way.  If there is an application which
> can't work with such a high-level approach we may revisit this and
> decide whether to add a low-level API for this case.

The problem is that IETF standards (RFC 5116/5288) are not _that_strict.
As far as I understand text, it only proposes a way to generate nonce (which
looks like 8.2.1). And 5288 requires distinct explicit nonce, but then it tells
that it may be a TLS sequence number (and thus might be not).

To make things worse:
libgcrypt should permit using any IV for decryption. Thus we should not impose
any additional requirements on setiv() if the user wants only to
decrypt a message.

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.
* In FIPS mode GCM encrypt() fails, if 'explicit IV' flag is set (and works
  if IV was generated).

-- 
With best wishes
Dmitry