10

gpg has some preset default settings, which I assume were selected as a compromise between speed and security. I understand that these are good enough for most people.

But, in a situation where speed / performance was not an issue, what defaults could be changed, to make gpg use stronger parameters, and use even stronger encryption ?

For example, I have read discussions about the s2k-count default value being not sufficient. I really don't care if my gpg operation takes 50 milliseconds or 200 milliseconds. I would rather err on the side of safety, even if it is overkill.

Specifically, I would like to use the strongest possible values for:

  1. password hashing iterations
  2. size of asymetric key
  3. algorithm for symetric key

What else could be changed from default values, to make gpg more secure ?

I am using gpg (GnuPG) 2.2.12 on Debian Buster.

Anders
  • 64,406
  • 24
  • 178
  • 215
400 the Cat
  • 213
  • 1
  • 5
  • 1
    I think this question is missing focus. gpg can be used for various things (encrypt mails, symmetric encryption of data ...) and it is not clear what your use case is where you need improvements. These requirements should also come from your threat model and not just because "it can take a bit longer". It does not make sense to focus on useless improvements of key size etc if the real threats are somewhere else - see also https://xkcd.com/538/ . – Steffen Ullrich Jan 04 '20 at 08:41
  • 1
    Related: https://security.stackexchange.com/a/90617/165253 – forest Jan 04 '20 at 10:48
  • Is there anything else you'd like me to add to my answer? – forest Jan 23 '21 at 23:06

1 Answers1

10

1) password hashing iterations

If you don't care about waiting a little longer, you can use the maximum count value, which is 65011712. This isn't strictly the number of iterations so much as the number of bytes to be hashed. S2K works by repeatedly feeding the password and salt to a hash function for a specific number of bytes. The more bytes, the longer it takes. This is what the s2k-count parameter specifies.

2) size of asymetric key

The maximum key size that most implementations of GnuPG are capable of generating is 4096 bits for RSA. This is a result of the memory limitations placed upon the software. In order to prevent secrets from being leaked into swap, it has to "lock" memory. The operating system provides a limit as to how much memory a single process is allowed to lock. GnuPG would need to lock more than it is allowed to generate a key larger than 4096 bits. Luckily, 4096 bits is plenty for an RSA key.

3) algorithm for symetric key

AES256 is already plenty. It's most certainly not going to be your weakest link.

There are other things you can do to further harden your GnuPG implementation, although the complete list is too vast and dependent on your situation to list here. A few improvements would be to add to your gpg.conf file a few settings like with-fingerprint to display fingerprints by default. This doesn't improve security unless you actually verify that the fingerprints match what you expect, of course.

You can also use a stronger digest for signing keys. Avoid using SHA-1. You can use SHA-256, or even SHA-512, although that's a little overkill. This can be set with cert-digest-algo SHA512.

forest
  • 64,616
  • 20
  • 206
  • 257
  • There's little reason to use AES256, as AES128 will remain unbreakable until at least 2030. For future proofing, a Master key should only be capable of S&C and be 4096bit RSA _(should only be allowed to sign subkeys)_, but it wouldn't make sense for a subkey to use 4096bit as that will also remain uncrackable until past 2030. Hashing would depend on whether an x64 CPU is being used, since x64 CPUs process SHA512 faster than SHA256 – JW0914 Jan 04 '20 at 10:22
  • 4
    @JW0914 AES256 can resist multitarget attacks better than AES128 (although it's not likely to be an issue the way the OpenPGP standard uses it). Additionally, the extra four rounds in the 256-bit version lend some extra security against cryptanalysis. You are right that AES128 is likely to remain unbreakable for a very long time (I think 2030 is a pessimistic estimate, even), but there's little reason _not_ to use it, given the small amounts of data being encrypted. As for the hash algorithm used, the performance of 64- vs 32-bit operations is negligible for the amount of data to be hashed. – forest Jan 04 '20 at 10:25
  • Great points =] – JW0914 Jan 04 '20 at 10:29
  • The size of the asymmetric key can be changed by using ED25519, this will reduce the performance and the size of the keys – camp0 Jan 13 '20 at 20:44