Introducing Off-the-Record communication
While GPG has its place, if you are concerned about losing control of your private key,
then maybe you should consider other tools. One tool, which was designed with this threat
in mind, is called Off-the-Record ( OTR ) which was originally published in the paper Off-
the-Record Communication, or, Why Not To Use PGP (Borisov 2004). OTR includes some
cryptographic features and design goals that differ from PGP. For example, OTR was de-
signed to incorporate perfect forward secrecy , which ensures that session keys , the keys
that are encrypting the communication traffic, can't be re-derived if the longer term identity
key is compromised. Also OTR only uses digital signatures for the initial authentication
step; individual messages are not signed.
The session keys are derived independently by both parties through a Diffie-Hellman Key-
Exchange protocol. The Diffie-Hellman protocol helps to solve a key distribution problem.
Alice and Bob want to secure their communications with a symmetric cipher, but they both
need the same key. Using Diffie-Hellman, they can both derive the shared key value over
an insecure channel, without exposing the value of the key to a third party. OTR uses asym-
metric cryptography in a Diffie-Hellman key-exchange, so that both parties can derive a
shared AES key in counter-mode. AES in counter-mode ( AES-CTR ) uses AES as a
stream cipher, the significance of which is discussed later in this section.
A simplified, two-minute description of the Diffie-Hellman Key Exchange is available at
Khan Academy website https://www.khanacademy.org/computing/computer-science/cryp-
Another feature of OTR that is different than PGP is that OTR was designed with repudiab-
ility for messages, which is the ability to deny authorship or validity. PGP was designed for
non-repudiability, which provides a proof, via your digital signature, that you indeed cre-
ated that message. However, with OTR, neither Alice nor Bob can prove the other, or them-
selves, created a particular message. The details of this feature are a bit technical, but we'll
provide a high-level summary since it is a clever use of Message Authentication Codes
( MACs ).
A MAC is a small tag that accompanies a block of data. The tag is computed by the sender
and is sent to the receiver, who recomputes the value to check that the data was not corrup-
ted in transit, which attests the integrity of the data. Furthermore, MACs involve a shared-
key between parties. So, Alice has the same MAC key as Bob. Therefore, when Bob veri-