You thought you were safe after that last post, didn’t you? Well it turns out that I didn’t quite have the details correct. You can read for yourself in the governing IETF document RFC 4880: The OpenPGP Message Format. [1]
It seems that the whole public-private key thing is only PART of the magic which makes encrypted email possible. The details came out when I looked into how messages intended for multiple recipients are encrypted. It turns out it’s pretty simple, and fairly elegant (as you might expect from the kind of gurus that hang out in the IETF) and can be simplified as being what I described before pretty accurately.
So here’s how it really works:
I could paraphrase this, but to be honest, I think the description in the intro to the RFC is pretty straightforward with a bit of clarification. Here goes:
OpenPGP combines symmetric-key encryption and public-key encryption to provide confidentiality. When made confidential, first the object is encrypted using a symmetric encryption algorithm. Each symmetric key is used only once, for a single object. A new “session key” is generated as a random number for each object (sometimes referred to as a session). Since it is used only once, the session key is bound to the message and transmitted with it. To protect the key, it is encrypted with the receiver’s public key. The sequence is as follows:
1. The sender creates a message.
2. The sending OpenPGP generates a random number to be used as a session key for this message only.
3. The session key is encrypted using each recipient’s public key. These “encrypted session keys” start the message.
4. The sending OpenPGP encrypts the message using the session key, which forms the remainder of the message. Note that the message is also usually compressed.
5. The receiving OpenPGP decrypts the session key using the recipient’s private key.
6. The receiving OpenPGP decrypts the message using the session key. If the message was compressed, it will be decompressed.
I italicized the two important bits that I left out of the previous description. This is the magic, really. It’s not the message itself that is encrypted with the recipient’s PUBLIC key, but the SESSION key (a symmetrical key used to encrypt and unencrypt the body of the message) is encrypted. This way, everybody gets a copy of the same encrypted message, which can be decoded with the same SESSION key. As discussed in the previous post, only the recipient’s PRIVATE key can decode their copy of the SESSION key. So there IS some overhead since a copy of the key is included in the message for each recipient, but it’s not as bad as including multiple copies of the message. Of course, if the message is REALLY short and there are a LOT of recipients, this might get overhead intensive… but short messages aren’t really a problem from a bandwidth point of view.
- It’s ok, I read it so you don’t have to! [↩]
