human readable key algorithm

Smári McCarthy smari at immi.is
Fri Jan 17 11:44:26 CET 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/16/2014 10:47 AM, Werner Koch wrote:
> Which shows one of the little things I have not found a solution so
> far:
> 
> The "256E" is not very descriptive.  With RSA and DSA things were
> easy because there was no need for domain parameters or we use
> random ones. With EC things changes because we use fixed domain
> parameters (aka the curve name).  In the example 256 may stand for
> all kind of curves and some people will probably like to see
> whether that is a NIST curve or some other curve with a more
> trustworthy origin.  Well, for Curve25519 we the 255 bit would give
> a clue but having the curve name would probably be better.  The
> --with-colons output already has this information.
> 
> One idea how to change it would be to use descriptions like:
> 
> nistp256/12345678 secp256k1/975B9053 ed25519/87654321
> 
> Given that a curve name never starts with a digit, this can easily
> be distinguished from RSA/Elgamal/DSA key sizes.  There are two
> drawbacks: The fixed column format of the key listing can't be
> kept.  For sure there are scripts which will break if they see such
> key specifications.
> 
> Another idea would be to use a GnuPG specific mapping of curve
> names to to simple identifiers:
> 
> 1E/12345678 2E/975B9053 11E/87654321
> 
> 
> Opinions?

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
only meaningful to those who have a fair bit of knowledge about things
such as Curve 25519.

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.

So:

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

Others might be:

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

And of course you could expand this scheme to include other families:

   alg-dl-aes256
   alg-dl-cast
   alg-sp-keccak

.. whatever. (The "families" I used in this mockup were "elliptic
curve", "factorization", "discrete logarithm" and "sponge" -- somebody
might think it'd be better to use a different family definition
scheme, and I would not necessarily disagree.)

I'm aware that this is a substantial modification from the current
approach, and in theory people should already know that an algorithm
is an algorithm and such, but really, people don't, and the current
naming scheme is not useful beyond a narrow set of cases.

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.

  - Smári



> Shalom-Salam,
> 
> Werner
> 


- -- 
Smári McCarthy   -   smari at immi.is   -  http://immi.is/
Iceland: +354 662 2701           UK:    +44 7462 795953
PGP:  B221 6FD2 779A E5B5 9D79 743C D5DC 2A79 C2E4 AE92
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIbBAEBAgAGBQJS2QmKAAoJENXcKnnC5K6Sgq4P+P4KWiEgOZeHUIPDjcbM6+5V
/+MtpQWUAlCV/c7rxzyLc84xDx1GzV14f+ptD9AxrO6ipTnKOFbtmpnDC5xAvBgP
Ptc2LRrWPNuy+vNgHnbqo/gKspDqp3CCxDk6FWk4Ef0hHTFDf7O23lXKUlLmDsYX
Ur5Oklr/gPQGhKxpjmMSvlgQA66JFJDe6sjfYKHBTPbvJqRHqrf+0qGyIP6icERB
ELb8Vg0/rudAXfp6IVXJM8sYcihqAIFqbbNekj3C5N7Y4i6V4I2M3KyyxHpCk/kh
SmBDWmlAF4sPmJ84d8Wz5eje1wTZr1rFu81RbGVSwqGWD0CzGQaS4SezszyQ9s0r
wjdysg6FpHNzjmdCukOfJzJ2+4L+q3d5wBrlpjFUoPMMpsuWKOypwmLRAn3GUhi/
JTHX4RkOaCKmGY7OAQ96P8oqPkBgjyNkbnoo7QiX+tmlOkwVC3UlPw5KQx+NHZiK
teE0Qo54g+Id2PddEPRQ0p6yMLSRPTFzhWiCvONtdYouXnmW9tazf7Z7wtvbPrzx
FFBzc0ZC+/8TtGC3m//CSex6fTXa/7sDJKSwqC9fmyWD+ekbuataHdOgQu4CvZLK
UDpJNl/bpIOrbASFB0Jug53lyvUwyjjzct768sEJCS45vOm9nMIOW6d9TNTOAELx
5ZDO6GikIwtL7BNCORY=
=3Q4a
-----END PGP SIGNATURE-----



More information about the Gnupg-devel mailing list