├── .gitignore ├── README ├── mpOTR-discussions ├── 30c3_discussion.txt └── RWC2014_discussion.txt └── mpOTR-papers ├── LaTeX └── README ├── README ├── dissent.pdf └── mpotr.pdf /.gitignore: -------------------------------------------------------------------------------- 1 | papers/ 2 | -------------------------------------------------------------------------------- /README: -------------------------------------------------------------------------------- 1 | There have been several research papers to see how such a system would work, 2 | unfortunately, there hasn't been a fully fledged specification written. 3 | Together with various other researchers in the field, we aim to solve outstanding 4 | issues and solve them collaboratively. 5 | 6 | TODO: 7 | * Create our own research paper which can be reviewed by the community. 8 | * Create Threat-Model 9 | * Build Alpha library and client. 10 | * Profit \o/ 11 | * Fix attribution 12 | 13 | Communication channels: 14 | irc.oftc.net #otr #otr-dev 15 | 16 | Mailinglist: http://lists.cypherpunks.ca/mailman/listinfo/otr-dev 17 | -------------------------------------------------------------------------------- /mpOTR-discussions/30c3_discussion.txt: -------------------------------------------------------------------------------- 1 | mpOTR discussions at 30C3 2 | 3 | Deniability 4 | deniability - tricky in mpOTR - leads to less efficient protocol 5 | May be useful to develop a 'multiparty encrypted chat' spec without deniability that can come to existance faster 6 | OTR chat records have been used in court, and have been accepted as an evidence, so denyability does not always help.-> Quinn - deniability maybe not relevant in the real world 7 | 8 | Result: 2 specs possibly 9 | 10 | Resources 11 | https://github.com/cryptocat/mpOTR 12 | http://lists.crypto.cat/pipermail/mpotr-dev/ (cryptocat specific discussions) 13 | http://lists.cypherpunks.ca/pipermail/otr-dev/ (mpotr main mailing list) 14 | https://etherpad.mozilla.org/mpotrlol mpOTR brainstorming session from OHM2013 15 | 16 | Moxie's ratcheting: https://whispersystems.org/blog/advanced-ratcheting/ 17 | 18 | Key agreement 19 | The part of the MPOTR spec that isn't fully developed at this point is key exchange mostly, naive approach is O(n^2) 20 | 21 | 22 | Message order verifiability 23 | couldn't you include a hash of your own local chat history? -> key agreement and authentication is the focus of SMP >(channel verifiability is a separate issue) 24 | some solutions to ensuring consistent message ordering were discussed recently on otr-dev: 25 | modelling history as a DAG, like git commits, with consistency proofs on that data structure. that seems promising. "OldBlue: Causal Broadcast in a Mutually Suspicious Environment" by Gundy & Chen. 26 | The way to address the ordering problem is to sidestep it: you either elect one person and use their total ordering, or you use partial ordering. 27 | Google Spanner has an ordering mechanism based on clock synchronization, with ~10ms as their concurrency window, which might be good enough for human timescales 28 | 29 | Papers 30 | OldBlue: http://matt.singlethink.net/projects/mpotr/oldblue-draft.pdf 31 | Improved Deniable Signature for key exchange: http://matt.singlethink.net/projects/mpotr/improved-dske.pdf 32 | 33 | Threat model 34 | We need a simple description of the security properties and threat model. See paper: "Finite State Security Analysis" by Joseph Bonneau 35 | 36 | Next steps? 37 | 38 | Transport Requirements 39 | OTR is easy to implement in many protocols, e.g. Twitter, XMPP, proprietary chat messaging system; mpOTR is different because depending on how you spec, it might require individual messages to have key exchanges etc. Might be hard to map to IRC, XMPP group chat, Facebook messages, etc. 40 | 41 | Does it make sense to mpOTR spec that's transport agnostic? What would be needed to achieve that? 42 | 1-to-1 is easy because any comm protocol must support 1-to-1 43 | timestamps can't be consistent without a single central server 44 | you can get close, but you can't solve byzantine clock agreement 45 | google came out with spanner/truetime to do distributed ordering. might work at human time-scale even without well synchronized clocks. 46 | 47 | 48 | Ejection (Kickban) 49 | In any semipublic channel, you're eventually going to have to kick someone out. How do? 50 | Two models: 51 | Exclude someone from speaking in a conversation 52 | Make someone invisible without letting them know they've been excluded 53 | Ignore someone (don't encrypt for them)? 54 | Really hard if there's a single key for everyone, then you have to switch everyone to a new session key, complicated 55 | The ignore button has some problems, recently removed 56 | Legal experience: even when there is bad crypto, the way people have been getting caught is by a confederate. Infiltration is a much bigger problem than crypto right now; that will probably be true for a long time. Not having tools to enable social negotiation is a big problem. 57 | Isn't this the same as revokable broadcast encryption? There are schemes for blu-ray, tv broadcast that seem to do this. Worth looking into how they do it? 58 | How does kickbanning differ from a person leaving? 59 | Difference between kicking and leaving is that if you're kicked, you can't come back. 60 | You don't need a kick primitive; you can do it with just an invite primitive (invite everyone except one person). 61 | The problem for mpOTR is to renegotiate a key so that a person is excluded. 62 | Should also be done somehow when someone loses connectivity. 63 | Leaving and joining: 64 | Leaving is hard because we need to negotiate a new key 65 | What happens when someone joins late in a chat where a key has already been agreed? Instead of having one key, use that key to build a hashchain. When you agree to a key, use a hashchain, for each 1 second of wall clock time use an item in the chain, the new person gets the key for the second during which he joined. So he can move forward in the key order but not backward. 66 | Sounds a bit like Moxie's ratchet proposal? Hash-chaining is one way of moving forward without being able to go back. In Silent Circle, there is the SCIMP ratchet. TextSecure is doing work on a two-step DH ratchet. (google "moxie ratchet") 67 | Currently in OTR, Alice sends g^x to Bob and then the message. Upon responding, Bob acknowledges g^x and uses that when he responds afterward. For mpOTR do you need to acknowledge keys along the way? In OTR the other person can acknowledge when they respond, but for mpOTR does everyone have to respond with an acknowledgement? 68 | problem when people disconnected silently. That can DoS the whole conversation 69 | 70 | What are the use cases? 71 | 72 | How many participants do we think it should be able to handle to be useful? 73 | Use cases: 74 | 1. Conspiracy 75 | 2. Replace fucking IRC 76 | 3. A newsroom: potentially 100 users, imagine a news org being pursued by a private investigator or a corporation 77 | - It's a long-lived room, membership roster, will have key compromises so revocation is important 78 | - If it's an organization, they would trust their own server right? 79 | - But they tend to trust servers that are hosted not on their premises 80 | - I've seen news orgs e-mail the VPN password around... 81 | - Sometimes the social leak is not the main problem 82 | 83 | e.g. Chevron is trying to use US RICO laws against the people who are trying to make Chevron obey a court order. 84 | 85 | Migrating (client agility) 86 | 87 | What about clients that want to move from one system to another? E.g. talking on a phone, need to move to a computer. 88 | 89 | Usability note from observing people using OTR: 90 | When people run into a key management problem, they usually assume the client is broken. 91 | 92 | Possible solution: Have it out of the OTR spec. If a user starts a second client, he can transfer all the keys off-band. 93 | 94 | Gcouprie says: 95 | Would be useful to have an mpOTR voting system (e.g. voting to exclude someone) 96 | 97 | -Multiple people approve who can join? 98 | -Single channel owner? 99 | -automatic key renegotiation 100 | -kickban 101 | -power delegation 102 | - disconnection detection: some nodes may discover than other ones dropped out, and ask for a key renegotiation 103 | - One of the mistakes of IRC is that the channel owner needs to be more sophisticated than a regular user. Make the operations of a channel owner really simple and rudimentary, don't make it too complicated. 104 | Voting structures imply organizational structures (e.g. totalitarian, consensus, consensus minus one, etc.) 105 | those can be channel parameters (ie, needs approval from the three moderators, or majority, or unanimity, or whatever) 106 | It will always be useful for someone to be able to be a moderator. 107 | 108 | We love more features and options. But users just want it to go. Often, making simple decisions and forcing people into it is more merciful than giving them numerous options. 109 | 110 | As a protocol designer and from working products people use: it's often beneficial to keep as much flexibility as you reasonably can (not too much, or it will make implementations too hard!) in the spec, but don't prematurely constrain things in the spec; but then when you build the UX, pick one thing and do one thing well. Don't try to do everything that's offered in the spec in the UX. 111 | 112 | To handle ejection, you need to either have a voting system or a moderator. 113 | 114 | Specs influence social effects. A good spec might want to make relevant suggestions. 115 | 116 | Voting can also be implemented just by talking in the channel with a moderator or a bot. So maybe it doesn't need to be in the spec. 117 | 118 | Using Tor, you might have lots of issues. Netsplits are messy. Maybe with warnings, workarounds, but we need to accommodate the possibility of someone DoS attacking the channel. 119 | splits will happen. They are not an exception, and must be handled carefully. You cannot a priori detect if a split is just a network error, or malicious attack 120 | 121 | Participants on Twitter: 122 | @e_tews https://twitter.com/e_tews 123 | @kiserene 124 | @xnyhps 125 | @cwlcks https://twitter.com/cwlcks 126 | @gcouprie 127 | @FredericJacobs 128 | @willscott 129 | -------------------------------------------------------------------------------- /mpOTR-discussions/RWC2014_discussion.txt: -------------------------------------------------------------------------------- 1 | People present: 2 | Ben Laurie, 3 | Ian Goldberg, 4 | George Kadianakis, 5 | Nadim Kobeissi, 6 | Nadia Heninger, 7 | Tanja Lange, 8 | Joseph Bonneau 9 | Andy 10 | Moritz Bartl, 11 | Trevor Perrin, 12 | Daniel Gillmor, 13 | Clint Adams, 14 | Ximin Luo, 15 | 16 | Properties: 17 | 18 | How do we implement joins/leaves? 19 | 20 | ian: as discussed in '09 mpotr: whenever a join/leave occurs, it creates a new "room". participants choose to continue in old room or to move to new room. 21 | 22 | Drawing distinction between *protocol* properties and *ui* behaviors. For example when a room gains users, what happens if a client UI displays a new room memberhsip and one user disagrees/prohibits the change, what happens in the protocol? 23 | 24 | Ian: I want threading to exist in group chats. "In reference to that thing Andy said 10 lines ago" 25 | 26 | Nadim: implementing this "new member results in a new room and user has to agree" is a new UI paradigm, users don't have experience with this. Tanja compares to Skype, when a new user joins, existing users can decide to continue with the room or can decide to leave (and user has to make a decision before continuing the conversation). 27 | 28 | AGL: Threading might cause conversation forking, where some people get different content and some people get the same content (confusion) 29 | 30 | DKG: If the UI only gives you a choice when someone is joining, then...? The Invite problem: what happens when a new user is invited, but one of the existing users either declines or doesn't respond to the invite protocol. One option is to require users to participate in the protocol, and exclude them from the room [after some period] to prevent DoS by inaction/disconnect. 31 | 32 | Nadim: Adding invitation requirements to the room means someone can join and just refuse all invites, causing DoS. Kicking by vote can have similar problems 33 | 34 | Ian: If invitations have to be approved by everyone in the room for someone new to join, then you automatically support kicking. 35 | 36 | Ian disagrees with mpOTR being asynchronous, that it is not possible to do a useful protocol 37 | that is 38 | 39 | 40 | How do invites work? One option is to support "public" channels, "invite *". The invite model works as follows for private rooms: the people in the room unanimously decide to invite a new user. 41 | 42 | Question: can you do N-of-M or superusers/room-owners? 43 | A: possible, possibly, but not worth doing in this scenario. DKG suggests an attack on multiple outstanding invitations, where both Alice and Bob receive simultaneous invites. Alice accepts invite first and then prohibits Bob from joining. Ian has a countermeasure that I didn't catch. 44 | 45 | An alternative model is that any room member can generate an invite allowing a newuser to join; Ian strongly feels that this model isn't proper for mpotr. 46 | 47 | Nadim mentions the cryptocat model, where channels have a persistent identifier, and anyone who learns the identifier can join the room. Ian thinks this is pretty similar to the "invite *" model described above, wihch is a special case of the protocol Ian is suggesting. 48 | 49 | 50 | Quick digression into the group key agreement debate, curtailed for today. 51 | 52 | Ian: Do you have to be online right now to participate in the chat? Or can you go offline for an hour and then come back and catch up? If the session decryption key touches your disk, that's bad and can't happen. 53 | 54 | Ian talks about what he calls the "Asynchronicty" property --- do you have to be online and participating in the chat in order to receive the transcript? What happens if you are online for an hour, then go offline, spend one hour offline, and come back online? The scenario has several possible permutations -- is the client still interacting with the protocol; is the 55 | 56 | Ian: "when a client goes away, it's important that the client does not have a persistent handle to past conversations." If someone leaves the room (either by END message or by simply ceasing participation in the protocol) when do they lose the ability to decrypt encrypted messages to the room? 57 | 58 | Comparison to Pidgin+OTR current implementation, suppose a user goes offline, OTR messages can be queued and delivered later without requiring re-OTR. 59 | 60 | Context switch to use cases -- Nadia suggests that there are radically different use cases that require different protocols. Ian agrees that there may be multiple protocols for multiple use cases, and respectfully requests that protocols that do not provide 61 | * strong deniability 62 | * forward secrecy 63 | should not use the name "OTR". Andy mentions the (terrible) name "secure multiparty chat" smpchat, Nadia says "persistent something something" and comes up with an even worse acronym 64 | 65 | 66 | Daniel suggests that there should be a cutoff. So if you drop off for 10 minutes you need to rekey, but if you drop off only for 5 minutes you can rejoin and get the history and everything is fine. 67 | 68 | Joseph Bonneau is trying to identify two properties: it would be nice if every time a message is accepted by every member, there is a rekey, and once that is completed the message is "in the past" and cannot be decrypted by a new member. Alternatively suppose that a member is in the room but unreachable, the rachet cannot move forward until that member re-participates in the room. 69 | 70 | djb suggests it's possible to build a protocol where Tanja going through the tunnel (for 15 minutes) causes the messages to be continued to be decryptable by Tanja's key, but the rachet can move forward for every other (still online) member in the room. 71 | 72 | ian agrees you can rachet public keys, which avoids the N^2 communication requirement that Trevor raised as a challenge for the per-user-rachet suggestion. 73 | 74 | Tanja and Nadim: There could be a UI element to maintain the order of messages even if messages are delivered out of order. Ticks, green circles... usefulf for other parts of the UI too 75 | 76 | Ben Laurie asks if we can get proofs -- can we get a proof that Tanja, even though offline for part of the conversation, saw a complete correct transcript afterwards? 77 | 78 | 79 | ... 80 | 81 | 82 | Bottom line, Ian: Don't call it "OTR" if it doesn't provide deniability and forward secrecy. 83 | 84 | Nadia's proposal: "multiparty private interactive secret chat: mpPISS" 85 | 86 | Tanja's vague endorsement for "smpchat". 87 | 88 | ... and we're out of time. Resuming tomorrow I suspect. 89 | 90 | Potential talking points: 91 | 92 | Use-cases 93 | 94 | Size 95 | 96 | - between friends (~15, <50) 97 | - private small org (~30, <200) 98 | - large semi-public forum (~150, <3000) 99 | 100 | Form 101 | 102 | - asynchronous/high-latency, long-lasting sessions, low availiability 103 | - solving mpOTR for this scenario, seems to automatically solve it for the synchronous/low-latency scenario 104 | 105 | - maintain session state across devices 106 | - no-one seems to be doing this at the moment. a naive implementation could just treat the other device as a separate participant, but this does not fit well into XMPP's "resource" primitive 107 | 108 | Security properties 109 | 110 | Multiparty 111 | 112 | - message authenticity against other participants 113 | - transcript consistency across all participants 114 | - what level of consistency (how many missed messages is acceptable?) 115 | - robust join/leave and invite/kick algorithms 116 | 117 | Messaging 118 | 119 | - message confidentiality against network attacker 120 | - message authenticity against network attacker 121 | 122 | - forward secrecy = past message confidentiality against NA w/ current-secret-compromise on recipient(s) and/or transmitter 123 | - "future secrecy" = future message confidentiality against NA w/ current-secret-compromise on transmitter[1] 124 | - "deniability" = repudiability of ciphertext authenticity against NA w/ secret-compromise on recipient(s) 125 | 126 | Protocol 127 | 128 | - detect and recover dropped/reordered messages 129 | - detect and ignore replayed messages 130 | 131 | Info-theory 132 | 133 | - no information leakage against timing/length attacks 134 | 135 | -------------------------------------------------------------------------------- /mpOTR-papers/LaTeX/README: -------------------------------------------------------------------------------- 1 | Directory with our own research papers 2 | -------------------------------------------------------------------------------- /mpOTR-papers/README: -------------------------------------------------------------------------------- 1 | Papers will be published here for research purposes. Papers written by others and by us. 2 | -------------------------------------------------------------------------------- /mpOTR-papers/dissent.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DrWhax/mpOTR/314478d557dbdd028d08a94d70df7bb8bf4fb245/mpOTR-papers/dissent.pdf -------------------------------------------------------------------------------- /mpOTR-papers/mpotr.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DrWhax/mpOTR/314478d557dbdd028d08a94d70df7bb8bf4fb245/mpOTR-papers/mpotr.pdf --------------------------------------------------------------------------------