GCM mode and GMAC
nmav at gnutls.org
Mon Feb 7 11:35:15 CET 2011
On 02/07/2011 10:26 AM, Niels Möller wrote:
>> Moreover by not allowing the setting the blocksize as option any
>> extension on that code to work with 64-bit ciphers, will require
>> an abi break, or a new gcm64 mode... (what if 256-bit ciphers are
>> added in the future?)
> I don't think it's useful to be that general here. Variants with
> different block sizes will likely need a different context struct
> I could rename gcm to gcm128 in the interface if that's clearer.
I like the plain gcm...
>> As I already mentioned I prefer having the cipher and f, to context
>> to avoid supplying on individual calls. There is no advantage (that
>> I can see) on having on each function parameters, and it just
>> delegates the storage of those two pointers, to caller's structures
>> instead. It's no big deal but it is inconvenience.
> I haven't yet made up my mind on this, but let me explain the reason
> for having these pointers as function arguments. The idea is that
> context structs in nettle should be non-magic with no pointers, so
> that it can be copied or relocated in memory at will. Say we
> implement gcm_aes as
It makes sense, and although I've never used context structs like that
I could understand if someone did. I like to see context structures as
things that will take away my burden of maintaining several pointers and
data that relate to the operation.
Moreover different AEAD modes might have different requirements, but
it might be nice to have a consistent low level interface on them (if
possible of course).
If an AEAD mode doesn't require the encryption function at
the _digest operation, it would mean it would have different function
parameters. For me it would be best if it was consistent, even if
it is low-level... but it's your call...
> When thinking about it, maybe the right thing is to redesign the
> general gcm-code to use a separate struct for the hash subkey,
> passed as argument to the functions needing it.
I would like less of the internals of gcm exposed to the user rather
than more. As a user of nettle I wouldn't even want to know that there
is a hash subkey on gcm.
More information about the nettle-bugs