Here are some more notes about mpOTR that I refreshed today. Here are some properties that the mpOTR protocol should have. These were also mentioned in the mpOTR paper:
- Confidentiality - Entity Autentication - Origin Authentication - Forward Secrecy - Deniability (Repudiation/Malleability) Do we want this? It would certainly be nice to have, but it makes things so much harder! - Transcript synchronisation - ... Here is a breakdown of an mpOTR session in phases: [Channel establishment] -> [Authentication] -> [Key exchange] -> [Communication phase] -> [Shutdown phase] At the moment, the [Authentication] and [Key exchange] phases are the ones that need the most attention from researchers. More details below. Phase breakdown: [Channel establishment] * Where a set of initial unauthenticated participants is selected and a channel between the participants is established. Notes: - I assume that the protocol is centralized since it makes everything much easier (I assume that broadcast happens by sending a broadcast msg to a server). We can decentralize later. Solutions: - Assuming an application-agnostic protocol, this can happen using IRC channels, or XMPP MUCs, or SIP or whatever. [Authentication] * Where participants authenticate each other and a set of authenticated participants is established. Notes: - At the end of this phase, each participant should be confident that he trusts all the other authenticated participants. - If deniability is in our goals, this handshake should happen in a deniable fashion. - A session ID etc. must be established somewhere around here too. Solutions: Possible solutions include: - "Improved Deniable Signature Key Exchange for mpOTR" by Matthew Van Gundy. Uses the scheme presented in "Deniable Group Key Agreement" by Bohli et al as a basis. The Bohli paper is not terribly well-cited. Also see http://lists.cypherpunks.ca/pipermail/otr-dev/2013-August/001815.html - Just-Vaudenay "Authenticated multi-party key agreement". Well-cited, but there are published attacks (key-compromise impersonation etc.) against the original protocol. The idea is kind of similar to the 2-party key exchange proposed by Trevor Perrin in: https://whispersystems.org/blog/simplifying-otr-deniability/ - The protocols mentioned by Matthew Van Gundy in: http://lists.cypherpunks.ca/pipermail/otr-dev/2013-March/001676.html - There are dozens more protocols that we haven't looked at. Which ones are worth reading? GDH.2 and GDH.3 by Steiner et al.? [Key exchange] * Where participants negotiate a shared key to be used for this conversation. Notes: - This phase will probably get merged with the "Authentication handshake" phase using a "Authenticated Group Key-Exchange protocol". - Ideally this handshake should be friendly towards dynamic groups, so that the computational damage of joins/parts is minimized (with a naive scheme, this handshake will need to be repeated everytime someone joins or leaves the channel). - This handshake should be cheap and ideally broadcast-based. Handshakes that work pairwise between participants are expensive and hard to scale. Solutions: - See the previous section for "Authenticated Group Key-Exchange" solutions. - Also see "Secure group communicaton using key graphs" and "Scalable Authenticated Tree Based Group Key. Exchange for Ad-Hoc Groups" for dynamic group key-exchange solutions. [Communication phase] * Where participants, using the derived keys, communicate with each other in an authenticated/confidential fashion. Notes: - A message format must be defined. Each message will need to be encrypted, authenticated, maybe even marked with a sequence number, etc. Also see the mpOTR paper for more stuff that we need to be aware of. - Furthermore, we need to ensure transcript correctness, that is, in real-time fashion each participant should be assured that she is seeing the same transcript as all the other participants. This is to avoid attacks like: """ [PoV of Alice] Bob: Do you like reggae music? Alice: Yes! Bob: Do you like metal music? Alice: No! [PoV of Bob] Bob: Do you like reggae music? Alice: No! Bob: Do you like metal music? Alice: Yes! """ To avoid this we will need to use some kind of causal delivery protocol. For example, "OldBlue: Causal Broadcast In A Mutually Suspicious Environment" by Matthew Van Gundy et al.? [Shutdown phase] * A shutdown phase might be needed in a deniable protocol so that parties expose their ephemeral keys etc. * A shutdown phase is needed in any case to memwipe all cryptographic material from memory. Notes: The mpOTR paper includes a Shutdown() algorithm. _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
