nisse@lysator.liu.se (Niels Möller) writes:
Simon Josefsson simon@josefsson.org writes:
Possibly the block_count stuff could be used, although I'm not sure how it works: if you have a large dkLen wouldn't more than the final octet be needed?
In general, one could have something larger. In lsh I use it only for encrypted private keys, and then I don't need anything larger than, say 256 bits key and 128 bits iv.
Ah. I have some uses that require long outputs, and a generic implementation should support that.
However, I'm not certain 1) it makes sense to implement several KDFs in nettle,
I imagine main use would be to decrypt alien password-encrypted data. E.g., gpg keyrings and private keys for any other tools (what is openssh using?) So any method which is used in more than one non-obscure application would make some sense to support.
Not all KDFs are password-based, though, but I think it is the password-based KDFs that are most useful to support in the near term. HKDF is a recent strong candidate though.
- whether an generic interface can be found.
I don't think we need to worry about a generic interface now. I was more thinking about proper naming for the non-generic interface. E.g, can we say "pkcs5" rather than "pbdwhatever", or are there other methods defined in pkcs#5 (or likely to be in the future)? Naming should be reasonable now, and still not break down if we add other methods later.
PKCS#5 specify an obsolete PBKDF1 as well, and several other algorithms, so PKCS#5 as a name is not that unique. Possibly pkcs5_pbkdf2_hmac would be more precise, although it is longer.
/Simon