search

wireapp / hkdf

HKDF implementation (RFC 5869)
GNU General Public License v3.0
30 stars 6 forks source link

Why is `mk_salt` implemented like this? #4

Open KizzyCode opened 6 years ago

KizzyCode commented 6 years ago

Why is mk_salt implemented like this?

I've read RFC 5869 and as far as I can tell, it is nowhere specified that you should pad or hash the salt. They just say that the salt is optional and if none is given, you should use "HashLen" zero bytes instead (Step 1: Extract).

So maybe it would be a good idea to document the rationale behind this decision.

brycx commented 6 years ago

Seems to me they have documented it(although I have to admit it could be rephrased a bit):

// The salt is used as key for HMAC-Hash. It is either padded to the right
// with extra zeroes to the input block size of the hash function, or the
// hash of the original key if it's longer than that block size.

sodiumoxide, which is a binding to libsodium, only accepts arrays of size 32 as Key input, with HMAC-SHA-256. That is why the salt is padded against a length of KEYBYTES. When the comment says

input block size of the hash function

it just means hmacsha256 from sodiumoxide.

KizzyCode commented 6 years ago

Ah, ok. This means the only reason is an API-limitation of the oneshot-functions and not an important (cryptographical) reason... I forgot about this because if you use the traditional init-update-final calls, you can use arbitrary key-lengths for HMACs with libsodium.

Thanks for pointing out 👍🏻