2

From the manual: the s2k-count parameter specifies how many times the passphrase mangling for symmetric encryption is repeated. This value may range between 1024 and 65011712 inclusive.

Apparently in many linux distributions the default is 65536 (just checked in mine).

Apparently all these values (range and default) were defined several years ago, in a time where computers were much slower. I tried creating an encrypted file using the largest possible value (65011712), and decrypting takes a fraction of a second on my PC anyway. The default value (65536) just looks way too small to me.

So are these values still adequate today, and for how long will they continue to be meaningful before a modification of GPG is needed?

  • Related. And of course, it depends how good your password is. If your password has 128 bits of entropy, it doesn't really matter. – AndrolGenhald Sep 13 '18 at 19:15
  • @forest, it's ok, I accepted the answer. – reed Oct 4 '18 at 12:19
2

The default today is half the minimum recommendation from 20 years ago.*

The specific key strengthening algorithm used is Salted and Iterated S2K, which combines the input password and the salt and repeats it numerous times, hashing the concatenation. The actual count value you are using is the number of bytes to continue hashing, so the highest possible value hashes only around 65 MB of data. The default of 65536 is indeed fairly low. Each SHA-256 hash block is 64 bytes in size, and PBKDF2 uses the HMAC construction which calls SHA-256 twice for every iteration (processing 128 bytes), so the default strength is equivalent to only 512 invocations of the hash function! Obviously any KDF that uses that few hash iterations is not going to be particularly secure. The maximum value of 65011712 is equivalent to more than 500,000 hash iterations, which is better.

The problem is not only that the value is too low, but that it is not memory-hard. This means that it's very easy to massively parallelize cracking attempts without running into memory limitations. This is the same issue that PBKDF2 has. A proper alternative would be a memory-hard function like Argon2, but GnuPG does not support that. It is unfortunately limited to S2K. You must use a stronger password.

* I am comparing PBKDF2 and S2K. The minimum recommendation of PBKDF2 iterations was 1k in 2000. If each iteration is equivalent to two 64-byte SHA-256 hashes, then we can consider the S2K count divided by 128 to be approximately equal to a single iteration of PBKDF2. As such, 65536 / 128 = 512, about half the recommendation from 2000.

  • So basically the default value for the parameter can be considered insecure. And the maximum allowed value probably won't be enough in the near future (or maybe it isn't even enough now). GPG seems the de-facto standard for encryption in Linux and the FOSS world, and the only reliable option, so... I just wonder why the default was never changed (and I've seen this issue was mentioned in newsgroups many years ago), and I wonder if there are any plans to make GPG more "modern" (either allowing more s2k rounds or supporting a better KDF). – reed Oct 4 '18 at 12:27

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.