Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)
s7r at sky-ip.org
Tue Aug 29 09:09:50 CEST 2017
Robert J. Hansen wrote:
>> The thing is, if I create an ECC (ECDSA) secp256k1 primary key with
>> Sign, Certify capabilities I can also create a subkey with E
>> capability which is also a secp256k1 key. So, they can be used for
>> encryption after all, so why can't I just add E capability to the
>> primary one.
> You're confusing the field of numbers in which an algorithm operates
> with the algorithm itself. It's like confusing a sports car with a tour
> bus, thinking that since they run on the same roads they're interchangeable.
> secp256k1 is a certain field of numbers in which elliptical curve
> operations may be defined. It is not an algorithm. You do not have a
> secp256k1 key. You have an ECDSA key which operates in the curve
> defined by secp256k1.
> When you "create a subkey with E capability", you're creating an ECDH
> subkey operating in secp256k1. It's a completely different algorithm
> that happens to operate in the same numerical space. Different cars,
> different capabilities, same roads; different keys, different
> capabilities, same curve.
> ECDSA/EdDSA cannot encrypt. ECDH cannot sign or certify.
> Your primary key must be able to make certifications. So that means if
> you want to use ECC, your primary key must be ECDSA/EdDSA, and you will
> never be able to make it into an encryption-capable primary key.
Thanks for this. Ok, now it's clear why the primary key cannot Encrypt.
Here is a key I have just generated:
created: 2017-08-29 expires: never usage: SC
trust: ultimate validity: ultimate
created: 2017-08-29 expires: never usage: E
[ultimate] (1). Delete Me <delete at me.me>
I understand that the first one is ECDSA and the second is ECDH, but
can't I use the same secp256k1 key (if I import it) but in different two
representations (ECDSA representation for Sign and Certify and ECDH for
Encrypt)? The subkey might have a different fingerprint because it's a
different representation of course but this is not the concern, the
concern is for both to be computed from the same imported private key.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-users