> 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?
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
