From jason at sjobeck.com Wed Mar 1 01:29:37 2006 From: jason at sjobeck.com (Jason SJOBECK) Date: Tue, 28 Feb 2006 22:29:37 -0800 Subject: [OTR-dev] fyi, just a typo' Message-ID: Just a typo', just fyi, that I just noticed: "We received an unreadable encrypted messahe from bob at innsbruck" where "messahe" ought to be "message" Thanks so much. Peace. Jason From kat at paip.net Wed Mar 1 08:48:02 2006 From: kat at paip.net (Kat Hanna) Date: Wed, 1 Mar 2006 08:48:02 -0500 (EST) Subject: [OTR-dev] fyi, just a typo' In-Reply-To: References: Message-ID: Hi Jason, That's actually fixed in CVS. But thanks for reporting it. -Kat On Tue, 28 Feb 2006, Jason SJOBECK wrote: > Just a typo', just fyi, that I just noticed: > > "We received an unreadable encrypted messahe from bob at innsbruck" > > where "messahe" ought to be "message" > > Thanks so much. > > Peace. > > Jason > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From ian at cypherpunks.ca Thu Mar 2 08:48:46 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 2 Mar 2006 08:48:46 -0500 Subject: [OTR-dev] Decrypting messages from an old OTR conversation In-Reply-To: References: Message-ID: <20060302134846.GM31096@smtp.paip.net> On Mon, Feb 27, 2006 at 08:08:38PM +0100, Paul Wouters wrote: > On Mon, 27 Feb 2006, Evan Schoenberg wrote: > > > The problem: some services support serverside offline messaging. Yahoo and > > ICQ, for example. If Bob is in an encrypted conversation with Alice, and > > Alice signs offline, the service still allows Bob to message Alice, storing > > the (encrypted) message on the server for delivery when Alice next signs > > online. Bob knows that Alice has the information for decrypting his message, > > since they've been communicating previously... > > > > So Alice signs on a day later... but she can't read the message, since the > > conversation has since ended. She receives: > > The encrypted message received from Bob is unreadable, as you are not > > currently communicating privately. > > When signing off, the client should close the OTR connection to the > "finished" state. To be clear: when Alice's client is about to go offline, it should send OTRL_TLV_DISCONNECTED packets to each of the buddies with which she currently has a OTRL_MSGSTATE_ENCRYPTED session (and protocol version greater than 1). That will notify Bob's client that Alice can no longer read encrypted messages, and it won't try to send one. See process_quitting() in gaim-otr/otr-plugin.c to check out how gaim does this. - Ian From asm at CS.Stanford.EDU Mon Mar 6 19:35:35 2006 From: asm at CS.Stanford.EDU (Andrew S. Morrison) Date: Mon, 6 Mar 2006 16:35:35 -0800 Subject: [OTR-dev] Draft of Security Analysis Message-ID: <20060307003535.GA22368@xenon.Stanford.EDU> We wanted to send along the draft of some of the results of our security analysis before we give a talk on it in a few days in hopes we could get some comments. We believe we've found a few good attacks. http://www.stanford.edu/~amo/DRAFT_otr_analysis.pdf The paper is just a draft right now. We're hoping some people on this list could take a look at the "Attacks Found" section and read through to make sure the attacks are legitimate. After a round of getting comments from you guys and some others we'll send the final version of our paper and the Murphi code we used to model OTR. That'll be in about a week and a half. The talk we're giving will be on Stanford campus this Thursday some time after 1:15. If anyone is interested in coming to see our presentation let me know. It'll only be about 15 minutes, and there'll be a few other presentations from groups analyzing other protocols. -- Andrew S. Morrison asm at cs.stanford.edu (650) 575 9261 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ian at cypherpunks.ca Mon Mar 6 21:45:09 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 6 Mar 2006 21:45:09 -0500 Subject: [OTR-dev] Draft of Security Analysis In-Reply-To: <20060307003535.GA22368@xenon.Stanford.EDU> References: <20060307003535.GA22368@xenon.Stanford.EDU> Message-ID: <20060307024509.GZ1288@smtp.paip.net> On Mon, Mar 06, 2006 at 04:35:35PM -0800, Andrew S. Morrison wrote: > We wanted to send along the draft of some of the results of our security > analysis before we give a talk on it in a few days in hopes we could get > some comments. We believe we've found a few good attacks. > > http://www.stanford.edu/~amo/DRAFT_otr_analysis.pdf > > The paper is just a draft right now. We're hoping some people on this list > could take a look at the "Attacks Found" section and read through to make > sure the attacks are legitimate. After a round of getting comments from > you guys and some others we'll send the final version of our paper and the > Murphi code we used to model OTR. That'll be in about a week and a half. I took a (very) quick look, but I'll be travelling tomorrow, and may not have email access again before your talk. 3.1 Version Rollback Version rollback, I think, is only a serious concern when it's invisible (in SSL, for example). In OTR (at least the gaim-otr UI; I can't speak for the others), it's clear when you're sending and receiving encrypted messages, and when you're not. Additionally, it's made clear when you're using version 1 of the protocol, so you can take the precaution of asking your buddy to say her name. 3.2 Attack on Strong Deniability The attack relies on Bob publishing incorrect MAC keys. But that doesn't make sense; Bob publishes the MAC keys in order *to protect himself*. Intentionally publishing incorrect ones (or, he may as well just not publish them at all) would only serve to weaken his own deniability. Note also that Alice and Bob each publish the MAC keys, so they'd *both* have to be intentionally trying to make their own conversation not deniable. 3.3 Message Integrity Good call on this one. Bizarrely, it doesn't turn out to be a security hole in the deployed software because there's a bug in it. (!) The deployed software only publishes MAC keys that were used to receive messages, not ones on messages it sent. This is safe, because it knows for sure that it'll never trust a MAC key that it's already published. I also believe that even if Bob is cheating, and doesn't publish any MAC keys, but only Alice publishes the MAC keys of the messages she receives, they still get strong deniability: Mallory can take one of the messages Alice received (and subsequently published the MAC key for), and substitute a g^y of his choosing. He can then recompute the keys and MACs for future messages in the transcript. [It's late, and I'm doing this quickly, so I don't guarantee this is correct. I'll think about it some more in the next couple of days.] Assuming this is correct, you indeed found a problem with the spec, but not in the implementation, because the implementation turns out to be more secure than the spec. 3.4 Authentication Failure I don't see the problem here. Alice believes she's talking to Bob, because she *is* talking to Bob. If Mallory is passing messages through unmodified, she may as well be a wire. It's not a security problem if Mallory sees encrypted messages, and her being able to stop Alice and Bob from talking to each other is just a Denial of Service attack, which we explicitly don't care about. Thanks for the analysis! Feel free to email me or the list with any questions, comments, or radical doubts. ;-) [Though, as I mentioned, I may or may not have email access from Tuesday morning to Thursday.] - Ian From asm at CS.Stanford.EDU Tue Mar 7 17:41:51 2006 From: asm at CS.Stanford.EDU (Andrew S. Morrison) Date: Tue, 7 Mar 2006 14:41:51 -0800 Subject: [OTR-dev] Draft of Security Analysis In-Reply-To: <20060307024509.GZ1288@smtp.paip.net> Message-ID: <20060307224151.GA4064@xenon.Stanford.EDU> Thanks for the reply. I have a few clarifications that we'll put in the paper before it's final version, but should help aide discussion now. > 3.1 Version Rollback > > Version rollback, I think, is only a serious concern when it's > invisible (in SSL, for example). In OTR (at least the gaim-otr UI; > I can't speak for the others), it's clear when you're sending and > receiving encrypted messages, and when you're not. Additionally, > it's made clear when you're using version 1 of the protocol, so you > can take the precaution of asking your buddy to say her name. Although it's possible to set which versions you will and will not use in the UI, setting it to "any version" or "just 1 or 2" allows an attacker to force version 1 or 0 even if 2 is the desired version for both parties. So, although the conversation will be encrypted and it may be clear to the user that they're using version 1 instead of the version 2 that they desired, they will accept this thinking that the other party only supports vesion 1. > 3.2 Attack on Strong Deniability > > The attack relies on Bob publishing incorrect MAC keys. But that > doesn't make sense; Bob publishes the MAC keys in order *to protect > himself*. Intentionally publishing incorrect ones (or, he may as > well just not publish them at all) would only serve to weaken his > own deniability. Note also that Alice and Bob each publish the MAC > keys, so they'd *both* have to be intentionally trying to make their > own conversation not deniable. I think the point is that an attacker with tight network control on both end points is capable of removing or mangling the published MAC keys, and thus destroying strong deniability. > 3.3 Message Integrity > > Good call on this one. Bizarrely, it doesn't turn out to be a > security hole in the deployed software because there's a bug in >it. (!) > The deployed software only publishes MAC keys that were used to > receive messages, not ones on messages it sent. This is safe, > because it knows for sure that it'll never trust a MAC key that it's > already published. I also believe that even if Bob is cheating, and > doesn't publish any MAC keys, but only Alice publishes the MAC keys > of the messages she receives, they still get strong deniability: > Mallory can take one of the messages Alice received (and > subsequently published the MAC key for), and substitute a g^y of his > choosing. He can then recompute the keys and MACs for future > messages in the transcript. [It's late, and I'm doing this quickly, > so I don't guarantee this is correct. I'll think about it some more > in the next couple of days.] Assuming this is correct, you indeed > found a problem with the spec, but not in the implementation, > because the implementation turns out to be more secure than the > spec. I knew bugs would start pulling their own weight one of these days :) I think it's an error to be trusting only a single party to publish the MAC keys. That gives a single party the power to enable or disable strong deniability for half the conversation. This is weaker security than is claimed. > 3.4 Authentication Failure > > I don't see the problem here. Alice believes she's talking to Bob, > because she *is* talking to Bob. If Mallory is passing messages > through unmodified, she may as well be a wire. It's not a security > problem if Mallory sees encrypted messages, and her being able to > stop Alice and Bob from talking to each other is just a Denial of > Service attack, which we explicitly don't care about. This attack is a bit of an edge case, but we believe it's a valid attack on the protocol nonetheless. The point is that one party is committing to the AKE having no clue who they're talking to. Bob doesn't know who Alice is and has no desire to communicate with her, but still she is able to be convinced to commit to AKE with him. Perhaps the invariant that "no party shall commit to an AKE exchange without both parties being who they say they are" is too strong. I think the real "edge case" part about this attack is that there is nowhere interesting to go once Alice has been tricked. -- Andrew S. Morrison asm at cs.stanford.edu (650) 575 9261 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at cypherpunks.ca Wed Mar 8 14:54:50 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Wed, 8 Mar 2006 20:54:50 +0100 (CET) Subject: [OTR-dev] Draft of Security Analysis In-Reply-To: <20060307224151.GA4064@xenon.Stanford.EDU> References: <20060307224151.GA4064@xenon.Stanford.EDU> Message-ID: On Tue, 7 Mar 2006, Andrew S. Morrison wrote: > I think the point is that an attacker with tight network control on both > end points is capable of removing or mangling the published MAC keys, and > thus destroying strong deniability. Doesn't the other end check the MAC? If not, perhaps it should. This attack should be detectable. Though I guess a complex attack could work where the mac is sent *privately* by the attack to the other endpoint's attacker to rewrite the packet. But that is a lot of work for destroying strong deniability (and wouldn't work on say, a wifi connection, where the attacker sees the packet together with everyone else before it can modify it. Paul From asm at CS.Stanford.EDU Wed Mar 8 15:08:49 2006 From: asm at CS.Stanford.EDU (Andrew S. Morrison) Date: Wed, 8 Mar 2006 12:08:49 -0800 Subject: [OTR-dev] Draft of Security Analysis In-Reply-To: References: <20060307224151.GA4064@xenon.Stanford.EDU> Message-ID: <20060308200849.GA9116@xenon.Stanford.EDU> I agree, the strong deniability attack isn't very strong in the real world, but formal verification is our goal here, not being able to crack into people's conversations, so we have to include attacks like this and the authentication failure. On 0, Paul Wouters wrote: > On Tue, 7 Mar 2006, Andrew S. Morrison wrote: > > > I think the point is that an attacker with tight network control on both > > end points is capable of removing or mangling the published MAC keys, and > > thus destroying strong deniability. > > Doesn't the other end check the MAC? If not, perhaps it should. This attack > should be detectable. Though I guess a complex attack could work where > the mac is sent *privately* by the attack to the other endpoint's attacker > to rewrite the packet. But that is a lot of work for destroying strong > deniability (and wouldn't work on say, a wifi connection, where the attacker > sees the packet together with everyone else before it can modify it. > > Paul > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev -- Andrew S. Morrison asm at cs.stanford.edu (650) 575 9261 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From asm at CS.Stanford.EDU Tue Mar 21 17:32:20 2006 From: asm at CS.Stanford.EDU (Andrew S. Morrison) Date: Tue, 21 Mar 2006 14:32:20 -0800 Subject: [OTR-dev] Finite-State Analysis of OTR V2 Message-ID: <20060321223220.GC2354@xenon.Stanford.EDU> We've completed our finite-state analysis of OTR V2. The paper outlining our results, including attacks we've discovered and potential solutions may be downloaded from http://www.stanford.edu/~amo/otr_analysis.pdf We modeled OTR using Murphi (http://verify.stanford.edu/dill/murphi.html). Instructions for installing Murphi can be found at http://sprout.stanford.edu/dill/murphi.html#Getting . The model may be downloaded from http://www.stanford.edu/~amo/MurphiOTR-1.0.tar.gz To run the model, first install Murphi, then decompress MurphiOTR-1.0.tar.gz and edit the Makefile to point to the correct location of Murphi. You may then run `make` to compile two programs; otrake and otrdata. otrake is a model of the authenticated key exchange while otrdata is a model of the data exchange protocol. Setting the various flags at the top of otrake.m and otrdata.m will show the attacks we've discovered and give a trace of the violating path. My partner Joe Bonneau and I would love to hear feedback from everyone about the analysis and argue about if the attacks are actually possible or not. One attack we've discovered is strong enough to force a version 3 of the protocol, we believe. We'd love to be involved in any discussion leading to that, and update the model when the time comes. -- Andrew S. Morrison asm at cs.stanford.edu (650) 575 9261 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: