nisse@lysator.liu.se (Niels Möller) writes:
Simon Josefsson simon@josefsson.org writes:
+void +pbkdf2_hmac (unsigned Plen, const uint8_t * P,
unsigned Slen, const uint8_t * S,const struct nettle_hash *hash,unsigned int c, unsigned dkLen, uint8_t * DK);Maybe it would make more sense for pbkdf2 to use an arbitrary mac?
Yes, PBKDF2 is actually defined to apply to any PRF generally.
The caller would provide the mac an dinitialize it with the password. And then the pbkdf2 functions takes the mac, the salt, count, and generates the key. Like
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);
This feels a bit inconsistent with the hmac interface, but it is slightly more general. In practice, I'm not aware of anyone using PBKDF2 with anything non-HMAC though.
Example usage:
hmac_sha1_ctx ctx; uint8_t key[57];
hmac_sha1_set_key (&ctx, 8, "password"); pbkdf2 (&ctx, SHA1_DIGEST_SIZE, hmac_sha1_update, hmac_sha1_digest, sizeof(key), key, 4711, 6, "pepper");
Would that make sense? I guess one may also want some convenience macros/functions for using hmac-sha1 etc.
I suppose this would work. PBKDF2 invokes the PRF many times with different inputs (however always with the same key). It seems hmac_sha1_digest reset the context for new use.
Do you want me to submit an updated patch?
/Simon