2
$\begingroup$

I'm using PBKDF2, and this is my current call.

key = pbkdf2-hmac-sha256(iterations = 100_000, secret = password ++ salt)

I recently learnt that the function I'm calling also takes an optional salt field, and passing the salt instead of appending it gives different answers. Is what I'm currently doing insecure? I don't think it is, but I want to be safe - it looks like PBKDF2 uses the secret many times, but the salt only once, and there might be a good reason for that.

$\endgroup$
4
$\begingroup$

What you have been doing is unconventional, but is cryptographically safe, and should be fine as long as the implementation of pbkdf2-hmac-sha256 is correct. Things to watch out:

  • is all the stuff (characters?) in password and salt safely kept by whatever ++ is?
  • is this secret then converted to octets without entropy loss on entry of pbkdf2-hmac-sha256 ? Changing anything non-ASCII to ? is a goof that has crept; combined with use of a foreign language, overly paranoid user, or an endianness problem, that could degenerate to the length of the secret being the only entropy left! Another issue that can creep is stopping at the first zero octet in secret.
  • Does the pbkdf2-hmac-sha256 implementation correctly handle the case when secret, converted to octets, exceeds 64 octets? The action pbkdf2-hmac-sha256 should perform in this case is to replace these octets with their 32-octet SHA-256 hash.

Given this, the worst I can think the unconventional use of pbkdf2-hmac-sha256could cause is that timing execution could leak the length of password in an easier manner, but that's a non-issue.

Before that comment, I knew no language where 100_000 is a valid constant. More importantly, a hundred thousands is an insufficient iteration count nowadays for PBKDF2-HMAC-SHA-256, a short memorable password, and protecting a key from exhaustive search. Modern password-based key derivation functions make use of memory, sometime multiple execution threads, to greatly increase their effectiveness at a given execution time or cost, e.g. scrypt, Argon2, Balloon.

Note: implementing the core of PBKDF2-HMAC-SHA-256 in something that ultimately is interpreted rather than somewhat compiled would be a huge (but not rare) design mistake, since it would force using a lower iteration count than would be otherwise possible.

$\endgroup$
  • 1
    $\begingroup$ "I can't remember using a language where 100_000" Java and Ruby allow this (there may be others) but neither appears to use ++ as concatenation. Haskell and erlang seem to alloy ++ but I've not seen that they allow underscores in numbers (but I don't know they don't!) $\endgroup$ – TripeHound Aug 8 '18 at 10:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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