Multiple issues in GPG documentation

[Collin Funk]

Borden via Gnupg-users <gnupg-users at gnupg.org> writes:

> For what it's worth, I select my encryption algorithms based on two criteria:
>
> 1. If I'm encrypting for someone else's service (typically, SSH), what cyphers do they support?
> 2. If I'm encrypting for myself, what's the most advanced and future-proofed cypher I can use that my hardware supports?

Number 1 is a bad idea. Some services still support legacy ciphers for
backwards comparability. A recent example is Microsoft's Active
Directory defaulting to RC-4 [1]. This cipher has been known to be
insecure for decades now [2].

Generally, NIST recommendations can be trusted. Minus a few exceptions
where researchers raised alarms [3].

> 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.

I think that is a bit technical for an FAQ. Quantum computing is still
an active field of research, and it will likely be quite some time
before current algorithms are broken.

The worry about quantum computers is because of their theoretical
ability to efficiently perform integer factorization and solve the
discrete logarithm problem [4].

Efficiently performing integer factorization would make RSA insecure.
Solving the discrete log problem would make Diffie-Hellman key exchanges
insecure.

I don't know much about quantum computing, so maybe someone else on the
list can cover anything I missed.

>> Right there you go, Camellia in three keylengths on Fedora Workstation 42. It is almost certainly supported by your GnuPG installation.
>>
> 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:
>
> ```
> (1) RSA and RSA
> (2) DSA and Elgamal
> (3) DSA (sign only)
> (4) RSA (sign only)
> (7) DSA (set your own capabilities)
> (8) RSA (set your own capabilities)
> (9) ECC (sign and encrypt) *default*
> (10) ECC (sign only)
> (11) ECC (set your own capabilities)
> (13) Existing key
> (14) Existing key from card
> ```
>
> ... none of which appear to lead me to a Camellia key. Having said
> that, being a symmetric cypher, maybe it's only supported for directly
> encrypting documents and not generating keys. I was trying to say that
> the attention it gets seems excessive to the ease of generating it. I
> would think that RSA, DSA & ECC cyphers would be far more relevant and
> should be the focus of that discussion. I used it as an example, and
> there are other cyphers that are completely unfamiliar to me.

Camellia is a symmetric cipher so you would not use it to create a key.

You can use it to encrypt a file like so:

   $ echo 'abc' > input
   $ gpg --symmetric --cipher-algo CAMELLIA256 input
   Enter passphrase:
   $ rm input
   $ gpg --decrypt input.gpg
   Enter passphrase:
   gpg: CAMELLIA256.CFB encrypted data
   gpg: encrypted with 1 passphrase
   abc

Collin

[1] https://arstechnica.com/security/2025/09/senator-blasts-microsoft-for-making-default-windows-vulnerable-to-kerberoasting/
[2] https://en.wikipedia.org/wiki/RC4#Security
[3] https://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology#Controversy_regarding_NIST_standard_SP_800-90
[4] https://en.wikipedia.org/wiki/Shor's_algorithm