[OTR-dev] OTR version 4 Draft #2

[Carsten Mattner]

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.