Bug #9511

gpg.conf could have better defaults for private key encryption

Added by emmapeel 2015-06-02 08:36:04 . Updated 2016-07-16 05:54:51 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2015-06-02
Due date:
% Done:

100%

Feature Branch:
Type of work:
Communicate
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

reported by user (kinda cryptic for me):

User claims that our gpg.conf file could have a better algo for encryption of private keys.
As there are no settings about sk2, then GnuPG will use its default settings, that are:

s2k-cipher-algo CAST5
s2k-digest-algo SHA1
s2k-mode 3
s2k-count 65536

And user claims they better be:

s2k-cipher-algo AES256
s2k-digest-algo SHA512
s2k-mode 3
s2k-count 65011712

As per https://www.gnupg.org/documentation/manuals/gnupg/OpenPGP-Options.html

In this way, the private key material will be encrypted with algo AES256, hash SHA512, and iterating the hash 65011712 times.

Here the references for the algo numbers:

https://www.ietf.org/rfc/rfc2440.txt

I checked with a friend and:

- maybe the overhead of s2k-count 65011712 will eat a lot of CPU
- Also ‘s2k-mode 3’ may be superfluous as it is covered by the defaults

But maybe ‘s2k-cipher-algo AES256’ and ‘s2k-digest-algo SHA512’ are good to have.

Is this something we should report upstream? I could submit a patch for duraconf git, but maybe I should ask GnuPG people to change the defaults?

Subtasks

Related issues

Related to Tails - Bug #12178: GPG uses SHA1 for symmetric encryption Rejected 2017-01-25

History

#1 Updated by emmapeel 2015-06-02 14:13:43

Duplicates Debian bug https://bugs.debian.org/787385

#2 Updated by dkg 2015-06-02 22:14:12

If you’re referencing algorithm numbers, you’re better off with digest algorithms and s2k modes than the text version of RFC 2440.

the trouble with setting s2k-cipher-algo is that it doesn’t strictly cover secret key encryption. The advantage of the secret key encryption config is that you there is no interoperability concern. But s2k-mode is also a relevant default when you use gpg --symmetric, in which case the SKESK packet will also use it, which means that

I agree that s2k-cipher-mode should probably move from CAST5 to AES256. I’m making that argument upstream

I’m not convinced that the s2k-digest-algo makes any significant difference. This is not a situation where the message digest relies on either its collision resistance or even pre-image resistance. However, changing it away from SHA1 would at least stop people from saying “oh no, SHA1 is broken, it’s bad that it’s used here!”

SHA1 is used as an entropy-stretching mechanism here, and as a computational obstacle — you have to do X reps of the hash from the password to get to the actual key. In practice, SHA512 may actually be faster to compute on some architectures than SHA1, so the move might actually reduce the computational hurdles for a brute-force attacker, depending on their hardware.

As of version 2.0, GnuPG’s default s2k-count setting is tuned to match the hardware it is run on, with a default value being drawn from gpg-agent figuring out how many hashes can be done on the current machine in about 100 milliseconds.

Version 1.4 appears to default to 65536. setting s2k-count to the maximum possible value (65011712) is probably functional on fast modern machinery, but may mean several seconds per secret key operation on weaker hardware (older computers, or low-power hardware like raspberry pi or cheap laptops). So i think the measured approach handled by gpg-agent (in 2.0 and 2.1) is the right one, though maybe you think it ought to be 500ms instead of 100ms?

I’m inclined to suggest that the default value for 1.4 should be raised, but i also don’t want to spend a ton of time tweaking out 1.4 — we should be helping people move off of 1.4 to one of the 2.x branches, not fiddling with it a lot.

#3 Updated by intrigeri 2015-06-03 08:24:38

  • Status changed from New to In Progress
  • Assignee set to dkg
  • % Done changed from 0 to 10
  • Type of work changed from Discuss to Communicate

Thanks emmapeel for raising this topic, and dkg for following-up on it! IMO we should not diverge from the OpenPGP best practices document on that one, so next steps are:

  1. try to have the improvements we want implemented upstream;
  2. if it fails, check if Debian maintainers want to carry it as part of the Debian delta (I doubt it);
  3. if not, have it implemented in the OpenPGP best practices document.

dkg, once the discussion upstream about s2k-cipher-algo (that’s really it, not s2k-cipher-mode, right?) has reached a conclusion, may you please report about it here?

#4 Updated by BitingBird 2016-06-29 06:24:52

There seems to have been no answer since a year…

#5 Updated by intrigeri 2016-07-16 05:54:51

  • Status changed from In Progress to Resolved
  • Assignee deleted (dkg)
  • % Done changed from 10 to 100
  • QA Check deleted (Info Needed)

Actually, since GnuPG 1.3.2 s2k-cipher-algo defaults to personal-cipher-preferences when set, so in Tails that would be “AES256 AES192 AES CAST5”, so I think we’re good here.

#6 Updated by intrigeri 2017-03-03 10:18:44

  • related to Bug #12178: GPG uses SHA1 for symmetric encryption added