Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

s7r 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:

sec  secp256k1/BF131CA5E1642BE9
     created: 2017-08-29  expires: never       usage: SC
     trust: ultimate      validity: ultimate
ssb  secp256k1/26882EB702DD7D4B
     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.

Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170829/66491e2c/attachment.sig>


More information about the Gnupg-users mailing list