human readable key algorithm
wk at gnupg.org
Thu Jan 16 18:33:10 CET 2014
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"
> 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