[OTR-dev] the state on mpOTR?

[Ximin Luo]

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 messaging at mc.o 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20140328/20d2905a/attachment.pgp>