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.
signature.asc
Description: PGP signature
_______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
