4

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?

Community
  • 1
Cyker
  • 729
  • 5
  • 17
  • 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. – SEJPM Dec 06 '19 at 12:50
  • @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; – Cyker Dec 06 '19 at 12:59
  • 1
    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.

     – Swashbuckler Dec 06 '19 at 16:04
  • 2
    @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 https://crypto.stackexchange.com/questions/3298/ and https://crypto.stackexchange.com/questions/36981/ (mine) and https://security.stackexchange.com/questions/29106/openssl-recover-key-and-iv-by-passphrase (ursine). – dave_thompson_085 Dec 07 '19 at 05:16
  • 1
    @Swashbuckler: salt is not secret, so bruteforcing it is irrelevant. – dave_thompson_085 Dec 07 '19 at 05:21
  • Cyker: the question of what tools or methods should be used for file encryption instead of openssl enc has been asked and discussed many times; I'll try to find my notes on this later. – dave_thompson_085 Dec 07 '19 at 05:29
  • I think that questions 2 and 3 depend on more than just the salt and are considered off topic on this site (opinionated and asking for software recs respectively). They are also quite separate from any answer on #1, so they may keep people from answering in case they don't know the answer to these separate questions. I would urge you to remove them from your post. – Maarten Bodewes Dec 07 '19 at 13:40
  • @MaartenBodewes Alright, did it. I think Q2 may be relevant, though. If it is mainly a cryptographic library that can also be used from the command line, we can't tell if its choice of parameters is wise. – Cyker Dec 07 '19 at 13:57
  • Neither the man page or the Wikipedia page says that it is used only as a demo, and as there has been a complete CA software kit based on openssl command line usage, I doubt if you cannot call that "production use". If it is smart to rely on command line utilities for that is another question of course. As for choice of parameters that should be on merit of how the parameters influence security, not on some kind of evaluation on the software component as a whole. It's meant for production use, so it is secure? Really? That's not the security market as I know it. – Maarten Bodewes Dec 07 '19 at 14:04

1 Answers1

0

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).

SamG101
  • 613
  • 4
  • 12