Salt in KDF

[shipitfaster]

I hope it's OK to ask questions here. Thanks again for your help in previous threads. I have gone through the flow you outline here for my purposes of creating messages for a specific wallet owner. I'm wondering if it makes sense to prepend the salt for the KDF (Blake2) to the message since it's not known by the receiving party prior. For personalization, I was thinking of keeping blank as I don't think there is much benefit.

Given the need to include the salt in the messages, I'm wondering if this is the correct flow for my use case which is to encrypt a message, write to a block, and then notify the wallet owner that there is a message for their consumption.

If you'd prefer to discuss elsewhere, please let me know! Appreciate the discussion.

[samuel-lucas6]

I've moved it to a discussion.

Because an ephemeral key pair is being used, you don't really need a salt here. A salt is primarily needed for either a) deriving multiple subkeys from the same master key (e.g. a counter salt), b) randomness extraction in HKDF when deriving keys from a shared secret, or c) because you want to ensure a unique output despite the same input (e.g. static long-term key pairs, so a random salt).

You can just specify an all-zero salt, but I would recommend specifying a personalisation (e.g. Encoding.UTF8.GetBytes("application name")) for domain separation to your application as it's good practice.

[shipitfaster]

Thanks, I'll likely remove the Blake invocations in lieu of ephemeral keys.

[samuel-lucas6]

Note that the shared secret(s) should still be processed by a KDF because they're not uniformly random, which is what you want for keys. X25519.DeriveSenderSharedKey() and X25519.DeriveRecipientSharedKey() somewhat solve this for you because they hash the shared secret with the public keys. However, passing that hashed output through the BLAKE2b KDF is more like how HKDF works.

[shipitfaster]

Given the requirement for salt + personalization in Blake2b, which, given the nature of my application, would need to be either knowable, static values or knowable, dynamic values, what value does a KDF add on top of the DeriveXXXSharedKey() methods?

[samuel-lucas6]

Good question. The main reason would be if you perform multiple key exchanges and want to merge the outputs or to derive multiple subkeys.

Otherwise, it could be avoided, although the security may be slightly worse compared to how HKDF works. This is because HKDF derives a key from a shared secret that's then used to generate another key/more keys, whereas DeriveXXXSharedKey() just uses a shared secret and the public keys to derive a key. Practically speaking, this doesn't matter. Theoretically speaking, it probably does, hence why HKDF was designed that way.