[OTR-dev] OTR version 4 Draft #2

[Ola Bini]

Hi,

I do want to add to some of these points!

> We don't have a clear path of when v5 is going to come, as we are
> dedicating the next months to finish all the implementation of v4 in C.
> Around ideas we have had for v5, we have thought of including a
> post-quantum algorithm if they are sufficiently stabled and implemented
> (in a production-ready way) by the time v5 comes. We will probably
> update some cryptographic primitives, if efficient ones are available by
> that time. And lastly, I hope that in that version we have a secure,
> efficient and good way of supporting group chat (but this needs a lot of
> work).
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.

The main reasons from an API standpoint is things like callbacks to
the plugins, how the DAKE is managed and a few other things - all
these we think will remain stable for the medium term future.

> > What do we gain by including v3 support in libotr-ng? Shouldn't we
> > remove it and avoid complexity? If a client wants to support v3 and
> > v4, and libotr-ng would link v3's lib, then why shouldn't the new code
> > path use libotr-ng for v4 only?
> 
> This is just to give implements and users time, as v3 is more
> implemented than v4. A client can have v4 implemented but is talking to
> a client that only has v3 implemented: the idea is that they can still
> talk with OTR. Yet, this same client will know how to work when a
> request from v4 or more comes.
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.

> > Since our last discussion here, I've come to the conclusion that
> > libotr-ng should really reduce its external dependencies and try to
> > find a single crypto primitives lib or bundle those that are written
> > in C or Go anyway. Their implementation doesn't change, and any change
> > in a crypto primitive is dubious and worthy of a lenghty code and
> > crypto review anyway.
> 
> Well, the libraries we have for crypto primitives per se are
> "libsodium-dev", "libgcrypt" and "libgoldilocks". The latter is just for
> the curve. Mmm... what can be pushed for this is including
> ed448-Goldilocks in libsodium
> (https://github.com/jedisct1/libsodium/issues/254). I don't know the
> state of this issue, though.. I'll ask around.
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.

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/9627c16f/attachment.sig>