Nikos Mavrogiannopoulos nmav@gnutls.org writes:
Thanks for the comments.
- gcm.h:
The GCM_SET_KEY macro uses key both as input and to access a ctx element, and thus requires the last parameter to be called "key" as well.
#define GCM_SET_KEY(ctx, set_key, encrypt, key) \ do { \ (set_key)(&(ctx)->cipher, (key)); \ if (0) (encrypt)(&(ctx)->cipher, 0, (void *)0, (void *)0); \ gcm_set_key(&(ctx)->key, &(ctx)->cipher, \ (nettle_cipher_func *) (encrypt)); \ } while (0)
Fixed, good catch. I renamed the macro argument to gcm_key.
- cbc.h:
cbc_encrypt and decrypt use const void* as first parameter. That is, it cannot be wrapped over a function that works for cbc_encrypt as well as gcm_aes_encrypt (the latter doesn't use const). Without casts that is.
Overall, what I didn't like it that the new cipher API required more code to wrap around it.
Can you give some example of what you're doing?
gcm_encrypt uses const void * and nettle_cipher_func, just like cbc_encrypt.
While the struct gcm_aes_ctx contains both the aes key (constant after key schedule) and per message state, and hence has to be non-const. And it's not much different to if you use
struct cbc_aes_ctx CBC_CTX(struct aes_ctx, AES_BLOCK_SIZE);
- macros.h:
The MD_INCR(ctx) macro is now only applicable for sha512.
For hashes where the count is stored in a scalar variable (typically an uint64_t), you should use "ctx->count++" instead of MD_INCR (ctx). I didn't see any need for a macro for that.
- nettle-types.h:
There is still nettle_crypt_func which is identical to nettle_cipher_func. Is that intentional? I was wondering what was its use.
The differ in const-ness... The idea is that nettle_cipher_func is for block ciphers where encrypt and decrypt doesn't change the cipher state. nettle_crypt_func is used for stateful operations, such as stream-ciphers and aead constructions.
- dsa_verify()
Note sure if this is a regression, but this function will now succeed verifying data signed with a DSA-2048 key and SHA1 as hash.
Right, one can use dsa (and ecdsa) with any hash function, with arbitrary digest size. I think that's according to spec (even if not all combinations are recommended or make sense).
- libhogweed soname:
libhogweed has the same soname with 2.7.1, so applications crash if they are linked against nettle 2.7.1 and 3.0 is installed (that is because hogweed links against libnettle.so.5).
He intention was that nettle-2.7.1 uses the sonames "libnettle.so.4" and "libhogweed.so.2", and that nettle-3.0 bumped both numbers, to libnettle.s0.5 and libhogweed.so.3. Was that somehow messed up in the release?
As far as I understand, the versions symbols thing should help. I guess sonames have to be bumped again when version symbols are introduced?
It may make sense for both libraries to share the same so version.
I think it is likely that there maybe incompatible changes affecting only nettle or only hogweed. So I think it's best to keep them independent.
Regards, /Niels