Key Derivation Functions
Non-Password-Based

「 Overview 」




Recommended 「 In Order 」

Salted BLAKE2b

Restricted to a 128-bit salt and 128-bit (16 chars) personalization
parameter for domain separation, which is annoying.

However, you can feed more context information into the message parameter.

Besides the weird personal size limit, this is easier to use than HKDF
because there’s only one function rather than three, which can be confusing.

Furthermore, please see the Hashing section for why
BLAKE2b should be preferred over other hash functions.

If there’s no KDF variant of BLAKE2b available in
your library, then you should probably use HKDF.
↳ Please see below

However, if you know what you’re doing,
you can construct a BLAKE2b KDF using:

BLAKE2b(
    Message : Salt | Info | Salt Length | Info Length
    Key : Input Keying Material
)

with the Salt Length and Info Length parameters being encoded
as specified in point 5 of the Message Authentication Codes notes.

Like HKDF, this custom approach allows for salt
and info parameters of practically any length.

HKDF ( SHA512 | SHA3-512 )

The most popular KDF with support for a larger salt and lots of context information.

However, people get confused about the difference between
the Expand and Extract functions, it doesn’t require a salt
despite it being recommended and beneficial for security
and it’s slower than salted BLAKE2b.

Please see the Hashing and Message Authentication Codes sections
for a comparison between SHA2 / SHA3 and HMAC-SHA2 / HMAC-SHA3.

BLAKE3

As mentioned before, BLAKE3 has a lower security
margin,but it also doesn’t have a salt parameter.

With that said, very good guidance is given on how to produce globally
unique and application specific context strings in the Blake 3 Github .

If you’d like a salt parameter, then you can construct a
custom KDF implementation as explained in point 1 above.




Avoid 「 Unordered | All Unsuitable 」

Regular Hash Functions

Salted & Unsalted

Whilst this can be fine for deriving an encryption key from a Diffie-Hellman
shared secret for example, it’s typically not recommended.

Just use an actual KDF when possible as there’s less that
can go wrong (there’s no risk of length extension attacks).

Password-based KDFs

Such as PBKDF2

If you’re not using a password, then you shouldn’t be using a password-based KDF.

Password-based KDFs are designed to be slow to prevent bruteforce attacks, whereas
non-password-based KDFs are fast because they’re designed for high-entropy keys.

Even with a small delay (1 iteration of PBKDF2), this is likely slower and makes
the code more confusing because an inappropriate function is being used.

〔 HChaCha20 〕 〔 HSalsa20 〕

These are not general-purpose cryptographic hash functions

If you want something based on ChaCha, then use BLAKE2b or BLAKE3.




Notes


「 1 」

These KDFs are not suitable for hashing passwords

They should be used for deriving multiple subkeys from
a high-entropy master key or converting a shared secret
into a cryptographically strong secret key.

「 2 」

Using the same parameters besides changing the output
length can result in related outputs (for HKDF and BLAKE3)

This is exactly why you shouldn’t reuse the same parameters for different keys.

「 3 」

Use different contexts for different keys

A good format is [ Application ] [ Date & Time] [ Purpose ]
because this means the context information is application-specific
and unique, which provides domain separation.

「 4 」

Salted BLAKE2b can use a counter salt

If you’re deriving multiple subkeys from a master key,
then you can use a counter salt starting at 0 (16 bytes of 0s)
that gets incremented for each subkey.

However, if you’re deriving a single key from a
shared secret, then you should use a random salt.

「 5 」

Use a random salt with HKDF when possible

The RFC explains that using a random salt adds to the security of the scheme.

The authors recommend a salt as long as the hash
output length, but a 128-bit or 256-bit salt is sufficient.

Using a secret salt (a bit like a Pepper ) further improves the security guarantees.



「 Overview 」