Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
    
Do you have a link to the source code? –  makerofthings7 May 12 '13 at 14:57
    
it is not yet finished. i will push everything to this git repository: github.com/esskar/BouncyCastle.Crypto –  esskar May 12 '13 at 16:15
add comment

1 Answer

up vote 3 down vote accepted

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.

share|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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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