Although your comprehensive discussions on cyphers is certainly interesting, if you want to streamline your workflow, perhaps consider linking to other discussions (like Wikipedia) for technical and historical information. Otherwise, recommending a couple really good cyphers may make the FAQ more digestible for newcomers.
The FAQ *does* recommend a couple of good ciphers. There is a recurring line in the FAQ, words to the effect of "unless you know what you're doing and why, just use the defaults." It's surprisingly awesome advice. If you just use the defaults you'll get an excellent selection of algorithms. You don't need to tweak anything. However, no matter how often I told people this, quite often they would come back with "no, really, which ones are the _best_?" And 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.
Just occurred to me: you may want to consider adding an FAQ about which cyphers are quantum vulnerable, since newcomers will probably want advice on that.
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. "Extraordinarily silly" might be the only polite answer there. Cryptographic engineering is not the same as cryptography. Cryptography is a purely mathematical field; if you can reduce a 128-bit cipher to a 2**64 work factor, well, that might be very significant. But cryptographic engineering asks questions like, "what are the time, energy, and space requirements for this attack?", and if an attack is totally unfeasible then it's not really an attack at all, is it? Years ago I talked down some user who found some obscure paper that promised to break some cipher or another in a small work factor... although it required about 10^33 joules of energy to pull off. Okay, great, as soon as we build a Dyson sphere around the sun I'll start worrying. But not until the 10^8 seconds necessary to collect all that energy have passed.
My comments were unclear. I agree that gpg (which I confirm on my Debian box) supports Camellia. My point was that it doesn't seem easy to access. Specifically, when I run `gpg --full-generate-key -- expert`, I get these options:
When generating a certificate, you're asked for which asymmetric
algorithms should be used for encryption and signing. Camellia is a
symmetric algorithm.
Add CAMELLIA256 to your list of personal-cipher-preferences and GnuPG
will start using Camellia when appropriate. For instance, 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),
which means I tend to think Camellia implementations will be maybe a
little better (again, *totally* subjective). So my own personal-cipher-
preference (in ~/.gnupg/gpg.conf) reads:
personal-cipher-preferences CAMELLIA256 AES256 TWOFISH CAMELLIA192 \
AES192 CAMELLIA128 AES BLOWFISH CAST5 \
3DES
(Note: that should all be placed on one single line. The backslash is
meant to indicate data is broken across multiple lines; it should not be
included in the final single line.)
This tells GnuPG, "when choosing which symmetric cipher to use, prefer
the 256-bit symmetric ciphers starting with Camellia256; only if no 256-
bit cipher is available should we choose a 192-bit cipher starting with
Camellia192; only if no 192-bit cipher is available should we fall back
to 128-bit ciphers starting with Camellia128; and only if everything
else fails should we fall back to 3DES."
Then again, I respect that you could have been bombarded with so many questions about Camellia and the other cyphers that you added it to your FAQ.
A lot of people see unusual names in the output of --version and ask,
"hey, what's Camellia?"
I have to be honest here: most of the people asking these questions are
not competent to evaluate which ciphers are better or worse, or how they
are better or worse, or the mathematical structures, or... etc. And
that's okay. But that's why the discussion of ciphers is kept at a very
high level, giving basic background information and nothing more.
This is also why the FAQ doesn't link to Wikipedia, which tends to be
very newbie-unfriendly. Looking at the Wikipedia page on Camellia, for
instance:
https://en.wikipedia.org/wiki/Camellia_(cipher)
That page has language like,
"Camellia is a Feistel cipher with either 18 rounds (when using 128-bit
keys) or 24 rounds (when using 192- or 256-bit keys). Every six rounds,
a logical transformation layer is applied: the so-called "FL-function"
or its inverse. Camellia uses four 8×8-bit S-boxes with input and output
affine transformations and logical operations. The cipher also uses
input and output key whitening. The diffusion layer uses a linear
transformation based on a matrix with a branch number of 5."
Which is all true, you know, but it's also not exactly accessible to
people who don't have a strong background in cryptography.
Wikipedia is a great resource, but for newbies it's sometimes a little
daunting.
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
