I'm using PBKDF2 to generate an ED448 signing key, and I'm trying to figure out the optimal salt size for SHA-3. I recall reading a recommendation to use a salt size equal to the PRF's internal-state block size, for PBKDF2. My understanding is that Keccak/SHA-3 doesn't use blocks the way SHA/MD hashes do. So how do I pick or calculate the salt length based on the Keccak parameters? Should iterations be increased since Keccak is faster than SHA2?

Current code:

const uint32_t SaltLen = 64; // what to pick here?
const uint32_t PBKDFIterations = 10000;
uint8_t Salt[SaltLen];
uint8_t SigningKeyBytes[ED448_KEYLEN];
RAND_bytes(Salt, sizeof(Salt));
PKCS5_PBKDF2_HMAC(Password, PasswordLength, Salt, SaltLen, PBKDFIterations, EVP_sha3_512(), sizeof(SigningKeyBytes), SigningKeyBytes);

I've seen the existing question from 2015 regarding using SHA-3 in PBKDF2, however that question is nearly 7 years old and I expect the recommendations to have changed since then.


1 Answer 1


For the purpose of this post, let's define the block size of an iterated hash function as:

the amount of data which, when fed to the hash algorithm will cause the iterating function (compression function for MD, and permutation for Sponge) to be invoked.

With this in mind, the block size of SHA-3 and SHAKE-* would be their "rate" parameter.

Now back to salt. Usually 128-bit (16-byte) salts would be sufficient (to deter pre-computation attacks such as Rainbow table attack), 256-bit would be ample. Related post on StackOverflow


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.