I am trying to integrate RFC 6637 into Bouncy Castle C# which is more challenging as initially thought because both private key and public key have to be present to calculate the share secret: that those not fit into the API of bouncy castle.

Anyways, Section 10 of the RFC defines a public key is to be encoded into the Public-Key Encrypted Session Key Packet. Is this the public key of the sender or the receiver? Either way, why is the OID not part of it, because without the OID, the point is more or less useless.

UPDATE: I just used Symantec Pgp Command Line tool to dump the packets of ecc encrypted files. Now i understand a bit more: for every encryption, the sender generates a new ECDH key which matches the curve of the receiver and sends the new public key as part of the package.


RFC 6637 is now fully supported. Check the repository.


In the Diffie-Hellman algorithm, sender and receiver must play in the same group -- in the case of ECDH, the same curve. People with key pairs do not a priori share the same group parameters (although in the case of elliptic curves, there are very few "standard curves"). If both sender's and receiver's key pairs use the same curve, they may use that to compute a shared key, but, in general, this cannot be assumed.

Moreover, PGP follows the email context, which is one-way: a single message is sent from the sender to the receiver, and the receiver is not notified of the transaction until the email is actually emitted. The receiver is then completely static throughout the operation. Therefore, sender and receiver must use the group of the receiver's key pair.

It follows that the sender must (normally) create a new key pair, deemed "ephemeral" (that's the important word in section 10 of RFC 6637), just for that email-sending, in the same group as the receiver's key. The sender will not store that key (hence the naming). The message must include the public part of the sender's ephemeral key pair, i.e. a curve point; the curve OID needs not be specified because, by definition, the receiver's curve is used: the receiver already knows it.

Note: since the sender uses a brand new ephemeral key pair, not sender authentication is implied by ECDH. If the sender wishes to prove his identity to the receiver, he must also sign his email, with his own, non-ephemeral, signature key pair.

| improve this answer | |
  • yes, that explains it well. i should have looked up the word "ephemeral" in the dictionary! :-) – esskar May 12 '13 at 12:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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