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

[Dmitry Eremin-Solenikov]

On Mon, Aug 5, 2013 at 4:31 PM, Stephan Mueller <smueller at chronox.de> wrote:
> Am Montag, 5. August 2013, 16:28:09 schrieb Dmitry Eremin-Solenikov:
>
> Hi Dmitry,
>
>>Hi Stephan,
>>
>>On Fri, Aug 2, 2013 at 6:10 PM, Stephan Mueller <smueller at chronox.de>
> wrote:
>>> Am Freitag, 2. August 2013, 11:14:15 schrieb Dmitry Eremin-Solenikov:
>>>
>>> Hi Dmitry,
>>>
>>>>+void
>>>>+_gcry_cipher_gcm_setiv (gcry_cipher_hd_t c,
>>>>+                        const byte *iv, unsigned int ivlen)
>>>>+{
>>>>
>>> The IV handling in GCM is a special beast. SP800-38D section 8.2
>>> defines exactly two ways how IVs are to be constructed. The current
>>> implementation seems to leave that issue to the caller. However, a
>>> caller may not understand that there is a specific requirement on how
>>> to set up the IV.
>>
>>Thanks for the pointing to the issue. In my opinion, we should not
>>mandate any special form of IV in setiv interface. IV block could  be
>>already constructed by the caller according to the rules of SP800-38D.
>>I might be wrong, but judging from quick glance on OpenSSL, Nettle or
>>NSS, no library implements these IV requirements in basic interface.
>>If that would be required by FIPS certification, we can probably
>>extend API. However I don't think
>>that basic setiv should have any additional complexity.
>
> As I am working in that field of FIPS 140-2, I know that NIST has some
> change of heart in that area in recent times. If you leave it like this,
> a successful validation is in question in the future.

What would be your proposal?

>>
>>I will probably add a note that to be fully compatible with NIST
>>recommendations,
>>one have to generate IV according to the specification.
>>
>>What do you think?

-- 
With best wishes
Dmitry