OTR: Off-the-Record protocol

“Off-the-Record Communication, or, Why Not To Use PGP” is the title of the paper that introduces the OTR protocol.

The OTR protocol separates the identity key from the encryption keys. Encryption keys are continually derived and deleted after use, providing both forward secrecy and backward secrecy.

Alice and Bob each know the other’s identity public key. When they add each other as contacts, they each randomly generate a Diffie–Hellman private/public key pair—[S(a1), P(a1)] and [S(b1), P(b1)]—and exchange the public keys. The identity keys indirectly authenticate that the DH public keys genuinely come from the other party.

Each side then uses its own DH private key and the other’s DH public key to perform a Diffie–Hellman calculation and derive the same shared key:

SK1 = S(a1) × P(b1) = S(b1) × P(a1).

Alice encrypts message M1 to Bob with SK1. Before sending M1, she also generates a new DH key pair [S(a2), P(a2)] and attaches P(a2) to M1.

When Bob receives M1, he decrypts it with SK1. He then prepares M2 (a reply to M1), randomly generates a new DH key pair [S(b2), P(b2)], performs a DH calculation to obtain

SK2 = S(b2) × P(a2),

encrypts M2 with SK2, and appends P(b2) to M2.

After Alice receives M2, she performs a DH calculation to obtain the same

SK2 = S(a2) × P(b2)

and decrypts M2 with it. When preparing M3 (a reply to M2), Alice randomly generates [S(a3), P(a3)], performs a DH calculation to derive

SK3 = S(a3) × P(b2),

encrypts M3 with SK3, and attaches P(a3).

This process continues indefinitely; it is called the DH ratchet, which keeps turning forward.

The DH ratchet advances in step with the back-and-forth messages, so users passively gain forward and backward secrecy simply by continuing to exchange messages.

If a DH private key is compromised at some moment, an attacker can decrypt only that single message. After the parties exchange another message and the DH ratchet advances, they recover from the compromise. (The “compromise” here does not refer to continuous real-time eavesdropping—encryption cannot help against that—but rather to an attacker capturing a key at one moment and being unable to keep decrypting subsequent messages.)

Reply to this note

Please Login to reply.

Discussion

What kind of eavesdropping are you referring to?

For example, an operating system-level bug.

Sure. I was thinking you meant network-level (passive) observation.

Any OS-privileged compromise would possibly affect any program, with the exception of "third-party" "assistance" such by using TPM or TEE right? (Unless you meant something like hooking into keyboard-handling hooks that aren't well protected/separated/isolated.)

Does Keychat do this differently, or any other reason for the emphasis?

Also, slight inaccuracy but nitpicking. One can send multiple messages in a series all in the same ratchet. So it isn't a "single" message. I'm guessing you meant that.

The final sentence is simply meant to highlight the scope of PCS (post-compromise security) so that readers don’t mistakenly think it can do everything.

We will discuss the case in the Signal protocol where Alice sends several messages in a row, because Signal adds another ratchet specifically to handle this situation.