[OTR-dev] OTR version 4 Draft #2

Carsten Mattner carstenmattner at gmail.com
Fri Mar 16 22:54:23 EDT 2018

On 3/17/18, Sofia <sofia at autonomia.digital> wrote:
> Hey!
> Thanks so much for looking at the library.
>> It says it depends on 'libotr 4.x'. I don't understand, isn't that
>> the project itself?
> That is actually libotr (often called libotr3) that implements OTRv3,
> whose library version is 4.

Yeah, I was expecting the work to be part of a future libotr release,
though it doesn't seem viable.

> Well, for libotr4 we also need the library of ed448, "Goldilocks"
> elliptic curve, which is not implemented in libsodium. It was
> implemented by Mike Hamburg here:
> https://sourceforge.net/p/ed448goldilocks/code/ci/master/tree/
> This library (libdecaf) is a multi-purpose elliptic curve library, so
> right now we are also working on a "pure" implementation of ed448
> elliptic curve, "Goldilocks".
> Libgcrypt is a library that libotr3 also depends upon, to use MPIs,
> for example. Libotr is included for backwards compatibility
> with OTRv3.

Like I wrote above, I was naively thinking it would be a branch of
libotr that implements a new protocol, while leaving the existing
code untouched or modified where needed.

I totally understand how the "multitude" (no negative meaning
implied) libs came to be dependencies. From experience with
open source projects, I'm certain this will raise eyebrows
and/or upset downstream, in addition to the uncertainty and
irregular reliability of pulling in many independently developed
libraries, especially if it's for crypto primitives we put
our trust in.

More information about the OTR-dev mailing list