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

[Stephan Mueller]

Am Montag, 5. August 2013, 19:17:58 schrieb Dmitry Eremin-Solenikov:

Hi Dmitry,

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

It is always a hassle when mechanisms are defined in two different 
places :-(
>
>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.

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

As you only refer to 8.2.1, why not considering 8.2.2 as well?

Ciao
Stephan

-- 
| Cui bono? |