Encrypt your messages BETTER (Forward Secrecy)

How to implement Forward Secrecy and reduce your exposure in case of future key compromise by adopting better practices.

Encrypt your messages BETTER (Forward Secrecy)

#OpSec, bitches!

tl;dr: After completing a normal key exchange, DO IT AGAIN and switch to Session Keys to reduce your exposure in case of compromise. This is a human-practical implementation of Forward Secrecy, albeit an incomplete one.

A definition:

Most of us on the darknet publish a keypair used for identity and first contact purposes. I'll call these Long Term Identity Keys. They're our long term keys that accumulate signatures and expire every few years. Session Keys, however, are unpublished keys exchanged secretly, used for a limited time, discarded and replaced. This is similar to the machanisms in OTR messaging and TLS, the security layer in HTTPS. The procedure. Is fucking. Standard.

An example:

Let's say that Alice and Bob have completed a key exchange or they already have each others' pre-published Long Term Identity Keys and are now able to send encrypted messages back and forth. Great! Now they perform another key exchange using the encrypted tunnel they've created to send each other Session Keys. These temporary (aka "ephemeral") keys are then used for a limited duration like 1 hour, 1 week, 1 message, 100 messages, 1 meg or gig of data, etc. At some arbitrary interval the key is cycled out- expired, revoked, replaced with a new one. A Session Key should be signed by the previously accepted Long Term Identity Key. Duh.

For clarity: The scope here is PGP personal use. Session Keys are not specially created or derived keys as in TLS or elsewhere. They're just another pair of normal PGP keys just like the Long Term Identity Keys we publish.

Why? A list of risks and rewards:

  • The use of Session Keys limits the amount of ciphertext available for cryptanalysis attacks on any one key, enhancing their resistance in the present and theoretically lengthening the timeframe for which our messages will remain secure despite advances in technology and attack methodology.

  • It conceals even the public Session Key used for encryption because that key was sent encrypted by the Long Term Identity Key in the first place. This further hampers attacks on our privacy. As usual, messages will still include the key fingerprint.

  • A broken Session Key can only expose the data that it was used to encrypt; a slice of our data instead of everything we received from everyone, everywhere.

  • A broken Long Term Identity Key can only expose the initial contact messages and the public Session Keys, not the data encrypted by individual Session Keys. Consider destroying Session Keys when they are cycled out. Mind your data forensics countermeasures.

But it's a pain in the ass!

Yes, it is. Welcome to the Usability-Security Paradox. You'll get used to it. Here are some variations to make it slightly less cumbersome but which trade security for convenience:

  • Generate a new Session Key for each person you communicate with, but refresh it less frequently.

  • Generate a new Session Key and use that for all senders, refreshing it more frequently.

  • Generate a batch of keys ahead of time and use key expiration to enforce key cycling. Send a new key when an old one expires. Note that this increases the threat to your privacy if the local machine is compromised.

  • Send Session Keys in batches, again using expiration to enforce key cycling. Note that expiration does not prevent a key being used ahead of schedule, so consider adding dates/timeframes to the keys' name or comment fields for the sender's reference.

How often to change Session Keys?

I said "the procedure is fucking standard", but I meant in other areas like OTR and TLS. In the world of personal PGP use, there are only suggested best practices. Unless you are a professional cryptographer, any interval is basically a magic number. Sooooo... 42.

A final note:

For the sake of familiarity, the example Alice-Bob scenario uses two people who have published keys known to each other, but the same model can and should be applied in any case. If a random stranger with candy sends you a key and you decide to respond and perform a key exchange, STILL perform the additional step and switch to session keys.