review default algorithms recommendations for GPG 2.1 about riseup_help

[dkg]

for default key -- we should not be recommending DSA at all, and i don't think it's a good idea for us to recommend "or more" than RSA 4096. We should be recommending something strong, but the tradeoffs for larger RSA keys (as a ratio of cost to your allies against cost to your adversaries) are not great.

The GnuPG 2.2.0 defaults are 2048-bit RSA ("112-bit symmetric equivalent" by the various numerology prognosticators like ECRYPT II). Arguably, that should be 3072-bit RSA instead ("128-bit symmetric equivalent", about the same as Curve25519). I don't think anyone will be able to convince the GnuPG upstream to move all the way to 4096-bit RSA by default.

for cert-digest-algo, the default for GnuPG is SHA-256 (again, roughly "128-bit symmetric equivalent" due to the "birthday paradox"). The main upstream argument against moving that to SHA-512 has been interoperability, but basically everyone who implements SHA-256 has also implemented SHA-512 by today, so i don't think it's a great argument. And, depending on the platform, SHA-512 can potentially outperform SHA-256. So we might be able to push for a change upstream there.

For default-preference-list, You can see the current defaults with:

export GNUPGHOME=$(mktemp -d)
gpg --batch --no-tty --quiet --pinentry-mode loopback --passphrase '' --quick-gen-key 'bananas'
gpg --export bananas | pgpdump | awk '/Sub: /{ k = 0 }; /^[[:space:]]*Hashed Sub: preferred/{ k = 1 }; { if (k) { print $0 }; };'

on GnuPG 2.2.0, that gives:

		Sym alg - AES with 256-bit key(sym 9)
		Sym alg - AES with 192-bit key(sym 8)
		Sym alg - AES with 128-bit key(sym 7)
		Sym alg - Triple-DES(sym 2)
	Hashed Sub: preferred hash algorithms(sub 21)(5 bytes)
		Hash alg - SHA256(hash 8)
		Hash alg - SHA384(hash 9)
		Hash alg - SHA512(hash 10)
		Hash alg - SHA224(hash 11)
		Hash alg - SHA1(hash 2)
	Hashed Sub: preferred compression algorithms(sub 22)(3 bytes)
		Comp alg - ZLIB <RFC1950>(comp 2)
		Comp alg - BZip2(comp 3)
		Comp alg - ZIP <RFC1951>(comp 1)

So the only question here is whether we should be preferring SHA512 and SHA384 over SHA256. Again, there isn't a ton to gain or lose here, so it seems like it should be pretty unobjectionable.

I'd be happy to try to make these changes in GnuPG in debian as a trial balloon, to see how that goes.

[elijh]

for default key -- we should not be recommending DSA at all

+1

i don't think it's a good idea for us to recommend "or more" than RSA 4096

+1 seriously, wtf!

Arguably, that should be 3072-bit RSA instead

This is what I think should also be our recommendation.

[dkg]

