> does not inspire a lot of confidence in their fork
Just out of interest, what reasons do you have for this?
Much of the code seems... incomplete? I don't want to sound too harsh, but what scares me looking glancing at the changes, are the functions `set_ncp_disable` and `set_ncp_enabled`.
Surely it's good though that someone has started adding ChaCha20 and Poly1305 to OpenVPN?
Pretty much this exactly. There's not a lot here, but what is there leaves you kind of confused about what the point is.
I'm not a cryptographer and can't vouch one way or another for the safety of their fork, but a lot of the changes are just stuff like moving whitespace around, and the stuff that isn't pointless sometimes involves changes to important cryptography functions without clear explanations or justifications given in the commit messages. All of the changes are by a single user without any clear indication that they've been reviewed by someone qualified to do cryptography.
And above all there's no obvious reason this fork needs to exist. There's no evidence that it's fixing any "critical bugs" that the OpenVPN project is ignoring, and if the changes are worthwhile they should just be upstreamed. If you're going to pursue something as major as forking OpenVPN, it's really on you to provide some evidence that people should trust your work.
> Surely it's good though that someone has started adding ChaCha20 and Poly1305 to OpenVPN?
For sure, but maybe they should put more effort into getting Wireguard support for their servers instead?
>Surely it's good though that someone has started adding ChaCha20 and Poly1305 to OpenVPN?
What's the advantage of those new ciphers? AFAIK they have better performance than AES on hardware without AES acceleration, but most consumer devices already have it.
Most (all nowadays?) Android tablets and smart phones are based on ARM processors that do not support AES-NI. Even a lot of consumers' routers, which can run OpenVPN, do not support AES-NI.
Raspberry Pi, nVidia Shield, Amazon FireStick are additional examples that come to mind, not to mention many other embedded devices, mediaplayers, Android based TVs...
I have verified impressive improvement (up to 45%) in throughput with CHACHA20 vs. AES-256 in several ARM based devices running either Android or Linux ARM (connecting to the same AirVPN server with same router, same ISP and same application based for Android or Linux ARM on their forked library).
About desktop computers, things might change with AVX-512 wider adoption: it remains to be seen whether AES-NI can perform better with AES-256-GCM than AVX-512 supporting processors can do with CHACHA20. I don't have the option to test that, anybody did?
Just out of interest, what reasons do you have for this?
Much of the code seems... incomplete? I don't want to sound too harsh, but what scares me looking glancing at the changes, are the functions `set_ncp_disable` and `set_ncp_enabled`.
Surely it's good though that someone has started adding ChaCha20 and Poly1305 to OpenVPN?