Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Wes Chow on "Off-the-Record­ Communication, or, Why Not To Use PGP"

Wes Chow on "Off-the-Record­ Communication, or, Why Not To Use PGP"

Your intrepid reporter goes to a private location and meets with a key source who wishes to remain anonymous and off the record. The reporter understands that all information she learns from the source must be validated elsewhere and not directly quoted (private), that the source is who he says he is (authenticated), and that should their conversation become public they could both plausibly deny having said any of the recorded words (repudiable). How do we construct a digital version of an IRL meeting?

Nikita Borisov, Ian Goldberg, and Eric Brewer devise a communication protocol in Off-the-Record Communication, or Why Not To Use PGP that provides all of the above mentioned properties, as well as forward-secrecy (breaking the encryption on one message doesn’t give an attacker keys to past or future messages). Wes will review the OTR protocol and its clever collection of strong and purposefully weak cryptographic techniques that form the basis of the Signal private messaging app.

Papers_We_Love

July 19, 2017
Tweet

More Decks by Papers_We_Love

Other Decks in Technology

Transcript

  1. Off-the-Record Communication
    Or, Why Not To Use PGP
    Borisov, Goldberg, Brewer
    Presented by Wes Chow, @weschow, slides at http://bit.ly/whispering-jellyfish

    View full-size slide

  2. What Does Off the Record Mean?
    - Alice is a reporter.
    - Bob is a whistleblower. He wants to remain anonymous to the public.
    - They meet secretly to chat.
    - Alice writes nothing down, and verifies information with other sources.
    - Eve may overhear their conversation.
    - How do we mimic this online?

    View full-size slide

  3. PGP, Pretty Good Privacy (public-key crypto)
    p, r = key pair (p is public, r is private)
    E(M, p) = ciphertext of M, using function E with p
    Essential property:
    D(E(M, p), r) = M and
    D(E(M, r), p) = M
    In other words, encrypting with one requires decrypting with
    the other.

    View full-size slide

  4. PGP, Pretty Good Privacy (public-key crypto)
    Encrypt to Alice is obvious:
    E(M, p) = ciphertext

    View full-size slide

  5. PGP, Pretty Good Privacy (public-key crypto)
    Authenticated by Alice is less obvious:
    E(DIGEST(M), r) = signature
    Digest:
    Short and hard to reverse computation on M, ie sha1.
    Verifiable by Bob.

    View full-size slide

  6. PGP, Pretty Good Privacy (public-key crypto)
    E(M, p) = ciphertext
    E(DIGEST(M), r) = signature
    (Bob has his own pair.)

    View full-size slide

  7. Public-Key Implications
    - Keypairs are long lived.
    - Eve can’t see what’s in encrypted messages.
    - But if Eve breaks a message, keypair may be compromised.
    - A compromised keypair means all past and future messages are readable,
    and messages are forgeable.
    - A signature is proof of authorship, no deniability.

    View full-size slide

  8. Structure of Talk
    - We’ll follow paper closely, build up the OTR protocol.
    - I’ll digress to explain some basic crypto.

    View full-size slide

  9. How to Encrypt
    - Alice wants to send M to Bob.
    - Eve can’t learn M, so M should be encrypted.

    View full-size slide

  10. Diffie-Hellman Key Exchange
    Start with public seed and * function.
    * is hard to unmix (not in scope of this talk, sorry)
    Alice generates random private key, xa.
    Bob generates random private key, xb.

    View full-size slide

  11. Diffie-Hellman Key Exchange
    Alice sends (seed * xa) → Bob
    Bob sends (seed * xb) → Alice
    Alice computes (seed * xb) * xa
    Bob computes (seed * xa) * xb
    Notice:
    (seed * xb) * xa = (seed * xa) * xb if …?

    View full-size slide

  12. Diffie-Hellman Key Exchange
    (seed * xb) * xa = (seed * xa) * xb = k
    sb * xa = sa * xb = k
    k is the secret key used for encrypting M, established over
    an insecure public channel!

    View full-size slide

  13. OTR Encryption Method
    - Alice and Bob determine k.
    - Alice sends Bob E(M, k).
    - What is E?

    View full-size slide

  14. Block Cipher vs Stream Cipher
    - Block ciphers take a n-bit block of plaintext and map it into a n-bit block of
    ciphertext.
    - Manipulating block ciphers creates chaos.
    - Stream ciphers are byte or bitwise transformations of a keystream on
    plaintext. Ok, let’s unpack that.

    View full-size slide

  15. Stream Cipher
    k = secret key
    keystream = sequence of {0,1} as function of k
    ciphertext = pairwise xor of keystream with plaintext

    View full-size slide

  16. Stream Cipher
    k = [unintelligible mass of numbers…]
    keystream = 011011011010
    plaintext = 101010101101
    xor
    ciphertext = 110001110111
    If you guess plaintext, you can back out keystream.

    View full-size slide

  17. OTR Encryption
    - Uses stream cipher, so that M is purposely forgeable by Eve!
    - Repudiable = plausible deniability
    - Repudiable between Alice and Bob (because k is symmetric).
    - Repudiable if Eve rats on them.
    - So how do Alice and Bob know Eve isn’t forging messages? We’ll come back
    to that.

    View full-size slide

  18. Protocol So Far
    E(M, k)
    where E is stream cipher, and k comes from Diffie-Hellman
    key exchange

    View full-size slide

  19. Perfect Forward Secrecy
    - If Eve captures a message and determines k, then she can now read all
    messages encrypted with k.
    - So, we change k on every message. Now compromise of one message
    doesn’t compromise them all.
    - We could initiate Diffie-Hellman on every message, but that’s wasteful.
    - Instead, we send next half on every message.
    - Note, Alice and Bob only have to remember the last half from each other.
    - They discard secret keys and Diffie-Hellman halves when done.

    View full-size slide

  20. Recall Diffie-Hellman
    Alice sends (seed * xa) = sa
    Bob sends (seed * xb) = sb
    sb * xa = sa * xb = k

    View full-size slide

  21. OTR Protocol w/ Forward Secrecy
    Compute sa2 = (seed * xa2)
    Send E(M1, k1), sa2
    Where M1 is the first message, k1 is the initial
    Diffie-Hellman key, and sa2 is Alice’s next Diffie-Hellman
    half.
    Bob computes k2 = sa2 * xb1.

    View full-size slide

  22. Is the Message Forgeable?
    E(M1, k1), sa2

    View full-size slide

  23. Public-key Crypto to the Rescue
    - Alice and Bob have public-private keypairs.
    - They sign their Diffie-Hellman halves on initial exchange. If this is
    compromised, they have only signed half a k.
    - Now they trust each other’s halves.
    - They compute MAC on messages.

    View full-size slide

  24. Message Authentication Code
    - Similar to digests, but take M and k, and produce a cryptographic signature of
    the two.
    - MAC is easy to compute, can be used to verify that k was used to encrypt M.
    - HMAC is popular, which is:
    H(K^opad || H(K^ipad) || M)

    View full-size slide

  25. OTR Protocol So Far
    E(M1, k1), sa2, MAC(..., H(k1))
    Bob independently computes MAC and verifies. Only someone
    who knows k1 can write this message. Because k1 is trusted
    (signed), Bob trusts this is from Alice.
    M2 authentication follows from induction.

    View full-size slide

  26. Final Trick!
    - Alice publishes the MAC after Bob has acknowledged receipt.
    - Eve (or anybody else) could make up a message that fits any MAC. Extra
    repudiability cleverness.

    View full-size slide

  27. OTR Protocol (Final)
    Use Diffie-Hellman to exchange sa1 and sb1.
    Sign sa1 and sb1.
    Compute k1 = sb1 * xa1
    Alice sends E(M1, k1), sa2, MAC(..., H(k1))
    Bob computes k2 = sa1 * xb1
    Bob sends encrypted M2 to Alice and publishes MAC1.

    View full-size slide

  28. Cryptographic Properties
    - Perfect forward secrecy
    - Digital signatures
    - Message Authentication Codes
    - Malleable Encryption
    - Repudiability

    View full-size slide