Hi Ximin, On 22/01/14 15:28, Ximin Luo wrote: > Hey Guy, I think you missed the final pad from the last day: > > http://piratepad.net/GMplxYhLSA
Indeed. I suppose it's not easy to come by this information if one is not present at the conference ... thanks for mailing it through. > It's a list of issues that mpOTR / smpchat would need to address, > and potential ways of solving each issue. I missed this part of the > meeting, but I hear that the next step is to pick a subset of the > candidate-solutions that we should try to accomplish. Yes, I think the main issue is that people know what OTR is, and they want to "stretch out" the use case according to need. Unfortunately the use cases are not all compatible with all ideas on the wish list. It seems like particularly conflicting is the desire to stretch it into the direction of being able to handle asynchronisity (for the OTR as well as mpOTR case), which does not work well with e. g. key agreement and ephemeral keys. For these reasons, I guess it's first of all important to sub-select the boundary conditions for one (or several) usage scenarios. If certain mechanisms don't work for a scenario, then (optional) alternatives may need to be found, while maybe other mechanisms still work. As for my/ourselves, we've been looking at OTR (which has become a de-facto standard, much more than its alternatives), because it just did what it did, without trying to be the all satisfying solution (which is often the death of great ideas when taken to a consortium). So, the most important thing that *we* are looking at is just to do what the the existing OTR and the name of mpOTR imply: A system that can be used in synchronous mode to secure live group communication channels. As far as having had a look at the two extensive list of issues and discussions on the PiratePads, I must say that many of these issues may need a solution through policy, and not quite by protocol implementation (e. g. on who to join or kick, when is a user's session to be considered stale and the user will be removed from the group, etc.). So one may just go and start on several basic conceptual decisions that build on top of "what people know from OTR", and leave out other issues to be decided or worked on later. > Away from the overall mpOTR discussions, I spent a lot of time on > the side talking about forward-secrecy ratchets with Trevor. We also > talked about the advantages and disadvantages of a pair-based system. > (This is opposed to a group-based system that most others are > thinking about). We and some others think it would be worth pursuing > this further, with the understanding that this would not scale to > massive groups. Despite this, the advantages are: Personally, I'd take the position here on group-based systems ... > - strong security properties (inc. deniability) can be implemented > in a much simpler way > - there is individual control over group decisions like join/part/expiry > - the overhead can be made independent of the message size, so only > linear in the number of participants > - no need for complex key exchanges, easier to make work for the > high-latency case (inc. store-and-forward) I can see those advantages, but these are the immediate disadvantages I can see: * Key agreement, though easier conceptually, involves many more message exchanges. If everyone needs to exchange keys with everyone, we're in an O(n^2) situation. If we'd use (just for simplicity reason) a Group Diffie-Hellman key agreement, we're already in the O(n) range of message exchanges. And I believe that message exchange latencies can play a major role in a secure group chat protocol. * There's the need to ensure that all participants will receive *the same* message, when encrypted/signed for each participant individually. As for the first point, I've started working on a simple GDH implementation, which should be quite suitable for groups in the order of magnitude around 10 users, and getting more difficult around 100. To keep messages small and computational overhead small, I'm currently doing Curve25519-based scalar multiplication chains rather than classical DH exponentiation. As a logical progression from there Ed25519 ephemeral signatures would work well in this scenario as opposed to doing vanilla DSA or RSA. Having said that, I think it'd still be a good idea to keep using the long term DSA secret of OTR for the initial participant authentication. > Additionally, doing work in this area lets us explore issues like > transcript consistency and the expiry of participants in more depth, > without worrying too much about group key exchanges. The lessons > we'll learn will probably be useful for group-based approaches too. For sure! > To be clear, only a subset of people support this direction, but I > think it can lead to somewhere concrete much faster than a > fully-generalised mpOTR strategy will. Agreed. As I had indicated in an earlier mail, I'm also looking at an "evolutionary" approach, which will not do the full mpOTR monty off the bat, but start with group encryption first. > I've started writing up more technical notes but they're not ready > for public consumption yet. The general strategy is to extend a > ratchet that is aware of message partial-ordering to multiple parties, > then add a join/part/expiry protocol on top of this. Note, I'm not > just "going in blind", I have thought about the latter before already >, in a way that fits into a partial-ordering model. Really looking forward to that. > (I'd be happy to talk more technical details over IM; this email > address is also an XMPP address.) Just added you to my messenger. I'm [email protected]. Guy
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
