4
$\begingroup$

when i was reading the latest source code of openssl, i found openssl enc has an 8-byte (64-bit) salt length; because the same (password, salt, iter) will generate the same (key, iv), birthday paradox tells that you may reuse a (key, iv) pair within about 2^32 encryptions;

openssl source:

//  apps/enc.c;
int enc_main(int argc, char **argv)
{
    ...
    unsigned char *buff = NULL, salt[PKCS5_SALT_LEN];
    ...
}

//  include/openssl/evp.h;
# define PKCS5_SALT_LEN                  8

personally i do not think 2^32 (around 4 billion) is a very large number; there are almost 8 billion people around the world now; in some use cases there are a lot of personal data records that need to be encrypted; the number is even larger when you include other animals such as cats and dogs;

pkcs #5 (in 2017) recommends at least 64-bit salt length; while nist (in 2010) says you shall use at least 128-bit salt length; there is also a github issue proposed in 2017;

my questions:

  1. is 64-bit salt length deemed secure right now? if so, why does nist said you shall use at least 128-bit salt length 7 years earlier?

  2. is openssl enc meant for production use or only a demo of the openssl library?

  3. if the salt length cannot be easily improved in openssl, what other libraries and shell tools are both secure and easy to use?

Improve this question
$\endgroup$
9
  • $\begingroup$ Note that the PKCS#5 recommendation really isn't from 2017 but from 2000 (when PKCS#5 2.0 was published) as upping the salt size probably wasn't seen as critical enough for this simple republication + change control transfer. $\endgroup$
    – SEJPM
    Commented Dec 6, 2019 at 12:50
  • $\begingroup$ @SEJPM i guess it's not a recent document but the revision is dated 2017; i was wondering they would update this if it is serious, but they did not... hence the question; $\endgroup$
    – Cyker
    Commented Dec 6, 2019 at 12:59
  • 1
    $\begingroup$ The birthday paradox doesn't worry me in this situation. Yes, if all the people on the planet used the same password it would be a concern. That's not going to happen. If someone uses the same password to encrypt files four billion times well they're just being stupid (and yes stupid people obviously do exist). What would worry me here is that a 64-bit number can be brute forced. Not easily, but it's possible. The sufficiency here depends on what you're protecting and who you think might try to break the encryption. I tell my teams to always use 128 bits of salt or more. $\endgroup$
    – Swashbuckler
    Commented Dec 6, 2019 at 16:04
  • 2
    $\begingroup$ @SEJPM+ plus what openssl enc uses below 1.1.1 (also openssl 'traditional' = nonPKCS8 privatekey files) is mostly PKCS5 v1 which was current in 1995 when EAY started and is now called PBKDF1 -- WITH ONLY ONE ITERATION which is a much worse problem than the salt size -- see crypto.stackexchange.com/questions/3298 and crypto.stackexchange.com/questions/36981 (mine) and security.stackexchange.com/questions/29106/… (ursine). $\endgroup$
    – dave_thompson_085
    Commented Dec 7, 2019 at 5:16
  • 1
    $\begingroup$ @Swashbuckler: salt is not secret, so bruteforcing it is irrelevant. $\endgroup$
    – dave_thompson_085
    Commented Dec 7, 2019 at 5:21

1 Answer 1

Reset to default
0
$\begingroup$

Some sites even suggest using a salt that is the length of the digest of the hash function, created by a CSPRNG, but 16 bytes is generally the minimum salt length used (128 bits).

Improve this answer
$\endgroup$

Your Answer

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

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