PGP: Pretty Good Privacy protocol In PGP, both Alice and Bob have their own public/private key pairs, which serve as both their identity keys and their encryption keys. Alice and Bob are friends and know each other’s public keys. • Alice uses her private key to sign the message. • She then encrypts the signed message with Bob’s public key and sends it. • When Bob receives the encrypted message, he first decrypts it with his private key. • He then uses Alice’s public key to verify that the signature was indeed created by Alice. PGP provides the simplest end-to-end encryption, ensuring that only the two parties in the conversation can decrypt the messages. However, if either of their private keys is ever leaked, both past and future messages can be decrypted; PGP therefore lacks forward secrecy and backward secrecy (also called post-compromise security, PCS).

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.)

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.