human readable key algorithm (was: gpgkey2bc: Generating address of Bitcoin from public key)

[Werner Koch]

On Thu, 16 Jan 2014 08:48, gniibe at fsij.org said:

> Attached 'gpgkey2bc.py'.

Cool.  Feel free to put it under tools/.

> sub   256E/975B9053  created: 2014-01-16  expires: never       usage: SA  

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?


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.