[OTR-dev] Alternative messaging protocol
infinity0 at pwned.gg
Sun Jan 29 19:16:00 EST 2017
> 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.
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  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:
- 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.
- 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).
- 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.)
- 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.)
More information about the OTR-dev