On 27/03/14 20:46, Guy K. Kloss wrote: > >> Later this April we are organizing a summit here in Montreal to invite >> visiting cryptographers to review and comment on our first draft before we >> open it for public review. I see that you work for Mega — one of your >> colleagues (Ximin Luo) was already invited to this summit, so surely we >> haven’t been as “fishy” as you suggest, and I’m not sure why you seem to be >> complaining about a lack of involvement. > > Well, I didn't refer to "you" (not you personally or the group) as being > fishy, but the intransparency in which the project is conducted. > Coincidentally, I have heard about Ximin attending that meeting this > week, yes. But has there been any sort of information flowing to those > others who did reply to your mail on this list previously? I doubt so. > It seems a bit elitist that way, after calling out publicly for > participation. >
I haven't heard much news about other people's progress either. I assumed this is just due to oversight and lack of time, rather than intentionally being secretive - writing things for public consumption does take a bit of effort. But it's good to ping people to ask for news. My understanding is that there's a broader academic/developer community interested in mpOTR topics, and Nadim's group is just a part of it that happens to be more structured than the rest. I know of another group of researchers having a discussion on similar topics, but as I understand (from secondary sources) these have been fairly abstract, or concrete but with caveats that not everyone wants to adopt. I guess I could give a high-level update from myself too. I've completed a prototype python implementation of message partial ordering, for static groups. (The only primitive I need here is a strong hash, and I'm using truncated SHA256 for now.) This ensures transcript consistency, and simplifies replay attack protection. I also made some pretty graphs that show what a transcript looks like under different delay conditions[1], and in an IM scenario I'd imagine that most things look like "low-delay-*.png", i.e. nearly-linear. The next task is to extend this to dynamic groups. This involves more work than previously expected, but it looks feasible at the moment. One task was to define a merge algorithm over sets of chat participants, and I have a "proof by test cases" of its correctness, but have put off a mathematical proof for the time being. I don't know if anyone else is working on this problem. I posted a (probably too-) technical email on [email protected] a while back, and didn't get any direct replies. The Cryptocat blog post mentions it, but I'm concerned about the approach - I'm not sure what sort of notion of transcript consistency they have, that demotes message ordering to being a "secondary" concern. Another subtle point is that, like replay attack protection and key validation, transcript consistency is both a cryptographic and logistical problem - i.e. you won't be able to solve it simply by performing cryptography on the received data, but you need to (efficiently) compare results with the other parties. I'm also a bit slightly wary of the focus on a specification-first approach. There's nothing quite like trying to write the actual code, to see what issues you originally forgot to think of. I should practise writing shorter emails. ¬.¬ X [1] https://people.torproject.org/~infinity0/res/mpotr/ the drops in the "high delay" ones can be much improved with (even basic) re-send algorithms. This is not a major concern for IM-over-TCP, but would be useful for e.g. SMS. I've lost about 1/3 of mine in the past few months. -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
