[OTR-dev] OTR version 4 Draft #2

[Ola Bini]

Hi,

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

> 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.
Yeah, I agree about all these points - we have internally discussed
both video and audio, and the many shortcomings with current
solutions. OTRv4 could be used for those kinds of solutions, just as
OTRv3 could (using the symmetric key, for example). But full solutions
would require a very different concept and project. Personally, the
authentication mechanisms used in ZRTP and SRTP are starting to feel
very scary, in the modern age of good enough voice faking etc.

> > 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.
Sorry, maybe I wasn't very clear about this. Basically, libotr-ng is
in charge of the full state-machine for OTR.

> 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 strongly disagree. No matter how skilled a developer is, a larger
library means more internal complexity, something that has been shown
increases the likelihood of bugs. I don't trust any developer, no
matter how skilled, to not make mistakes. =)

Cheers
-- 
 Ola Bini (https://olabini.se)

 "Yields falsehood when quined" yields falsehood when quined.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20180511/a6906d4e/attachment.sig>