human readable key algorithm

Werner Koch wk at
Fri Jan 17 14:04:48 CET 2014

On Fri, 17 Jan 2014 11:44, smari at said:

> I like how the subject of this mail is "human readable" but none of
> the suggestions are. "1E" is meaningless to everybody and "ed25519" is

gpg has two interfaces: The human readable and the machine readable
(--with-colons).  Agreed, the humans are expected to be PGP/GPG addicts.

> While it would lengthen the descriptor, it might be useful to add a
> standard prefix that suggests a) that it's an algorithm, b) what
> family it belongs to, and c) its distinguishing characteristics.

Does not fit nicely into one line or a printout for a signing party

>    alg-ec-nistp256/12345678
>    alg-ec-secp256k1/975B9053
>    alg-ec-ed25519/87654321

We know that this is about the public key algorithms.  Historically
(PGP-2) is has been used to indicate the strength of the key.  However
at least with EC there is no easy way to compare the key lengths.  We
could keep this key strength idiom by using scaled strengths (like Intel
CPU naming) but I am not keen to start discussing such a mapping table.

>    alg-f-rsa4096/deadbeef
>    alg-f-dsa2086/beefcafe

Well, I would risk switching from "2048R/xxxxxxxx" to something
"rsa2048/xxxxxx" with GnuPG 2.1. It might break things but after all
machine interfaces are not supposed to use this information.

The algorithm family does not make much sense to me.  There are other
parameters required for the use of the public key algorithm, which we
don't want to put into the key overview.

> Key naming convention design criteria: the terms must be easily found
> using a web search engine. I'm sure it's obvious why "11E" is not.

Makes sense.  Changing to


would be consistent and even allow scripts (and gpgme) to test whether
this is a new style listing or an old style.  Shall I change the code
for this, so we can do some tests?



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gnupg-devel mailing list