[OTR-dev] OTR version 4 Draft #2

[Ola Bini]

Hi Carsten,

I just wanted to add a few comments on what Sofi already said.

First, about libraries:

glib:
   This is really the only _significant_ dependency we are
   adding. However, it's not a runtime dependency, we only use glib
   for tests, so when installing using package managers etc, it will
   not be a dependency.

decaf:
  This is the current depenency that give us access to Ed448, which is
  the elliptic curve we are using for all operations. We opted for
  Ed448 instead of 25519, in order to increase the security level -
  and thus, sodium doesn't give us this curve.

sodium:
  Primarily, libsodium gives us xsalsa.
  
otr:
  See below for a longer explanation.

gcrypt:
  This dependency is primarily for the multi-precision integer
  library, MPIs.


As you can see, the decaf and sodium dependencies give us
cryptographic primitives that we need. In the same way, gcrypt give us
MPI's, which is also necessary for most of our implementation. In
theory, you could argue that these three libraries have significant
sizes, and adding them to OTR is problematic. We could in theory take
the pieces we need and put them directly into the OTR code base, but I
would argue that this wouldn't increase the security and reliability
of OTR, rather the other way around. Having smart people making sure
our XSalsa20 implementation is running fast on all architectures
instead of us having to do the work ourselves is quite nice.

The other way of looking at it, would be to say that OTR should only
use simple primitives that can be implemented inside the single
library, in the way the old libotr implements DH and DSA. However,
with todays threat landscape, that would restrict us to primitives
that are not well suited, OR, implementations that are not viable at
naive implementation speeds, in order to have a resonable security
level.


When it comes to libotr, vs the new libotrv4 (we are thinking about
changing the name, since it's confusing), we really had a few
different choices. Considering that OTRv4 comes with new primitives
and new capabilities, it would be close to impossible to keep the same
API as libotr without doing horrible things. Our choices were,
roughly:

- Ignore libotr and OTRv3 and backwards compatibility
- Subsume libotr, add OTRv4 functionality around the existing library
 and expose a new API, side-by-side with the OTRv3 API
- Create a separate OTRv4 implementation that ONLY does v4, but
delegates to the old libotr implementation for v3 functionality.

From our perspective, #1 was not viable, #2 would lead to a lot of
complexity, and potentially maintenance of a significant amount of
code that wasn't live most of the time anymore. Also, v3 and v4 have
significant differences, so there wouldn't be that much shared code
paths.

For us, #3 struck the right balance between user functionality and
maintenance ease for the developers.

Hope that helps!

Cheers
-- 
 Ola Bini (https://olabini.se)

 "Yields falsehood when quined" yields falsehood when quined.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20180318/60a69ce1/attachment.sig>