1

A program is using a private key to read messages. To improve security, besides randomness, I'm trying to create the longest passphrase that makes sense.

How long should it be? After which amount of (random ascii) characters does it stop making sense adding more to the passphrase?

Andras Gyomrey
  • 821
  • 3
  • 9
  • 17

1 Answers1

3

PKCS#8 is a flexible standard; it is a syntax for encoding private keys with optional password-based encryption. The security level that can be achieved depends on the algorithm used to convert the password into a key, and the cryptographic algorithm that works with this key. PKCS#5 defines a number of combinations of password-based key derivation and encryption algorithm.

For instance, suppose that you use PBKDF2 with HMAC/SHA-1 for key derivation, and 3DES for encryption. 3DES accepts a 192-bit key; however, only 168 of these bits are really used. SHA-1 output has size 160-bit, and this imposes a hard limit of 160 bits to the security of PBKDF2 with HMAC/SHA-1. Therefore, with that combination, it makes little sense to use a password with more than 160 bits of entropy.

Entropy is not automatically derived from password length, but if you use random characters (uniformly random characters, chosen independently of each other -- i.e. not at all the kind of password that a human user could come up with) then the relationship between length and entropy is easy. There are 95 printable ASCII characters (not including space) so each random character brings about 6.57 bits of entropy (because 26.57 is approximately equal to 95). Therefore, 160 bits of entropy are achieved with 25 characters. With these algorithms, it would make no sense whatsoever to use more than 25 characters, as long as these characters really are chosen randomly, uniformly and independently of each other.

In fact, password-based key derivation functions like PBKDF2 include thousands of iterations so that any attempt at exhaustive search would be slowed down; this is equivalent to some extra bits of entropy (in that context). If there are, say, 1000000 iterations, then these count as 20 bits (because 220 is approximately equal to 1000000, and each PBKDF2 iteration roughly implies the same amount of work as an elementary 3DES encryption block). From the figure above, account for these 20 bits by removing 3 characters, down to 22. Of course this depends on the iteration count that you are really using.

Arguably, going beyond 128 bits of entropy is already a big waste of time.

To get more information on these subjects, read the following answers:

Community
  • 1
Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • As I understand, PKCS#8 (currently) has a hard limit of 2048 iterations. Which adds 11 bits of entropy. The concept of bits of entropy is just what I needed. Why do you say that going beyond 128 bits of entropy is a big waste of time? You mean because it's not calculable in a reasonable amount of time? – Andras Gyomrey Oct 20 '14 at 00:50
  • Didn't read the last link. Got the 128 bits of entropy. Really nice answer. – Andras Gyomrey Oct 20 '14 at 00:54
  • 1
    There is no hard limit in PKCS#8 about the number of iterations. However, some _implementations_ may have arbitrary limitations, e.g. not having a command-line switch to configure the number of iterations. The real limit on the number of iterations is that iterations make the password-to-key transform expensive for everybody, attacker and defender alike; so you don't want to go to the billions range. – Tom Leek Oct 20 '14 at 11:25
  • Yep, you're right. I was talking about `openssl`. Thanks again. – Andras Gyomrey Oct 20 '14 at 12:07