[OTR-dev] Alternative messaging protocol

Ximin Luo infinity0 at pwned.gg
Sun Jan 29 19:16:00 EST 2017


Nik Unger:
> [..]
> 
> At the same time, criticisms of Open Whisper Systems' management of the
> Signal protocol and app suggest that there is room for an alternative,
> as long as it can compete in the same markets. This proposal does not
> appear to have been designed to do that (e.g., due to a requirement for
> synchronous communication, and compromises related to the need for
> OTRv3-style session initiation). I would prefer to see a design that
> provides an alternative to Signal. I would also like to see some
> discussion about this design direction on this list.
> 
> [..]

Hi Nik,

I'm glad that someone does recognise a need for this sort of thing.

In fact we got some funding recently from the German government's Prototype
Fund [1] to work on this very topic, continuing on from work that I had already
done in previous years that was funded by MEGA.

It would be great to have interested people help with this effort, but at this
stage I personally am too tired to continue debating on mailing lists about it.
I have been doing this for quite a few years, plus approaching various other
groups in private for funding or co-operation, and I don't think I have gotten
anything constructive out of those efforts.

Here is a summary on what we are building:

Compositional architecture

- Transport agnostic, can run over a server, a federated network of servers, or
  decentralised mixnet or other medium. We could in principle even do a single
  group chat with participants from several different transport networks, and
  any server(s) that exist do not have to know that the group exists.

- Does not leak application-specific metadata to the transport, e.g. whether
  you're doing a file transfer or sending picture vs text messages. This sort
  of stuff would be done in a separate layer *above* the messaging layer.

Asynchronous

- Non-blocking concurrent messages *and* membership operations; achieves this
  by modelling the session history as a partially-ordered hash graph.

- (Of course, can *also* work under synchronous settings).

End-to-end security:

- Confidential, and forward-secret.
- Authenticated, and deniably so: no "cryptographic proof" traces.
- Reliable, assurance that others saw your messages.
- Consistent, assurance that everyone sees the same thing.

End-to-end guaranteed delivery

- Automatic resending *by the client* until recipients confirmed received.
- (Works on top of any server reliability, which is opportunistic and
  practically useful but fundamentally cannot be end-to-end secure.)

Crypto details

- Pair-wise double ratchet, specifics are currently undecided. Actually I was
  hoping to be able to use the OTRv4 DAKE or something similar, but if this not
  suitable and there are patent issues with using the Signal ratchet then I'm
  fairly confident I can come up with a new one myself.

  The existing partial-order traversal algorithms should allow us to do this in
  (I estimate) about 15 lines of OCaml code, plus maybe 10-20 more lines for
  generic logic to delete keys. In other words, it will heavily use non-trivial
  utilities from other parts of the code, but we'd only have to change 15 lines
  to change "the ratchet algorithm".

Already you should be able to see some concrete and important long-term
advantages over Signal. If you or anyone else is interested *and* potentially
able to put in a significant amount of concrete work on it, I'd be happy to
talk much more about it over private email.

(Of course the end result will be FOSS, open, etc and all that good stuff.)

X

[1] https://prototypefund.de/en/our-first-round-of-funding-goes-to/

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git


More information about the OTR-dev mailing list