Weak deniability. The main goal of the OTR designers is plausible deniability. One consequence of this is that an attacker could conceivably determine which of several clients you’re using to initiate a connection. A final approach is to use the Socialist Millionaires’ Problem to prove that both parties share the same secret. Alternatively, they can exchange the “session ID” calculated in the second phase of the protocol. OTR provides three mechanisms for doing this: parties may exchange fingerprints (essentially hashes) of ( pubA, pubB) via a second channel. To verify that nothing’s amiss, both Alice and Bob should eventually authenticate each other. Lazy authentication. Of course if Alice and Bob never exchange public keys, this whole protocol execution is still vulnerable to a man-in-the-middle (MITM) attack.
#Guide cryptocat join room mac#
It then reveals the MAC keys for the previous messages. After sending a MAC, each party waits for an authenticated response from its partner. They can each verify these signatures and abort the connection if something’s amiss.** Using the encrypted channel they’ve previously established, they now set about to fix this.Alice and Bob each send their long-term DSA public key ( pubA, pubB) and key identifiers, as well as a signature on (a MAC of) the specific elements of the Diffie-Hellman message ( g^x, g^y) and their view of which party they’re communicating with. So far Alice and Bob have not actually authenticated that they’re talking to each other, hence their Diffie-Hellman exchange could have been intercepted by a man-in-the-middle attacker.
Since the session ID value is derived by hashing the Diffie-Hellman shared secret, it’s possible to use a relatively short session ID value to authenticate the channel, since neither Alice nor Bob will be able to force this ID to a specific value. Alice can decrypt this value and check that it matches the hash Bob sent in the first message.Now that both sides have the shares ( g^x, g^y) they each use their secrets to compute a shared secret g^. Bob can now ‘open’ his share to Alice by sending the AES key r that he used to encrypt it in the previous step. Next, Alice sends her half of the key exchange protocol ( g^y). Hash commitment. First, Bob commits to his share of a Diffie-Hellman key exchange ( g^x) by encrypting it under a random AES key rand sending the ciphertext and a hash of g^x over to Alice.There are four elements to this protocol: There’s alsoĪn OTRv1 protocol that’s too horrible to talk about here. Diagram by Bonneau and Morrison, all colorful stuff added. However it must be noted that this requirement makes the problem a bit more sexy. In fact, to the best of my knowledge no court in the history of law has ever used a cryptographic transcript as evidence that a conversation occurred. Your chat partners are all FBI informants so your chat transcripts must be plausibly deniable - so as to keep them from being used as evidence against you in a court of law.Ĭoming to this problem fresh, you might find goal (3) a bit odd.Users won’t bother to exchange keys, so authentication should be “lazy” (i.e., you can authenticate your partners after the fact).Messages must be ASCII-formatted and have some (short) maximum length.OTR works within the technical and usage constraints of your typical IM system. Also: they picked a cool name and released working code. are smart researchers who know what they’re doing. OTR was originally developed by Borisov, Goldberg and Brewer and has rapidly come to dominate its niche. You can enable it in some other clients through plugins and overlays. If you use IM clients like Adium, Pidgin or ChatSecure, you already have OTR support. OTR is probably the most widely-used protocol for encrypting instant messages. If you’re looking for exciting vulnerabilities in protocols, go check out someone else’s blog. I want to be clear from the start that this post has absolutely no destination.
0 kommentar(er)
