How to use PGP ephemeral keys & malleable encryption

Post date: Oct 14, 2013 2:59:41 PM

Disclaimer: This is purely based on what I have been reading and thinking. I'm not a cryptography specialist. Any feedback is very welcome.

I did read the post "Off-the-Record Communication, Why Not To Use PGP" and found it to be possibly incorrect. Because you can get exactly the same results using PGP (Pretty Good Privacy) or GPG (GNU Privacy Guard) or any basically any other public key solution capable to generating new keys and signing messages.

Ephemeral key

Ephemeral key or PFS (Perfect Forward Secrecy) is technology which allows each session or context to be communicated using individual encryption keys. Therefore requiring cracking each of those separately. This is perfectly achievable using PGP. Comparable to OTR Messaging (Off-the-Record Messaging).

How?

1. Create new key pair

2. Sign the new key with your own key

3. Export the key

4. Encrypt it with the recipients primary public key

5. Send it to the recipient

6. Use the new key for rest of this session / context when sending data

7. Now for bidirectional communication you should also receive your contacts new ephemeral public key, signed with your contacts primary private key which is encrypted with your primary public key.

8. After the session / context both parties simply delete the ephemeral keys (private & public)

Now we have achieved ephemeral encryption with PGP. But they claim that PFS isn't enough. You should also use ...

Deniable & Malleable Encryption

Now if you also want achieve deniability, you can follow this procedure.

1. Export the private ephemeral session key

2. Encrypt it with the recipients session key

3. Send it

Now because the recipient has also the private key of your session key, they can make up and sign what ever content they want to with it. Therefore messages signed with that private session key can't be proven to be written & signed only by you.

There's also alternate way of getting same results without using ephemeral session keys. It's using primary public keys for encryption and shared session secret.

1. Send message with random nonce to recipient, sign it and encrypt for recipient

2. Recipient adds random nonce to that message and signs it, sends it back encrypted.

3. You'll sign that and send it back, as encrypted message. At this stage both parties have random session key, which they know is signed, and due to encryption they're basically the only other party having the key.

4. Now you stop signing messages. And only use encryption, and messages you're swapping now contain only the shared session secret.

This means that messages do not contain signature, which could be used to prove that you sent the messages. But during the 'session', both parties know that the shared key is only known by them. If there's any doubt about the identity of the other end, the signed negotiation can be repeated as often as required.

Options

If you still don't want to sign the messages or send the ephemeral private key, you can simply generate a nonce. Just generate a small nonce and send it in signed (you ephemeral key) message, encrypted using recipients (ephemeral key). Place this nonce in each message. Which are then encrypted (using recipients ephemeral key) without any (your) signature. The presence of the nonce in the message will tells the recipient that it's still you there and not an impostor. Now messages aren't signed at all, but it's still very highly likely that nobody else is able to impose to be you. Because each message has to have the nonce and the transmission of the public key being used was already encrypted (and protected) using the recipients primary key. If the nonce is just long enough like 128 or 256 bits, it should be very secure alternative.

You can also refresh this ephemeral key as often as you want to. Every message, every day, every context what ever. Of course you'll be using different ephemeral keys for every contact.

It's also interesting question, do you need to tell the pass phrase of the exported private key which is protecting the ephemeral private key to the recipient. Who and how can the prove, if they do or don't know it? Anyone can say yeah, Ii got the encrypted data, and I got the private key, but I don't know the pass phrase.

Questions & Feedback

If you have any thoughts about this, please send me feedback or discuss this topic in G+. Especially why using nonce is better or worse option than signing with (on purpose leaked) ephemeral key.

Btw. As always, don't forget to check the authenticity of the contacts primary key being used. Remember Air Gap & Physical Security.

P.S. If someone posts a nice response to this, I'm really happy to link to it.

- Thank you!

KW: GPG, PGP, Pretty Good Privacy, GnuPG, Ephemeral Key / Keys, Deniable Encryption, privacy, private, communication, secure, security, secured, confidential, confidentially, Off-the-Record messaging, OTR, discussion, topic, forum, question, crypto, OpenPGP, Pretty Good Privacy, GNU Privacy Guard, PFS, FS, PyCrypto.