1. Off-the-Record Communication, or, Why Not To Use PGP
Slides by
Su Zhang
Nov 8th, 2010

2. Differences between Off-the-Record Communication and PGP System
Long-live encryption key
Non-Repudiable authentication
Off-the-Record communication
Perfect forward secrecy
Repudiability (verifiable only to receiver but not other people )
Off the Record Communication, or, Why Not To Use PGP
11/8/2010

3. What Security Properties do We Want?
Encryption -- Hide the content of conversation
Perfect Forward Secrecy -- Protect against future compromises
Authentication -- Make sure the person you are talking to is the right one
Repudiation – Make sure the communications are personal and unverifiable to third parties
Off the Record Communication, or, Why Not To Use PGP
11/8/2010

4. Why Hard to Guarantee Online Security Properties?
Compromising decrypt key will expose past and future encrypted messages with that key
Any third party could verify the identity of the sender through verifying the signature on the (digital signature is used by protocols like PGP)
Off the Record Communication, or, Why Not To Use PGP
11/8/2010

5. Perfect Forward Secrecy
Using short-lived encryption/decryption keys
Impossible to re-derive from their long-term keys
No one (including sender and receiver) couldn’t re- construct the key
Keys are generated through Diffie-Hellman key agreement protocol
Off the Record Communication, or, Why Not To Use PGP
11/8/2010

6. Cryptographic Primitives Used by OTR
Digital Signatures
Message Authentication Codes (MAC)
Malleable encryption (AES)
Off the Record Communication, or, Why Not To Use PGP
11/8/2010

7. Digital Signatures Long-lived Signature keys (acceptable)
Key compromising won’t affect past authentication (since authenticated messages are successfully received)
Non-repudiation (undesirable)
Signer couldn’t disclaim the authorship of a message she signed
Signed messages could be verified by anyone without signer’s cooperation
Save a lot of space
O(n) keys (shared secret has O(n2) keys )
Off the Record Communication, or, Why Not To Use PGP
11/8/2010

8. Message Authentication Code
MAC can check the integrity of the message
Cannot provide Non repudiation (repudiable)
Two parties could authenticate each other (by using their shared secret) but others couldn’t
Bob cannot show others that Alice has sent him the message since himself could have made the message.
Off the Record Communication, or, Why Not To Use PGP
11/8/2010

9. Malleable Encryption and Forgeability
Everyone could have changed the message before it arrive at the receiver end (or before attacker get it)
Modifying some cipher text could change the meaning of plain text even without knowing encryption key. (e.g. stream cipher)
Attacker could choose another message which could have a same length of cipher text then replace it with original one
This is to show that anyone could have modified the message so nobody (except Bob) could find any clue about Alice from the message she sent.
Off the Record Communication, or, Why Not To Use PGP
11/8/2010

10. The Off-the-Record Messaging Protocol
Using the primitive encryptions mentioned above
Achieve the aforementioned security properties
Mainly for low-latency communication protocols
Off the Record Communication, or, Why Not To Use PGP
11/8/2010

11. Off-the-Record -- Encryption
Encryption algorithm—AES (Malleable)
Encryption key – Generated through Diffie- Hellman agreement
Short-term key (forward secrecy): re-generated keys frequently
Diffie-Hellman’s computational cost is really cheap (only two modular exponatiation), so communication parties could re-generate keys as frequently as possible.
Off the Record Communication, or, Why Not To Use PGP
11/8/2010

12. Off-the-Record – Message Exchange
Exchange course
A  B : gx1
B  A : gy1
A  B : gx2 ,E(M1, k11)
B  A : gy2 ,E(M2, k21)
A  B : gx3 ,E(M3, k22)
Key construction
gxiyj is called shared secret in DH protocol
Encryption key kij = H(gxiyj )
Where kij = H(gxiyj ), message communicating is going with key exchange. Each message is encrypted using the shared secret
derived from the last key received from the other party and the last key that has been previously sent to the other party.
key ID should also be used in the message to ensure that both the sender and the receiver know which kij is being used, since the protocol does not require that Alice and Bob take turns sending messages to each other.
Off the Record Communication, or, Why Not To Use PGP
11/8/2010

13. Off-the-Record --Forgetting Keys
A couldn’t forget Xi-1 and its afterwards keys until it received a message encrypted with Xi from B
A only generate a new key after she received a reply from B (So A holds at most two keys at a time.)
Send empty message if one haven’t sent for a while
Each shouldn’t leave without sending a message for too long time. Instead, it should send empty message to reduce the size of vulnerable window (a key hasn’t been changed for a long time)
Off the Record Communication, or, Why Not To Use PGP
11/8/2010

14. Off-the-Record -- Authentication
At the beginning, using digital signature to verify each other’s identity.
A B : Sign(gx1, ka), KA
B A : Sign(gy1, kb), KB
Then message encrypted with H(gx1y1) could be accepted
Use MAC keys as following authenticators
Even if eve got encryption key, she still couldn’t know the identities of the sender or receiver
Off the Record Communication, or, Why Not To Use PGP
11/8/2010

15. Off-the-Record – Authentication (cont)
Following protocol message:
gx(i+1), E(Mk, kij ), MAC({gx(i+1), E(Mk, kij )}, H(kij))
MAC key: H(kij) =H( H(gxiyj ))
Both message and the encryption key are authenticated
Off the Record Communication, or, Why Not To Use PGP
11/8/2010

16. Revealing MAC keys
Let everyone could use the MAC keys as authenticator. (No one can prove message authenticated by these keys are from Alice)
Past authenticated messages through these keys are validated (Because these messages are successfully received.)
Off the Record Communication, or, Why Not To Use PGP
11/8/2010

17. Implementation of OTR- Design
Off-the-Record protocol is built on top of an IM protocol
Incremental deployment
A user could use their IM client to communicate with people have the security plug-in or not
Virtual session
Last until the client terminated or a period of inactive
A message is first encrypted and authenticated using our protocol, and then the result is encoded as a text message and sent as a regular instant message.
To support these two modes, the plugin must keep a list of which buddies support secure communication and which don’t. This list is populated automatically: the first time Alice sends a message to another user, Bob, it is sent unencrypted
Off the Record Communication, or, Why Not To Use PGP
11/8/2010

18. Implementation of OTR- Implementation
IM Client: GAIM
Could integrate several different IM applications
API dealing with Off-the-Record
Received an encrypted message
Received a clear texted message
Received an error information
Received an ignorable message (doesn’t include user message)
Off the Record Communication, or, Why Not To Use PGP
11/8/2010

19. Using OTR on high-latency application -Email
Impractical on key agreement
Diffie-Hellman protocol needs two parties to be online
Solution: Ring signatures
A set of people could sign a signature but others couldn’t tell which one signed. (Similar to MAC authentication but less privacy (since sender will be confined into a small range))
Mitigate the less privacy issue
Publish signature key after all signed messages have been authenticated (make short term keys)
Off the Record Communication, or, Why Not To Use PGP
11/8/2010

20. Conclusions Off-the-Record realized ideal security properties
Repudiable online communication
Perfect forward secret manner
Maintaining confidentiality and authenticity assurances
confidentiality
Off the Record Communication, or, Why Not To Use PGP
11/8/2010

21. Questions & Discussion
Thank you!
Off the Record Communication, or, Why Not To Use PGP
11/8/2010