On 3/17/18, Sofia <[email protected]> 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. _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
