[OTR-dev] OTR version 4 Draft #2

[Sofia]

Hey, Carsten

I think Ola will answer this too, but here are my thoughts:

> What are your ideas/plans for v5, and how do you envision the v4 API
> to support those? It sounds like you have a vague vision that would
> fit within v4's model.

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).

> 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.

> 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.

> As you mention the name of lib has been getting confusing, so why not
> take the opportunity to use a unique name, rather than libotr-ng?

We thought of this. But we wanted to follow the pattern of written
libraries by using 'lib' and then the name of the protocol. OTR is a
unique name anyway.

Thanks!

-- 
Sofía Celi (aka cherenkov)
@claucece / @cherenkov_d
EF74 1A5F 5692 E56F 14F6  243C 3992 6144 F89D 996F