[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