human readable key algorithm

[Werner Koch]

On Thu, 16 Jan 2014 14:30, gniibe at fsij.org 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"

Sure.

> 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.


Shalom-Salam,

   Werner

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