nisse@lysator.liu.se (Niels Möller) writes:
Simon Josefsson simon@josefsson.org writes:
This feels a bit inconsistent with the hmac interface,
Anything in particular which you think is inconsistent?
That the HMAC interface takes this parameter:
const struct nettle_hash *hash
but the new PBKDF2 interface would take these:
void *mac_ctx, unsigned digest_size, nettle_hash_update_func *update, nettle_hash_digest_func *digest
which feels low-level, especially considering that those parameters are captured through the nettle_hash abstraction together with hard-coding PBKDF2 for HMAC.
However, I suppose this complexity could be hidden with a utility function 'pbkdf2_hmac' that is similar to my original function signature. I believe HMAC-based PBKDF2's are important enough to warrant a utility function for easy use. Then the flexibility is there in Nettle if someone wants to use PBKDF2 for non-HMACs in the future.
Do you want me to submit an updated patch?
It would be great if you could try out the proposed interface. And if it works out well, submit a new patch.
See patch below (only pbkdf2.h, pbkdf2.c, and testsuite/pbkdf2-test.c update, the rest of the patch is not updated). It works, however I get warnings because there is a type conflict:
pbkdf2-test.c:27:3: warning: passing argument 3 of 'nettle_pbkdf2' from incompatible pointer type [enabled by default] ../pbkdf2.h:40:1: note: expected 'void (*)(void *, unsigned int, const uint8_t *)' but argument is of type 'void (*)(struct hmac_sha1_ctx *, unsigned int, const uint8_t *)'
The reason is that pbkdf2 has this signature:
void pbkdf2 (void *mac_ctx, unsigned digest_size, nettle_hash_update_func *update, nettle_hash_digest_func *digest, unsigned length, uint8_t *dst, unsigned iterations, unsigned salt_length, const uint8_t *salt)
and nettle_hash_update_func looks like this:
typedef void nettle_hash_update_func(void *ctx, unsigned length, const uint8_t *src);
which is not compatible with any instantiation like this one:
void sha1_update(struct sha1_ctx *ctx, unsigned length, const uint8_t *data);
Casting the parameter would solve this. Is there any other way to resolve the warning? Do you think casting is an acceptable solution here? The problem seems to be that the casting needs to happen in the application not in the library.
/Simon