Hi, > From: Gert Doering [mailto:g...@greenie.muc.de] > Sent: donderdag 18 april 2013 22:45 > > Hi, > > On Thu, Apr 18, 2013 at 08:28:42PM +0100, Ed W wrote: > > Hi, given the new abstractions to support PolarSSL, what > > interest/resistance would there be to supporting libsodium? > > https://github.com/jedisct1/libsodium > > It took us quite some effort to reach the point where a polarssl- > compiled openvpn would be able to talk to a (default-configured) > openssl-openvpn, and I don't really see us using a crypto library that > has none of the algorithms that we need for interoperability. > > But then, I'm not the crypto geek here, I'm just the janitor... >
As a (minor) crypto geek, I'd love to see support for NaCl. I'm personally very happy with PolarSSL, but it's good to have more options. There's a few issues that we need to overcome though: - Unfortunately as far as I know there's no TLS support in NaCl. I guess it could work as a crypto library for the data channel and TLS-Auth parts of OpenVPN though. The control channel could then still be managed by PolarSSL/OpenSSL. - Maintenance is an issue, are you (or do you know someone :)) willing to take responsibility for writing the required patches and maintaining them? - As Gert said, he default algorithm in OpenVPN is Blowfish with a SHA-1 HMAC. There's no support for auto-negotiation, so using NaCl will break compatibility with an OpenSSL/PolarSSL-based OpenVPN. This is minor though, as it's easy to work around this as an end-user by specifying the algorithms in the client and server config files. I don't want to sound overly negative though, the crypto abstraction in OpenVPN is flexible enough to support this sort of hybrid multi-library implementation now. At first glance, it would just require some tweaks to the build system, and some glue for libsodium. Adriaan