3072-bit RSA is broadly considered (e.g. ENISA, NIST, etc, see https://www.keylength.com for an overview of different claims from different practicioners of this sort of numerology) to have roughly "128-bit-equivalent" security. This means that we expect about the same order of magnitude of compute power to crack a good 128-bit symmetric cipher (e.g. AES-128) as to crack a 3072-bit RSA key. (this assumes all the math is being done correctly, RNGs perform as expected, the underlying primitives are as hard as we believe them to be, etc).

1024-bit RSA is roughly "80-bit equivalent", and 2048-bit RSA is considered to be roughly "112-bit-equivalent". RSA-4096 is notably more expensive to compute than RSA-3072, but isn't much more than 128-bit equivalent; it's reaching diminishing returns in the attack/defend tradeoff.

[kradan]

https://lists.gnupg.org/pipermail/gnupg-announce/2017q4/000419.html

Noteworthy changes in version 2.2.4

• gpg: Change default preferences to prefer SHA512.

[micah]

We have deprecated the gpg best practices document, instead suggesting people use the sane defaults and keep their software up-to-date, so I'm closing this issue.

[anarcat]

this is specifically about https://riseup.net/en/security/message-security/openpgp/best-practices#primary-keys-should-be-dsa-2-or-rsa-rsa-preferred-ideally-4096-bits-or-more and later. or, more specifically:

cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

[dkg]

See also:

gpgconf --list-options gpg | grep ^default_pubkey_algo:

[dkg]

I've just uploaded 2.2.0-3 to debian unstable, which should make all of these settings unnecessary.

[dkg]

See https://anonscm.debian.org/git/pkg-gnupg/gnupg2.git/tree/debian/patches/update-defaults for the changes made.

[anarcat]

I've just uploaded 2.2.0-3 to debian unstable, which should make all of these settings unnecessary.

Unfortunately, this will take some time before it hits anything significant for most users (e.g. Debian stable or Ubuntu), so I still think a review of the settings is important. Furthermore, the guide applies to more than just Debian derivatives, so we should make a note about when they are not relevant that is specific and clear enough...

[dkg]

On Fri 2017-09-08 06:01:02 -0700, anarcat wrote: Unfortunately, this will take some time before it hits anything significant for most users (e.g. Debian stable or Ubuntu), so I still think a review of the settings is important.

sure, my point is just that we should now have a reference point that follows the recommendations.

Furthermore, the guide applies to more than just Debian derivatives, so we should make a note about when they are not relevant that is specific and clear enough...

We could probably also talk to the GnuPG maintainers in other distros who are willing to experiment and see whether they'd consider adopting any of the patches in https://anonscm.debian.org/git/pkg-gnupg/gnupg2.git/tree/debian/patches/update-defaults Anyone have any suggestions for which distros or maintainers to reach out to?

…

--dkg

[anarcat]

i don't think it's a good idea for us to recommend "or more" than RSA 4096

+1 seriously, wtf!

Arguably, that should be 3072-bit RSA instead

This is what I think should also be our recommendation.

This seems self-evident in your comments, yet neither here nor in #462 or c93fe0 do we explicitly say why we recommend 3072.

Can you explain why 3072 is better than 4096? It would be great if those kind of decisions would be better supported by facts than OMGWTFBBQBANGBANGONEONE!? :)

[IvanFon]

That's a very good point, and honestly I think there's a lot of things in the entire help system that could be explained better.

2048 is the minimum to be considered secure for now (and probably another decade or two). 4096 is even more secure, which is good. But as you go up, you trade security for efficiency. While it'll be more secure, transfers and algorithms will take longer. 3072 is a good balance between secure and fast.

If I made any mistakes, feel free to correct me. If this explanation sounds good, I can create a pull request this weekend, unless someone else wants to contribute.

[anarcat]

thanks for the clarification.

[c7hm4r]

1024-bit RSA is roughly "80-bit equivalent", and 2048-bit RSA is considered to be roughly "112-bit-equivalent". RSA-4096 is notably more expensive to compute than RSA-3072, but isn't much more than 128-bit equivalent; it's reaching diminishing returns in the attack/defend tradeoff.

This justification is rather blurry to me. As breaking RSA encryption is supposed to have super-polynomial runtime and RSA key generation, encryption and decryption have polynomial runtime, the attack/defend tradeoff grows also super-polynomial (i.e. "diminishing returns" is confusing).

I think the choice of the RSA key size should simply be consistent with other key size choices of the whole usage scenario. A theoretical attacker would always focus on breaking the weakest door. So using RSA with much more than 3072 bit together with AES-256 would be a waste of computation resources as a theoretical attacker would always focus on breaking the AES encryption.

[xandro0777]

I think the choice of the RSA key size should simply be consistent with other key size choices of the whole usage scenario. A theoretical attacker would always focus on breaking the weakest door. So using RSA with much more than 3072 bit together with AES-256 would be a waste of computation resources as a theoretical attacker would always focus on breaking the AES encryption.

we need also to think about what happens in 10-20 years, time passes by surprisingly quickly. Is an algorithm exploiting quantum parallelism known for factorization? I believe yes. Is one known for AES? Don't know that one. Now you might say that everything is lost once quantum computers start targeting RSA but the 4096 bit key will still be more expensive to crack than a 3072 bit key and that will give people some time to switch to quantum proof methods.

For this reason even longer keys should be considered although some software stupidly doesn't allow creating them.

For the record, I have used 4096 bit keys since 2008 or so. I didn't care whether the tradeoff is worth it or bad - even with hardware that old those keys worked fast enough for me and wasted less resources than Firefox does any time it loads the simplest webpage.