On Wed, Oct 23, 2013 at 8:26 AM, George Kadianakis <[email protected]> wrote: > 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.
I'm not sure what this actually means. Can we rephrase it to be more specific? The only protocols I know of that "should make me confident that I trust another participant" involve tweaking my body chemistry or neural function. Do you mean to say at the end of this phase, a participant has some session state (such as a shared pairwise secret) which is authenticated to another party's public key? Do you mean something else? > - 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 cheers, nejucomo _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
