Borden via Gnupg-users <[email protected]> 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 _______________________________________________ Gnupg-users mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gnupg-users
