[RFC PATCH 2/3] Add API for initializing AEAD modes

[Werner Koch]

On Mon, 14 Oct 2013 13:20, jussi.kivilinna at iki.fi said:

> I based CCM patchset on the AEAD API patch Dmitry sent earlier for
> GCM. Since CCM has more restrictions (need to know data lengths in
> advance) than GCM, I added gcry_cipher_aead_init.

I forgot about this because I delayed that far too long.  Sorry.

> With this patchset to encrypt a buffer using CCM, you'd first need to
> initialize/reset CCM state with:
>
> gcry_cipher_aead_init (hd, nonce_buf, nonce_len, authtag_len, plaintext_len)
>
> CCM needs tag and plaintext lengths for MAC initialization. CCM also

Up until now we use separate functions to set key, IV, and counter.
This function changes this pattern.  Why not reusing setiv for the
nonce and adding a function for the authentication tag?

Is the plaintext length really required in advance?  That is
embarrassing in particular because the authenticated data is appended to
the ciphertext.

> gcry_cipher_authenticate (hd, aadbuf, aadbuflen)
>
> which does the actual MAC initialization. If aadbuflen == 0, then
> above call can be omitted and gcry_cipher_(en|de)crypt will call
> gcry_cipher_authenticate with zero length.

What about extending this fucntion to also take the authentication tag
and, if the plaintext length is required for the MAC setup, also that
length?  That would group the information together.

> NIST paper and RFC 3610 define CCM ciphertext as [ctr-enc(plaintext)
> || authtag] and that decryption must not reveal any information
> (plaintext or authtag) if authtag is not correct. Therefore full
> buffers, matching with length of plaintext_len and authtag_len given
> in gcry_cipher_aead_init, have to be used. If authentication check

I don't see that.  That is an implementaion detail and the requirement
could also be achieved by putting it into the security policy.

> Would it be better to add functions to do AEAD encrypt/decrypt in
> single go and use gcry_buffer_t? This would avoid having internal
> state machines in AEAD modes and having to call different functions in
> correct order.

And it also means that you can't use that mode with large amounts of
data.  Not a good idea; there are still lots of platforms with a quite
limited amount of memory but in need to encrypt large data take from
somewhere.  Yes, the need for the plaintext length makes it hard to use
but I can image systems which know that length on advance even if the
data does not fit into memory.

I mentioned gcry_buffer_t having the AAD in mind; a scatter/gather style
operation may be useful here.

We should also keep in mind that adding support for OCB is desirable.  I
had in mind to require the use of a new GCRYCTL_ENABLE_GPL_CODE to state
that Libgcrypt is used under the terms of the GPL.  However, meanwhile
Phil Rogaway relaxed the requirement for royalty free patent licensing
to all free software licenses and thus we could simply got forth and
implement OCB.  Any new API should make it easy to do just that.



Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.