human readable key algorithm

Werner Koch wk at
Thu Jan 16 18:33:10 CET 2014

On Thu, 16 Jan 2014 14:30, gniibe at said:

> robustness, etc.), and I'm afraid of Python version dependency.  For
> real use, it would be better to extend gpgkey2ssh to support Bitcoin
> address, say, with --btc option.  I'll look into gpgkey2ssh.

Well, gpgkey2ssh is also just a debugging aid and not really robust.
For example it runs "gpg" and not the gpg version from the same package.
Frankly, I never used it and I would need to read the code to see for
what it is used.

> N.B.  I don't recommend using Bitcoin, per se.  It's a bit
> contradictory if GnuPG (GNU Privacy Guard) pushed something with no or
> less privacy.               ^^^^^^^^^^^^^

Creating signature neither provides privacy but is nevertheless useful
to enable encryption.

> when you have his OpenPGP key with a subkey of secp256k1 (even if he
> hasn't been Bitcoin user yet, just owning private key of secp256k1

Adding notation data to the key or a newly defined keyflag would be
useful to identify such a subkey.  The question is whether we can deploy
this before the BC bubble bursts.

> Besides, there is another place: --card-status.  We discussed last
> year and currently it's like "256E" (for ECDSA NIST P-256) or "256e"


> This is needed to fix, too.  We need to consider updating of ECC
> support for OpenPGP card specification as well, anyway.

I have not followed Achims draft development closely.  We should address
non-ECDSA schemes.  Maybe simply by providing a DO with a list of OIDs
for supported curves.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gnupg-devel mailing list