From michaelhoofd at yahoo.com Mon Aug 16 12:45:24 2010 From: michaelhoofd at yahoo.com (Michael Hoofdburg) Date: Mon, 16 Aug 2010 09:45:24 -0700 (PDT) Subject: [OTR-users] pidgin-otr plugin on N900 : invalid length error Message-ID: <96835.79637.qm@web120219.mail.ne1.yahoo.com> Hi,? Been using Pidgin with the pidgin-otr plugin on my Nokia Maemo N900 phonewhithout any problems. All worked well. That was with the otr-plugin version 3.2.0-6. Now the phone got some updates and the pidgin-otr plugin updated toverion 3.2.0-8.? Now whenever I try to start a 'Private' conversation I get the error:? "Error setting up private conversation: Invalid length"? On my Ubuntu laptop with the same pidgin / pidgin-otr versions OTR works fine.? Anyone have any idea where the problem might be?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at cypherpunks.ca Mon Aug 23 08:07:03 2010 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 23 Aug 2010 08:07:03 -0400 Subject: [OTR-users] pidgin-otr plugin on N900 : invalid length error In-Reply-To: <96835.79637.qm@web120219.mail.ne1.yahoo.com> References: <96835.79637.qm@web120219.mail.ne1.yahoo.com> Message-ID: <20100823120703.GA30106@thunk.cs.uwaterloo.ca> On Mon, Aug 16, 2010 at 09:45:24AM -0700, Michael Hoofdburg wrote: > Hi,? > Been using Pidgin with the pidgin-otr plugin on my Nokia Maemo N900 phonewhithout any problems. All worked well. That was with the otr-plugin version 3.2.0-6. > Now the phone got some updates and the pidgin-otr plugin updated toverion 3.2.0-8.? > Now whenever I try to start a 'Private' conversation I get the error:? > "Error setting up private conversation: Invalid length"? > On my Ubuntu laptop with the same pidgin / pidgin-otr versions OTR works fine.? > Anyone have any idea where the problem might be?? Do you know what changed between the -6 and -8 versions of the Nokia package? Who is the packager? - Ian From casmls at gmail.com Wed Aug 25 14:58:03 2010 From: casmls at gmail.com (Christoph A.) Date: Wed, 25 Aug 2010 20:58:03 +0200 Subject: [OTR-users] mpOTR question: denAKE() and deniability in front of J Message-ID: <4C7567BB.3010100@gmail.com> Hi, I'm studying the mpOTR design and would have some questions regarding algorithm 4 and some other questions regarding chapter 3.2.3 of the paper: http://www.cypherpunks.ca/~iang/pubs/mpotr.pdf - Is denAKE(A,B) equal or similar to the OTR protocol? (if that is not the case where can I find more information about denAKE) - Is k the encryption key and km the key for the MAC? - If that is the case, why is km in line 4 (Send(B, SymEnc(Sign())..)) used if there is no MAC (just SymEnc)? Regarding the deniability in the case where a judge forces participants of a chat session (c1) to disclose their long term private keys: From chapter 3.2.3: " Our privacy requirement is stronger than the settings presented in [11, 12] because J must not be able to distinguish between Alice?s transcripts and forgeries even if J gets Alice?s long-term secrets. " later on: " We accept that users cannot convincingly deny their static secrets in order to achieve a less compli- cated protocol. The users can still deny taking part in any fixed chatroom and the content of messages that they sent. " My question: Is this last sentence true, even if a judge gets the long-term keys of all participants of a given chat session, or was the requirement in chapter 3.2.3 sacrified for a "less complicated" design? I found some slides of talk at CCS: http://goliath.cs.ucdavis.edu/~matt/pubs/mpotr-ccs09/mpotr-ccs09-slides.pdf Does someone know if this talk is available somewhere? kind regards, Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From michaelhoofd at yahoo.com Wed Aug 25 15:10:13 2010 From: michaelhoofd at yahoo.com (Michael Hoofdburg) Date: Wed, 25 Aug 2010 12:10:13 -0700 (PDT) Subject: [OTR-users] pidgin-otr plugin on N900 : invalid length error In-Reply-To: <20100823120703.GA30106@thunk.cs.uwaterloo.ca> Message-ID: <565945.74944.qm@web120203.mail.ne1.yahoo.com> Hi,? As I understand the guy who packaged it for the n900 stopped.http://wiki.maemo.org/User:Jebba The versions for the OTR package for the N900:http://maemo.org/packages/view/pidgin-otr/ __Version Changes Author Date 3.2.0-8 * Don't optify: echo none > debian/optify Appears to break libs: http://lists.maemo.org/pipermail/maemo-developers/2010-January/023443.html ___Off-the-Record Messaging plugin for pidgin Off-the-Record (OTR) Messaging plugin for pidgin OTR allows you to have private conversations over IM by providing: - Encryption - No one else can read your instant messages. - Authentication - You are assured the correspondent is who you think it is. - Deniability - The messages you send do _not_ have digital signatures that are checkable by a third party. Anyone can forge messages after a conversation to make them look like they came from you. However, _during_ a conversation, your correspondent is assured the messages he sees are authentic and unmodified. - Perfect forward secrecy - If you lose control of your private keys, no previous conversation is compromised. This is a pidgin plugin which implements Off-the-Record (OTR) Messaging. Section: user/network Repository: Fremantle Extras-devel free armel Maintainers: Jeff Moe Uploaded by: Jeff Moe Depends: Size: 0 bytes MD5sum: File: Source: pidgin-otr 3.2.0-6 Status: Old version cleaned by repository management Bugtracker: ___ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at cypherpunks.ca Wed Aug 25 17:17:25 2010 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 25 Aug 2010 17:17:25 -0400 Subject: [OTR-users] pidgin-otr plugin on N900 : invalid length error In-Reply-To: <565945.74944.qm@web120203.mail.ne1.yahoo.com> References: <20100823120703.GA30106@thunk.cs.uwaterloo.ca> <565945.74944.qm@web120203.mail.ne1.yahoo.com> Message-ID: <20100825211725.GT24134@yoink.cs.uwaterloo.ca> On Wed, Aug 25, 2010 at 12:10:13PM -0700, Michael Hoofdburg wrote: > Hi,? > As I understand the guy who packaged it for the n900 stopped.http://wiki.maemo.org/User:Jebba > > The versions for the OTR package for the N900:http://maemo.org/packages/view/pidgin-otr/ > __Version Changes Author Date > 3.2.0-8 * Don't optify: > > echo none > debian/optify > > Appears to break libs: > > http://lists.maemo.org/pipermail/maemo-developers/2010-January/023443.html I don't know what "optify" is supposed to do; is it a maemo thing? But you seemed to indicate that the plugin *was* installable, but just didn't work. The above message appears to say the package isn't even buildable correctly? In any event, I have no knowledge of maemo stuff. Someone needs to follow up with that Jeff Moe person and/or the Maemo devs, I think. - Ian From ian at cypherpunks.ca Wed Aug 25 17:26:22 2010 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 25 Aug 2010 17:26:22 -0400 Subject: [OTR-users] mpOTR question: denAKE() and deniability in front of J In-Reply-To: <4C7567BB.3010100@gmail.com> References: <4C7567BB.3010100@gmail.com> Message-ID: <20100825212622.GU24134@yoink.cs.uwaterloo.ca> On Wed, Aug 25, 2010 at 08:58:03PM +0200, Christoph A. wrote: > Hi, > > I'm studying the mpOTR design and would have some questions regarding > algorithm 4 and some other questions regarding chapter 3.2.3 of the paper: > http://www.cypherpunks.ca/~iang/pubs/mpotr.pdf > > - Is denAKE(A,B) equal or similar to the OTR protocol? (if that is not > the case where can I find more information about denAKE) It's reference [7] (see p. 8, col. 2, par. 3). > - Is k the encryption key and km the key for the MAC? Yes. > - If that is the case, why is km in line 4 (Send(B, SymEnc(Sign())..)) > used if there is no MAC (just SymEnc)? Fair enough; km just gets ignored by that function, I suppose. > Regarding the deniability in the case where a > judge forces participants of a chat session (c1) to disclose their long > term private keys: > > From chapter 3.2.3: > " > Our privacy requirement is stronger than the settings presented in [11, > 12] because J must not be able to distinguish between Alice?s > transcripts and forgeries even if J gets Alice?s long-term secrets. > " > > later on: > " > We accept that users cannot convincingly > deny their static secrets in order to achieve a less compli- > cated protocol. The users can still deny taking part in any > fixed chatroom and the content of messages that they sent. > " > > My question: > Is this last sentence true, even if a judge gets the long-term keys of > all participants of a given chat session, or was the requirement in > chapter 3.2.3 sacrified for a "less complicated" design? Yes, the last sentence is still true. Even if all private keys are revealed to a judge, the judge should not be able to distinguish a real transcript from a fake one. Participants *cannot* deny that those were their actual private keys, though. So the keys are not deniable, but the messages and the participation are. > I found some slides of talk at CCS: > http://goliath.cs.ucdavis.edu/~matt/pubs/mpotr-ccs09/mpotr-ccs09-slides.pdf > Does someone know if this talk is available somewhere? That *is* the talk. Or do you mean a video of it? I don't know if the talks were recorded. Matt, do you remember? - Ian From casmls at gmail.com Wed Aug 25 19:23:31 2010 From: casmls at gmail.com (Christoph A.) Date: Thu, 26 Aug 2010 01:23:31 +0200 Subject: [OTR-users] mpOTR question: denAKE() and deniability in front of J In-Reply-To: <20100825212622.GU24134@yoink.cs.uwaterloo.ca> References: <4C7567BB.3010100@gmail.com> <20100825212622.GU24134@yoink.cs.uwaterloo.ca> Message-ID: <4C75A5F3.4080500@gmail.com> Hi Ian, thank you for your fast reply! On 08/25/2010 11:26 PM, Ian Goldberg wrote: >> - Is denAKE(A,B) equal or similar to the OTR protocol? (if that is not >> the case where can I find more information about denAKE) > > It's reference [7] (see p. 8, col. 2, par. 3). I think there is a small error in the reference: Reference [7] as in http://www.cypherpunks.ca/~iang/pubs/mpotr.pdf " [7] C. Boyd, W. Mao, and K. G. Paterson. *Key Agreement Using Statically Keyed Authenticators*. In B. Christianson, B. Crispo, J. A. Malcolm, and M. Roe, editors, Security Protocols, 11th International Workshop, Revised Selected Papers, volume 3364 of LNCS, pages 255?271, Berlin, Germany, 2005. Springer Verlag. " The surrounding information (mainly year of publication, volume number, page-range) and the topic tells me that you meant actually the following paper - which was published in 2005 and is on page 255-271 of LNCS volume 3364: "Deniable authenticated key establishment for Internet protocols" full reference: C. Boyd, W. Mao and K.G. Paterson, Deniable authenticated key establishment for Internet protocols. In B. Christianson, B. Crispo, J.A. Malcolm, M. Roe (eds.), Security Protocols, 11th International Workshop, Revised Selected Papers. Lecture Notes in Computer Science Vol. 3364, pp. 255-271, Springer, 2005. PDF file: http://www.isg.rhul.ac.uk/%7Ekp/deniableauth.pdf "Key agreement using statically keyed authenticators" was authored by the same authors - maybe that was the trigger. PDF file: http://www.isg.rhul.ac.uk/%7Ekp/static.pdf To cross check: http://www.isg.rhul.ac.uk/~kp/ (scroll down to year 2005/2004) Regarding denAKE() I'll also have a look at http://portal.acm.org/citation.cfm?id=1180454 (ref. nr. 11) as the slides nr. 33+74 are also pointing at it. > Yes, the last sentence is still true. Even if all private keys are > revealed to a judge, the judge should not be able to distinguish a real > transcript from a fake one. Participants *cannot* deny that those were > their actual private keys, though. So the keys are not deniable, but > the messages and the participation are. Thank you for the clearification. >> I found some slides of talk at CCS: >> http://goliath.cs.ucdavis.edu/~matt/pubs/mpotr-ccs09/mpotr-ccs09-slides.pdf >> Does someone know if this talk is available somewhere? > > That *is* the talk. Or do you mean a video of it? I don't know if the > talks were recorded. Yes, I meant video or voice recordings. kind regards, Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From mdvangundy at ucdavis.edu Wed Aug 25 19:45:41 2010 From: mdvangundy at ucdavis.edu (Matthew Van Gundy) Date: Wed, 25 Aug 2010 16:45:41 -0700 Subject: [OTR-users] mpOTR question: denAKE() and deniability in front of J In-Reply-To: <20100825212622.GU24134@yoink.cs.uwaterloo.ca> References: <4C7567BB.3010100@gmail.com> <20100825212622.GU24134@yoink.cs.uwaterloo.ca> Message-ID: <4C75AB25.9040005@ucdavis.edu> Ian Goldberg wrote: >> - If that is the case, why is km in line 4 (Send(B, SymEnc(Sign())..)) >> used if there is no MAC (just SymEnc)? > > Fair enough; km just gets ignored by that function, I suppose. Apparently that's a typo. SymEnc() and SymDec() should be *authenticated* symmetric encryption and decryption primitives but apparently their definitions were lost in an edit and one instance was changed to SymMacEnc() (see line 2). For simplicity, replace instances of SymEnc() and SymDec() in Algorithm 4 with SymMacEnc() and SymMacDec(). >> I found some slides of talk at CCS: >> http://goliath.cs.ucdavis.edu/~matt/pubs/mpotr-ccs09/mpotr-ccs09-slides.pdf >> Does someone know if this talk is available somewhere? > > That *is* the talk. Or do you mean a video of it? I don't know if the > talks were recorded. Matt, do you remember? I don't believe that the talks were recorded (though if someone surreptitiously made a recording of my talk, I'd love a copy). Cheers, Matt From mdvangundy at ucdavis.edu Wed Aug 25 19:55:44 2010 From: mdvangundy at ucdavis.edu (Matthew Van Gundy) Date: Wed, 25 Aug 2010 16:55:44 -0700 Subject: [OTR-users] mpOTR question: denAKE() and deniability in front of J In-Reply-To: <4C75A5F3.4080500@gmail.com> References: <4C7567BB.3010100@gmail.com> <20100825212622.GU24134@yoink.cs.uwaterloo.ca> <4C75A5F3.4080500@gmail.com> Message-ID: <4C75AD80.50006@ucdavis.edu> Christoph A. wrote: > The surrounding information (mainly year of publication, volume number, > page-range) and the topic tells me that you meant actually the following > paper - which was published in 2005 and is on page 255-271 of LNCS > volume 3364: > > "Deniable authenticated key establishment for Internet protocols" You are correct. See section 3 of that paper, in particular. I see I have some updates to make to my errata page. Cheers, Matt From wjbaird at alumni.uwaterloo.ca Fri Aug 27 09:48:32 2010 From: wjbaird at alumni.uwaterloo.ca (Warren Baird) Date: Fri, 27 Aug 2010 09:48:32 -0400 Subject: [OTR-users] pidgin-otr plugin on N900 : invalid length error In-Reply-To: <20100825211725.GT24134@yoink.cs.uwaterloo.ca> References: <20100823120703.GA30106@thunk.cs.uwaterloo.ca> <565945.74944.qm@web120203.mail.ne1.yahoo.com> <20100825211725.GT24134@yoink.cs.uwaterloo.ca> Message-ID: On Wed, Aug 25, 2010 at 5:17 PM, Ian Goldberg wrote: > I don't know what "optify" is supposed to do; is it a maemo thing? ?But > you seemed to indicate that the plugin *was* installable, but just > didn't work. ?The above message appears to say the package isn't even > buildable correctly? the N900 has very limited space in /usr - so properly built packages for it put everything in /opt, and then create symlinks into /usr - a process they call 'optification'. I believe you are right that the package isn't buildable. > > In any event, I have no knowledge of maemo stuff. ?Someone needs to > follow up with that Jeff Moe person and/or the Maemo devs, I think. I haven't tried done any real dev for the N900, but I can take a look this weekend... I do have pigdin on it, but only use it for IRC normally... Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca From casmls at gmail.com Fri Aug 27 11:37:08 2010 From: casmls at gmail.com (Christoph A.) Date: Fri, 27 Aug 2010 17:37:08 +0200 Subject: [OTR-users] mpOTR: detecting manipulations to the random contributions of SessionID() Message-ID: <4C77DBA4.5010303@gmail.com> Hi, I would have another question regarding which function detects manipulations of the random contributions to generate the unique session id (sid), and if it is necessary that Attest() checks for manipulations of the sid. http://www.cypherpunks.ca/~iang/pubs/mpotr.pdf chapter 4.2 " If the adversary has manipulated the random contributions (x), it will be detected during the Attest() algorithm executed at the end of Initiate() when sidi and any other unauthenticated parameters paramsi are authenticated. " A manipulation of x would result in differing sids - assuming H() is collision resistant. Alice would generate sid, while B generates sid' (sid!=sid'). If sids are differing, AuthUser() will fail. If AuthUser() fails the session initiation is aborted before reaching Attest(). Isn't it the case that the random contributions (x) are therefore indirectly authenticated by DSKE()/AuthUser() and not by Attest()? If you can not reach Attest() if one of the random contributions was manipulated you may omit the verification of sid within Attest(). But unfortunately this doesn't give you any benefit as I guess the calculation of H(params) will not be faster then H(sid, params), because the sid is only 256 bit long(?). kind regards, Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From casmls at gmail.com Sun Aug 29 16:32:44 2010 From: casmls at gmail.com (Christoph A.) Date: Sun, 29 Aug 2010 22:32:44 +0200 Subject: [OTR-users] mpOTR: replay attacks from insiders Message-ID: <4C7AC3EC.6000202@gmail.com> Hi, sorry to bother you again with mpOTR stuff, let me know if there is a better place to discuss mpOTR related questions. http://www.cypherpunks.ca/~iang/pubs/mpotr.pdf Example: Alice's view of a chat session: 1 Charlie: Alice, go ahead ask your questions. 2 Alice: Do you like ice [y/n]? 3 Bob: y 4 Alice: Do you like soccer [y/n]? 5 Bob: y Line 5: Bob actually doesn't like soccer and answered with 'n' but Charlie dropped that message and replayed Bob's message from line 3 instead. For Alice line 5 looks ok because Bob's signature was successfully validated. If I understand AuthSend() - defined in algorithm 5 - correctly, it does not contain any counter that would prevent such a replay attack. Is that correct or did I miss something that prevents already such an attack? (beside the consensus check in shutdown()) kind regards, Christoph -- A per participant message counter included in sign() could prevent such a replay attack from an insider. e.g.: o = sign(sid, C, msgctr) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From gmaxwell at gmail.com Sun Aug 29 16:46:11 2010 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Sun, 29 Aug 2010 16:46:11 -0400 Subject: [OTR-users] mpOTR: replay attacks from insiders In-Reply-To: <4C7AC3EC.6000202@gmail.com> References: <4C7AC3EC.6000202@gmail.com> Message-ID: On Sun, Aug 29, 2010 at 4:32 PM, Christoph A. wrote: [snip] > If I understand AuthSend() - defined in algorithm 5 - correctly, it does > not contain any counter that would prevent such a replay attack. > Is that correct or did I miss something that prevents already such an > attack? (beside the consensus check in shutdown()) I initially replied "The consensus check" but then saw you mentioned that. I'm not an mpOTR designer, so perhaps there is some other protection there that I'm missing... But this was how I understood the operation of the protocol. Do you think that the consensus check is inadequate? From casmls at gmail.com Sun Aug 29 18:04:59 2010 From: casmls at gmail.com (Christoph A.) Date: Mon, 30 Aug 2010 00:04:59 +0200 Subject: [OTR-users] mpOTR: replay attacks from insiders In-Reply-To: References: <4C7AC3EC.6000202@gmail.com> Message-ID: <4C7AD98B.1050503@gmail.com> On 08/29/2010 10:46 PM, Gregory Maxwell wrote: >> If I understand AuthSend() - defined in algorithm 5 - correctly, it does >> not contain any counter that would prevent such a replay attack. >> Is that correct or did I miss something that prevents already such an >> attack? (beside the consensus check in shutdown()) > > > I initially replied "The consensus check" but then saw you mentioned that. > > I'm not an mpOTR designer, so perhaps there is some other protection > there that I'm missing... But this was how I understood the operation > of the protocol. Do you think that the consensus check is inadequate? A replay-proof signature would prevent the attack from happening/succeeding in the first place. Alice would refuse to accept the signature in line 5. The consensus check detects it after the fact at the end of the chat session, therefore I think I would prefer the first solution. I would be surprised that such a replay attack is possible (which is not confirmed yet) because including a counter in sign() would defeat the attack. To be honest I also have a question regarding the consensus that is somehow connected to the replay scenario: Alice view: 1 Alice: Does it rain? 2 Bob: yes 3 Alice: really? 4 Bob: no Bob's view of the same chat room: 1 Alice: Does it rain? 2 Bob: no 3 Alice: really? 4 Bob: yes Charlie's view 1 Alice: Does it rain? 2 Alice: really? 3 Bob: no 4 Bob: yes Consensus checklist: - same set of participants -> ok - same sid -> ok - same set of messages -> ok - each message origin -> ok consensus reached? From chapter 4.4: "To ensure that out-of-order message delivery does not affect this digest, the messages are taken in lexical order. Note however, that should messages include a suitable order fingerprint, the lexical order coincides with delivery and creation order, hence our ordering is not restrictive." The remaining question is: Which order fingerprint is chosen? kind regards, Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From bustaoglu at cryptolounge.net Sun Aug 29 21:23:58 2010 From: bustaoglu at cryptolounge.net (Berkant Ustaoglu) Date: Sun, 29 Aug 2010 21:23:58 -0400 Subject: [OTR-users] mpOTR: replay attacks from insiders In-Reply-To: <4C7AD98B.1050503@gmail.com> References: <4C7AC3EC.6000202@gmail.com> <4C7AD98B.1050503@gmail.com> Message-ID: <20100829212358.mf6jn9ckw048gsgk@mathgrad.net> Hi, This is one of the many directions we were not able to complete due to space and time restrictions. The examples you suggest are quite descriptive of the problems that can arise. You should consider the consensus as something vital for any implementation: we have not offered a concrete solution, but emphasized consensus importance for mpOTR and that security as in encryption, macs and signatures do not necessarily imply consensus. A more personal answer regarding your question "Which order fingerprint is chosen?". OTR I think is satisfying a quite a few folks. So when two parties are concerned as in your example mpOTR should at least provide OTR result. The interesting part to design/decide is when you have Charlie contributing to the messages. KleeQ (reference [18]) has some worthy things to add on the issue. I think relative counters must somehow be used. Alice has a counter she increases with every message, but also uses Bob's and Charlie's counters to indicate what she thinks she responds to. So Alice won't accept a replayed message (counter is part of the message) from Bob because Bob's counter will say "I'm responding to your first question.". However, the feasibility of that approach is somewhat questionable since counters may get the message length a bit too long. Your otr-user list alternative is to send us directly your questions and comments. Best Berkant Quoting "Christoph A." : > On 08/29/2010 10:46 PM, Gregory Maxwell wrote: >>> If I understand AuthSend() - defined in algorithm 5 - correctly, it does >>> not contain any counter that would prevent such a replay attack. >>> Is that correct or did I miss something that prevents already such an >>> attack? (beside the consensus check in shutdown()) >> >> >> I initially replied "The consensus check" but then saw you mentioned that. >> >> I'm not an mpOTR designer, so perhaps there is some other protection >> there that I'm missing... But this was how I understood the operation >> of the protocol. Do you think that the consensus check is inadequate? > > A replay-proof signature would prevent the attack from > happening/succeeding in the first place. > Alice would refuse to accept the signature in line 5. > The consensus check detects it after the fact at the end of the chat > session, therefore I think I would prefer the first solution. > > I would be surprised that such a replay attack is possible (which is not > confirmed yet) because including a counter in sign() would defeat the > attack. > > To be honest I also have a question regarding the consensus that is > somehow connected to the replay scenario: > > Alice view: > > 1 Alice: Does it rain? > 2 Bob: yes > 3 Alice: really? > 4 Bob: no > > Bob's view of the same chat room: > > 1 Alice: Does it rain? > 2 Bob: no > 3 Alice: really? > 4 Bob: yes > > Charlie's view > > 1 Alice: Does it rain? > 2 Alice: really? > 3 Bob: no > 4 Bob: yes > > Consensus checklist: > - same set of participants -> ok > - same sid -> ok > - same set of messages -> ok > - each message origin -> ok > > consensus reached? > > From chapter 4.4: > "To ensure that out-of-order message delivery does not affect this > digest, the messages are taken in lexical order. Note however, that > should messages include a suitable order fingerprint, the lexical order > coincides with delivery and creation order, hence our ordering is not > restrictive." > > The remaining question is: Which order fingerprint is chosen? > > kind regards, > Christoph > > -- Berkant Ustaoglu http://cryptolounge.net From casmls at gmail.com Mon Aug 30 11:48:47 2010 From: casmls at gmail.com (Christoph A.) Date: Mon, 30 Aug 2010 17:48:47 +0200 Subject: [OTR-users] mpOTR: replay attacks from insiders In-Reply-To: <20100829212358.mf6jn9ckw048gsgk@mathgrad.net> References: <4C7AC3EC.6000202@gmail.com> <4C7AD98B.1050503@gmail.com> <20100829212358.mf6jn9ckw048gsgk@mathgrad.net> Message-ID: <4C7BD2DF.2010004@gmail.com> On 08/30/2010 03:23 AM, Berkant Ustaoglu wrote: > Hi, > > This is one of the many directions we were not able to complete due to > space and time restrictions. The examples you suggest are quite > descriptive of the problems that can arise. You should consider the > consensus as something vital for any implementation: we have not offered > a concrete solution So the details of the mpOTR protocol are not fully defined yet and therefore detailed questions* and analyses should take place after Matt completed the implementation[1] ? *) e.g: "Is sign() replay-proof or not?" [1] http://lists.cypherpunks.ca/pipermail/otr-users/2010-June/001823.html > Your otr-user list alternative is to send us directly your questions and > comments. Thank you for your offer! kind regards, Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From casmls at gmail.com Mon Aug 30 11:52:40 2010 From: casmls at gmail.com (Christoph A.) Date: Mon, 30 Aug 2010 17:52:40 +0200 Subject: [OTR-users] Reasonably secure conference / chat rooms now? In-Reply-To: <4C1FCF75.2080107@ucdavis.edu> References: <4C1FCF75.2080107@ucdavis.edu> Message-ID: <4C7BD3C8.3010904@gmail.com> On 06/21/2010 10:45 PM, Matthew Van Gundy wrote: > Gregory Maxwell wrote: >>>> Does anyone know of a way, using OTR related or other protocols, to do >>>> reasonably secure multi-party chat? >>>> I found the mpOTR paper - http://www.cypherpunks.ca/~iang/pubs/mpotr.pdf - >>>> but could not find any software that implements the protocol. > > The cryptographic protocols we presented in that paper makes certain > assumptions about the underlying communication medium. I'm finishing > work on the underlying protocol over this summer. Could you elaborate on 'certain assumptions about the underlying communication medium' if they contain more then Broadcast() and Send() as defined in chapter 4.1? Are these assumptions somehow requirements to the underlying IM protocol or will mpOTR implement them on top of the underlying IM? kind regards, Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From mdvangundy at ucdavis.edu Mon Aug 30 12:40:08 2010 From: mdvangundy at ucdavis.edu (Matthew Van Gundy) Date: Mon, 30 Aug 2010 09:40:08 -0700 Subject: [OTR-users] mpOTR: replay attacks from insiders In-Reply-To: <4C7AD98B.1050503@gmail.com> References: <4C7AC3EC.6000202@gmail.com> <4C7AD98B.1050503@gmail.com> Message-ID: <4C7BDEE8.7070108@ucdavis.edu> On 8/29/10 3:04 PM, Christoph A. wrote: > On 08/29/2010 10:46 PM, Gregory Maxwell wrote: >>> If I understand AuthSend() - defined in algorithm 5 - correctly, it does >>> not contain any counter that would prevent such a replay attack. >>> Is that correct or did I miss something that prevents already such an >>> attack? (beside the consensus check in shutdown()) Your understanding of AuthSend() is correct. Due to space and time limitations, we left preventing consensus violations throughout the conversation to future work (which is now under submission). > A replay-proof signature would prevent the attack from > happening/succeeding in the first place. > Alice would refuse to accept the signature in line 5. > The consensus check detects it after the fact at the end of the chat > session, therefore I think I would prefer the first solution. > > I would be surprised that such a replay attack is possible (which is not > confirmed yet) because including a counter in sign() would defeat the > attack. We did not opt for either of these partial solutions because neither is sufficient to ensure our notion of consensus. Take, for example, the setting of a duplicitous adversary: Bob's view: 1 Charlie: Bob, please answer these questions. 2 Charlie Do you like ice [y/n]? 3 Bob: y 4 Charlie: Do you like hockey [y/n]? 5 Bob: y Alice's view: 1 Charlie: Bob, please answer these questions. 2 Charlie Do you like ice [y/n]? 3 Bob: y 4 Charlie: Do you like soccer [y/n]? 5 Bob: y Charlie has now convinced Alice that Bob likes soccer without forging a message from Bob. > To be honest I also have a question regarding the consensus that is > somehow connected to the replay scenario: > > Alice view: > > 1 Alice: Does it rain? > 2 Bob: yes > 3 Alice: really? > 4 Bob: no > > Bob's view of the same chat room: > > 1 Alice: Does it rain? > 2 Bob: no > 3 Alice: really? > 4 Bob: yes > > Charlie's view > > 1 Alice: Does it rain? > 2 Alice: really? > 3 Bob: no > 4 Bob: yes > > Consensus checklist: > - same set of participants -> ok > - same sid -> ok > - same set of messages -> ok > - each message origin -> ok > > consensus reached? > > From chapter 4.4: > "To ensure that out-of-order message delivery does not affect this > digest, the messages are taken in lexical order. Note however, that > should messages include a suitable order fingerprint, the lexical order > coincides with delivery and creation order, hence our ordering is not > restrictive." > > The remaining question is: Which order fingerprint is chosen? As Berkant mentioned, we left this open to discussion. In the protocol under submission, we have defined ordering as potential causality over the messages at the mpOTR API level (i.e. provided to AuthSend() or returned from AuthReceive()) at any honest participant. This also addresses the ordering issue you raised above. a -> b = a potentially caused b (or a sent or delivered by b's author before b was sent). Therefore, we have the following causal precedence relation: Alice: Does it rain? -> Bob: no Bob: no -> Alice: really? Alice: really? -> Bob: yes Honest participants deliver messages in causal order, ensuring that Alice, Bob, and Charlie have the same view of all messages that could have potentially influenced one another. They will all arrive at the following transcript: 1 Alice: Does it rain? 2 Bob: no 3 Alice: really? 4 Bob: yes This also avoids the need for a replay-proof signature. Incidently, is there a standard notion for replay-proof signatures that you are referring to? And, do they meet our criteria for transferability among conversation participants? Cheers, Matt From mdvangundy at ucdavis.edu Mon Aug 30 12:50:23 2010 From: mdvangundy at ucdavis.edu (Matthew Van Gundy) Date: Mon, 30 Aug 2010 09:50:23 -0700 Subject: [OTR-users] mpOTR: replay attacks from insiders In-Reply-To: <4C7BD2DF.2010004@gmail.com> References: <4C7AC3EC.6000202@gmail.com> <4C7AD98B.1050503@gmail.com> <20100829212358.mf6jn9ckw048gsgk@mathgrad.net> <4C7BD2DF.2010004@gmail.com> Message-ID: <4C7BE14F.5040005@ucdavis.edu> On 8/30/10 8:48 AM, Christoph A. wrote: > So the details of the mpOTR protocol are not fully defined yet and > therefore detailed questions* and analyses should take place after Matt > completed the implementation[1] ? As I mentioned in my previous email, a solution for ensuring consensus is currently under submission. It was the primary open problem that need to be addressed before we could provide a useful concrete implementation of mpOTR. With that in hand, I am working on implementing the protocol. I'm happy to field any questions/analysis you may have. >> Your otr-user list alternative is to send us directly your questions and >> comments. > > Thank you for your offer! I think posting questions to otr-users or, perhaps, otr-dev is useful because it gives others the benefit of learning from previous discussions. If the regular users of either list feel like the information is off-topic, perhaps we can set up another public list specifically for mpOTR discussion. Cheers, Matt From mdvangundy at ucdavis.edu Mon Aug 30 12:59:50 2010 From: mdvangundy at ucdavis.edu (Matthew Van Gundy) Date: Mon, 30 Aug 2010 09:59:50 -0700 Subject: [OTR-users] Reasonably secure conference / chat rooms now? In-Reply-To: <4C7BD3C8.3010904@gmail.com> References: <4C1FCF75.2080107@ucdavis.edu> <4C7BD3C8.3010904@gmail.com> Message-ID: <4C7BE386.5000208@ucdavis.edu> On 8/30/10 8:52 AM, Christoph A. wrote: > On 06/21/2010 10:45 PM, Matthew Van Gundy wrote: >> Gregory Maxwell wrote: >>>>> Does anyone know of a way, using OTR related or other protocols, to do >>>>> reasonably secure multi-party chat? >>>>> I found the mpOTR paper - http://www.cypherpunks.ca/~iang/pubs/mpotr.pdf - >>>>> but could not find any software that implements the protocol. >> >> The cryptographic protocols we presented in that paper makes certain >> assumptions about the underlying communication medium. I'm finishing >> work on the underlying protocol over this summer. > > Could you elaborate on 'certain assumptions about the underlying > communication medium' if they contain more then Broadcast() and Send() > as defined in chapter 4.1? > > Are these assumptions somehow requirements to the underlying IM protocol > or will mpOTR implement them on top of the underlying IM? Specifically, the incremental consensus mechanism that is currently under submission (foreshadowed in [1] page 10 paragraph 3): The consensus approach adopted above is very naive?--it does not attempt to remedy any consensus errors and it only determines if consensus has been reached at the very end of the chat session. This simple approach is adopted to allow a free choice of consensus-ensuring algorithms to be employed at the network layer. The network could provide totally ordered multicast or KleeQ-like algorithms optimized for the broadcast medium. Whatever approach is chosen, we can detect any violations of reliable delivery at the mpOTR level. ... Approaches which ensure consensus incrementally throughout the chat session are possible and useful. We have chosen the approach above for its clarity, but any implementation has room for improvement. Cheers, Matt [1] Ian Goldberg, Berkant Ustaoglu, Matthew Van Gundy, and Hao Chen. Multi-party Off-the-Record Messaging. In Proceedings of the Sixteenth ACM Conference on Computer and Communications Security (CCS), Chicago, IL, November 2009. From casmls at gmail.com Mon Aug 30 18:57:46 2010 From: casmls at gmail.com (Christoph A.) Date: Tue, 31 Aug 2010 00:57:46 +0200 Subject: [OTR-users] mpOTR: replay attacks from insiders In-Reply-To: <4C7BDEE8.7070108@ucdavis.edu> References: <4C7AC3EC.6000202@gmail.com> <4C7AD98B.1050503@gmail.com> <4C7BDEE8.7070108@ucdavis.edu> Message-ID: <4C7C376A.6010402@gmail.com> On 08/30/2010 06:40 PM, Matthew Van Gundy wrote: > Your understanding of AuthSend() is correct. Due to space and time > limitations, we left preventing consensus violations throughout the > conversation to future work (which is now under submission). Great, that was the answer I was looking for. Will there be another paper or will this work just pop-up in a final mpOTR spec (something similar to http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html for OTR)? kind regards, Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: