1
$\begingroup$

These days I'm generating some PGP keypairs, and I'm struggling to understand the correct terminology behind ECC keys. Moslty in the differences between ed25519/cv25519/ECDSA/EdDSA/ECDH. I tried to check RFC 6637 and this RFC draft without being sure of what I understood.

Let's take a practical example, with RSA first. Let's generate a keypair:

$ gpg --expert --full-gen-key

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC and ECC
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (13) Existing key
  (14) Existing key from card
Your selection? 1
What keysize do you want? (3072) 4096
What keysize do you want for the subkey? (3072) 4096
...

$ gpg -K
-----------------------
sec   rsa4096 2023-03-07 [SC]
      25EBF40DBE88FB395372A1D63F834EC009DB09B3
uid           [ultimate] John Doe <[email protected]>
ssb   rsa4096 2023-03-07 [E]

Here I think it's correct to say I generated a key using the RSA 4096 algorithm, with a subkey dedicated to Encryption ([E]) which is also using the RSA 4096 algorithm (correct me if I'm wrong).


Now let's do the same with Elliptic Curve Cryptography:

$ gpg --expert --full-gen-key

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC and ECC
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (13) Existing key
  (14) Existing key from card
Your selection? 9
Please select which elliptic curve you want:
   (1) Curve 25519
   (3) NIST P-256
   (4) NIST P-384
   (5) NIST P-521
   (6) Brainpool P-256
   (7) Brainpool P-384
   (8) Brainpool P-512
   (9) secp256k1
Your selection? 1
...

$ gpg -K
-----------------------
pub   ed25519 2023-03-07 [SC]
      448940C5335D1D278788F4AF67336C97696A1BE0
uid                      John Doe <[email protected]>
sub   cv25519 2023-03-07 [E]

What do I have here ? If I refer to this RFC draft section: I understand that I have a key using the Ed25519 curve (so EdDSA algo ?), with a subkey dedicated to Encryption ([E]) which is using the curve Curve25519 (so ECDH algo ?).

My question is: If I want someone to generate a PGP keypair using the 2nd method (with (9) ECC and ECC as a key kind) that will be used for encryption only, what should I ask him ? "Give me your public key that must be an ECDH one ?"

$\endgroup$
2
  • $\begingroup$ Why do you want this? ECDH isn't secure against active attackers without sender authentication, which requires a signature. The same goes for RSA key exchange ("encryption") of course. That's why the built-in options are either signing or signing + key exchange. $\endgroup$ Mar 7, 2023 at 13:41
  • $\begingroup$ I don't have practical needs behind this. I just try to understand what kind of key/algorithm will result of this key generation, as gpg binary only mention "ECC" during key generation. For what I understand, EdDSA will be used for the Sign & Certify subkey, and ECDH for the Encryption subkey. I try to know if this statement is correct $\endgroup$
    – Pierre
    Mar 7, 2023 at 14:14

1 Answer 1

2
$\begingroup$

cv25519 is short for Curve25519, which is an indication of the type of key pair. Curve25519 key pairs are mostly the same as Ed25519 key pairs. However, Ed25519 is used for EdDSA (as you concluded correctly) and Curve25519 is used for X25519 key agreement, which is a specific form of ECDH key agreement. The encoding for Curve25519 keys is well defined, but OpenPGP does of course add a protocol specific wrapper. If you want to ask your friend, you can ask for an OpenPGP compatible cv25519 public key.


X25519 key agreement can be used to implement ECIES *, which is a hybrid scheme using a separate ephemeral key pair to perform the key agreement to derive a symmetric encryption key using a KDF (just a hash over the derived secret + some parameters in this case). The derived key is used as a KEK (key encryption key) to wrap other keys, which can then be used to actually encrypt the messages.

The ephemeral public key is attacked to those encrypted messages for the receiver with the private (sub) key to be able to derive the KEK, unwrap the keys and finally decrypt the messages.

The specification can be found in RFC 6637: Elliptic Curve Cryptography (ECC) in OpenPGP . It e.g. contains the following information:

The output of the method consists of two fields. The first field is the MPI containing the ephemeral key used to establish the shared secret. The second field is composed of the following two fields:

  • a one-octet encoding the size in octets of the result of the key wrapping method; the value 255 is reserved for future extensions

  • up to 254 octets representing the result of the key wrapping method, applied to the 8-byte padded session key, as described above

In the end, the scheme is just using the public key of the receiver to encrypt, and the private key to decrypt. The difference is simply that the sender includes the ephemeral public key with the message instead of the RSA wrapped secret.

Information about the implementation in GnuPG can be found here.


* Currently the Wikipedia article shows a very specific form of ECIES. The PGP form of ECIES differs as explained in this answer and the ECC in OpenPGP RFC.

$\endgroup$
1
  • $\begingroup$ If anybody can generalize the IES article on Wikipedia then please do so, I'm almost ashamed to link to it. $\endgroup$
    – Maarten Bodewes
    Mar 7, 2023 at 23:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.