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

Stephan Mueller smueller at chronox.de
Mon Aug 5 14:31:29 CEST 2013


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


Ciao
Stephan
-- 
| Cui bono? |




More information about the Gcrypt-devel mailing list