Multiple issues in GPG documentation

Borden borden_c at tutanota.com
Sun Sep 14 01:25:04 CEST 2025



> The FAQ *does* recommend a couple of good ciphers. There is a recurriing line in the FAQ, words to the effect of "unless you know what you're doing and why, just use the defaults."
>
My point exactly. So why not streamline the documentation to explaining the defaults and offloading everything else to somewhere where keeners can go down the rabbit hole?

> I can't answer that -- "best" is inherently subjective -- but I can give brief breakdowns on the different ciphers. And I was asked to do this often
> enough that I just threw it in the FAQ.
>
Fair. Which is why I suggest consolidating it all into one question that goes to the effect of "The 'best' cyphers are the ones we set to the defaults."

I think the question people mean to ask - as it's one I often have - is "What's the difference between them?" or "What's the best for _my_ situation?"

If people are anything like me (and fortunately almost all of them aren't), I think they come from believing that if one algorithm were universally the best, everyone would use it. But since we have different algorithms, there surely must be some reason why people went through all that extra effort.

Again, advising to offload discussion onto other sources, I think the best response to that FAQ is to provide a layman's difference between them. Something to the effect of "Algo X is faster than Y, but Y produces more compact hashes than Z, but Z has higher resistance to side attacks than X, etc."

Wikipedia has comparison pages that, often in a tabular format, summarise the differences in whatever - like database engines or text editors. A table like that should shut most people up (if they bother to read it). If Wikipedia, or somewhere else, has a page comparing cyphers, so much the better. Link to it and save some typing.

> It's due for the rewrite, but that question is surprisingly hard. RSA is considered far more quantum-resistant than ECC, for instance, and most of the modern ciphers in the suite are inherently quantum-resistant but some are potentially not. And then you have to weigh against practical engineering realities: sure, a 128-bit cipher can _theoretically_ be brute-forced by a large quantum computer in 2**64 time using Grover's algorithm, but the energy requirements to create the ensemble are ... uh. Well.
>
Perfect answer. Plug it in the FAQ. Better still, make it a column in that comparison table I was talking about: "Theoretical resistance to quantum cracking" ... "Weaker"; "Stronger"; "Vulnerable" etc.

> When generating a certificate, you're asked for which asymmetric algorithms should be used for encryption and signing. Camellia is a symmetric algorithm.
>
Noted. Would also be a good column for that table: "One-way hash"; "Asymmetric"; "Symmetric"
> I quite like Camellia: it's construction is a lot like AES but I find it a little clearer and easier to implement (which is a *totally* subjective call),
>
I would offload that discussion to Wikipedia. If someone wants to go down that rabbit hole, godspeed to them.

For my purposes (and I'm not sure how well they reflect the public's), all that I need to know is "Can I use it where I want to use it?" and "For how long can I use it until I need to add another 512 bits to the length?"

Notwithstanding the discovery of a systemic security vulnerability, of course,

> personal-cipher-preferences CAMELLIA256 AES256 TWOFISH CAMELLIA192 \
>  AES192 CAMELLIA128 AES BLOWFISH CAST5 \
>  3DES
>
And, to me, that's largely a string of random characters. Again, would be great if the major differences were summarised in a comparison table or something.

> But that's why the discussion of ciphers is kept at a very high level, giving basic background information and nothing more.
>
Agreed. One more time for the back of the room: offload to another source for people who want to go down that rabbit hole. For laymen like me, reassure us that the defaults are "the best," (or, at least, grossly sufficient) and add a summary table so people can quickly learn the differences between the alternatives.

> This is also why the FAQ doesn't link to Wikipedia, which tends to be very newbie-unfriendly.
>
For my minimal competence, Wikipedia is fine. Yes, it gets into the mathematical weeds with alien notation as you quote, but their articles also begin with good summaries and histories that tell me what I need to know.

But if there's a better layman's source, use that. I'm suggesting that you don't make work for yourself by repeating what's already been done. GPG documentation should explain how to use GPG, not number theory or electronic engineering.


This is all fascinating, and I hope someone other than me found it useful, but we've gone a bit off topic. The documentation (particularly man pages) seems to have obvious errors and omissions. Any chance of fixing those?



More information about the Gnupg-users mailing list