[OTR-dev] Thinking about mpOTR and secure multiparty chat protocols in general
desnacked at riseup.net
Fri Mar 8 09:39:21 EST 2013
FWIW, I've partially answered some of my own questions. I'm replying
to myself with some extra information for completeness:
George Kadianakis <desnacked at riseup.net> writes:
> this is a post about mpOTR and secure multiparty chat protocols in
> general. I'm very interested in the secure multiparty chat problem,
> and I _really_ want to see it moving forward.
> * What about the tree-based transcript soundness idea that was
> discussed in FOCI '12? Is that also necessary in server-based chat
> frameworks (like XMPP and IRC), or only in decentralized
> environments? Is mPOTR centralized or decentralized after all?
On the topic of guaranteeing reliability and consistency in chat
transcripts, it seems that Matthew Van Gundy et al. have been
preparing a draft paper called "OldBlue: Causal Broadcast In A Mutally
which is a Causal Broadcast protocol that is supposed (I think) to fit
the needs of mpOTR.
> * Why do the primitives of mpOTR have to be pairwise between
> participants? This makes the protocol ugly and hard to scale. Aren't
> there ways to do group-key-exchanges in a
> fashion. I think there are fields of cryptography (like "Conference
> key distribution" and "Group key exchange") that deal with this kind
> of thing. Why are we not using them?
Matthew Van Gundy has been preparing a paper in this area too. His
paper "Improved Deniable Signature Key Exchange for mpOTR" proposes to
replace the suggested pairwise DSKE of mpOTR with a broadcast variant
like "Deniable Group Key Agreement" scheme of Jens-Matthias Bohli et
I think we shound also investigate whether we can replace other parts
of the suggested mpOTR protocol with broadcast variants.
> * Based on the previous question, how much do we want the protocol to
> scale? Do we want 5 people to be able to talk to each other, what
> about 40? What about 200 people or even 1000?
> * I will briefly mention deniability and the Fundamental Problem of
> Deniability (as presented in the mpOTR paper). It seems to me that
> deniability gives people a sense of security which might be
> completely useless in real life courts. It also complicates the
> protocol by an insane amount (Deniable Signature Key Exchange,
> complex shutdown phase, etc.).
> I know that some people here like the deniability property of mpOTR
> a lot, but personally I would be very happy with a multiparty chat
> protocol with end-to-end confidentiality, authentication and PFS,
> even if it didn't provide deniability in its first version.
> (FWIW, I like deniability and I would love to have a multiparty chat
> protocol that supported that property. Unfortunately, at the moment
> we have no multiparty chat protocols, and deniability is making
> their research and development even harder.)
> * Having cryptographers design the mpOTR protocol is great, but we
> will also need people who are experienced in thinking about chat
> protocols to evaluate whether our protocols are usable, deployable
> and scaleable.
> We should involve people from the XMPP and IETF community in this
> endeavor; they actually care about this problem, but they have many
> other things to care about and they are not cryptographers.
> * It's ridiculous how many edge-cases a simple chat protocol
> produces. Let alone a chat protocol with specific security
> properties. For example, 15 people talk in a conference, and
> suddenly an extra person gets invited. If the extra person is
> unknown to some people of the existing conference, do these people
> have to validate the fingerprint of the new guy? What happens if
> one of those people is AFK?
> Similar silly edge-cases really confuse me when I think about secure
> multiparty chat protocols. For this reason, I was thinking of
> writing a document similar to "Fallacies of Distributed Computing".
> It would be an article about assumptions that people take when they
> design chat protocols. For example, "all peers know each other
> beforehand", "all peers stay for the whole duration of the
> conversation", "all peers leave at the same time", etc. Maybe this
> way, it would be easier for people to reason about such edge-cases.
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
More information about the OTR-dev