[OTR-dev] OTR version 4 Draft #2

[Sofia]

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.

> I feel like libsodium-dev should be the only one a v4 libotr
> may depend on, if we consider the use DJB's crypto designs
> in place of OTRv3's past (reasonable) choices.

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.

This of course, can change ;)

> This isn't
> meant to diminish the work on v4 and meant as critique
> to consider as improvements.

Np. It is nice that people are looking at the library ;)




On 3/16/18 8:57 PM, Carsten Mattner wrote:
> On 3/16/18, Ola Bini <ola at olabini.se> wrote:
>> Hi Carsten,
>>
>> <snip>
>>
>>> I suppose (couldn't find it) that there is a libotr branch implementing
>>> the draft, right? This is very important if we want to upgrade pidgin,
>>> weechat, mcabber, jackline, adium, etc to OTRv4.
>>
>> You are completely right that having an implementation that offers a
>> similar API to libotr is incredibly important for adoption.
>>
>> You can find it here https://github.com/otrv4/libotrv4
>>
>> It's currently not anywhere near complete - we are planning on pushing
>> forward on that work now that I have a fairly stable version of the
>> specification.
> 
> It says it depends on 'libotr 4.x'. I don't understand, isn't that
> the project itself?
> 
> Thank you again for working on this and I wish it wouldn't add
> so many non-trivial library dependencies. The nice thing about
> libotr3 is that it is reliable because it's low on external
> dependencies.
> 
> From
> 
>     libglib2.0-dev
>     libdecaf
>     libsodium-dev
>     libotr 4.x
>     libgcrypt 1.8.0 or newer
> 
> I feel like libsodium-dev should be the only one a v4 libotr
> may depend on, if we consider the use DJB's crypto designs
> in place of OTRv3's past (reasonable) choices. This isn't
> meant to diminish the work on v4 and meant as critique
> to consider as improvements.
> 

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