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 anyway.
Indeed...
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.
regards, Nikos