5

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.

UPDATE 2:

RFC 6637 is now fully supported. Check the repository.

Improve this question
2
  • Do you have a link to the source code? Commented May 12, 2013 at 14:57
  • it is not yet finished. i will push everything to this git repository: github.com/esskar/BouncyCastle.Crypto Commented May 12, 2013 at 16:15

1 Answer 1

Reset to default
4

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
1
  • yes, that explains it well. i should have looked up the word "ephemeral" in the dictionary! :-) Commented May 12, 2013 at 12:37

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.