Nikos Mavrogiannopoulos <[email protected]> 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
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
