[OTR-dev] OTR version 4 Draft #2

Carsten Mattner carstenmattner at gmail.com
Fri May 11 10:49:37 EDT 2018


On 5/11/18, Ola Bini <list at olabini.se> wrote:

> Personally, I'm strongly against adding group chat to the core
> protocol - I think if and when a good group chat proposal exists, it
> should be separate. It would add too much complexity, in my point of
> view.

Group chat has still not been solved in a safe way, so I'd stay clear
of it, as well.

What I would love to see instead is similar cryptographically safe
improvements to Mumble. Sometimes I want to have a voice chat, and
given the options and what everyone else is comfortable to use, I
avoid voice chats as much as possible. There was ZRTP and then there's
Signal's voice chat, but Signal is Signal and I cannot use it for
multiple reasons anyway. And ZRTP isn't implemented widely. Of course
I could rely on SIP+SRTP, but that has its own problems. It's a shame
we're dealing with isolated centralized solutions users have happily
adopted in the meantime. And WebRTC is unreliable and buggy, too. I do
realize those things work to the satisfaction of some, no need to
discuss that. Some is not everyone or including those who care about
open and dependable solutions.

> There is another reason. It is _not_ an easy task for a plugin to
> support both v3 and v4 by calling directly into respesctive library.
> Since v3 and v4 functionality goes semideep into the state machines
> for the functionality, a plugin would need to duplicate a bunch of
> the state machine transitions before handing things over to the
> libraries, which I don't think is something we want.

I hear you, can you explain how this gets easier with the current
design of libotr-ng which links libotr-v3? I may have missed this from
past emails, sorry if I did.

> I don't know how valuable it is to push for goldilocks to be added
> to libsodium. I personally prefer _more_ smaller libraries, than
> _fewer_ larger libraries. And I'm personally not at all concerned
> with our number of dependencies at this point.

Cryptography has no way of dealing with a buggy implementation, so
instead of 5 different teams working on 5 or more libraries, I prefer
the concentration of skilled developers in 2 or 3 bigger libraries.
That means I do trust them to bundle only stuff they care about and
understand.

I understand your preference for many small libraries, but since those
are C libraries and not Rust, Go, Haskell packages, my experience
tells me to favor less libs in order to have higher reliability and
less issues with system wide installation and distro package
management.


More information about the OTR-dev mailing list