Should we replace libgoldilocks and libsodium with OpenSSL now that the latest version supports goldilocks?
Closed this issue · 3 comments
The question has come up on the OTR mailing list whether it would be a good idea to rely on openssl instead of libgoldilocks and libsodium. (The email mistakenly says we can also remove libgcrypt, but since libgcrypt is a dependency of libotr, there is no useful way for us to do this).
So, the basic idea is that since OpenSSL is more widely available on many platforms, and since having one dependency instead of having two dependencies makes it easier to get adoption. However, since the primitives we would need are all in the latest release of OpenSSL, it's not guaranteed that this version of OpenSSL will be available on those platforms anyway - thus putting it in the same situation as with our other dependencies.
We haven't mapped whether OpenSSL actually supports all the operations we really need - specifically, OTRv4 does require both EC scalar multiplication AND EC point addition on the same primitives. We are also making use of multi scalar multiplication and addition.
When it comes to libsodium, we are using some primitives, but we are also using utility functions from the library.
Fundamentally, investigating whether OpenSSL provides all we need is only worth doing if it would be a strong proposal to rewrite all the things we have already done. Thus, moving to OpenSSL would have to have a LARGE positive impact.
Personally, I don't see this large impact. The availability argument isn't very strong. Reducing dependencies is always good, but I prefer to look at reducing dependencies in terms of how much code you depend on, not how many libraries. And since OpenSSL is significantly larger than libsodium and libgoldilocks combined, I feel like adding OpenSSL would increase our attack surface.
Hey!
We haven't mapped whether OpenSSL actually supports all the operations we really need - specifically, OTRv4 does require both EC scalar multiplication AND EC point addition on the same primitives. We are also making use of multi scalar multiplication and addition.
Yes, they have it, as it is basically the same code from Mike. The concern I have on here is that for extra operations we might need (like the multiexponentiation), we cannot add to OpenSSL; but we can add to libgolidlocks and easily add to libdecaf.
On OpenSSL, I have not found XSalsa, but maybe I'm just not good at finding ;)
So, I don't see it as worthy to use it as well...
So, after having these thoughts, we have decided to not go with OpenSSL.