OpenVPN 3 development

[Staff 10014]

Hello!

We're very glad to inform you that AirVPN has begun to actively contribute to OpenVPN 3 development.

Our first goal has been adding support for ChaCha20 cipher with Poly1305 as authenticator on OpenVPN 3 Data Channel.

ChaCha20 is a stream cipher developed by Daniel J. Bernstein which combines strength and remarkable performance. https://en.wikipedia.org/wiki/Salsa20#ChaCha20_adoption

When compared with AES-GCM, ChaCha20 offers significant computational relief to all AES-NI non supporting processors, such as ARM processors.

ARM processors, routinely used on very many tablets, smart phones, media centers, smart TVs and routers, will get great benefits from OpenVPN with ChaCha20. Our tests show that CPU load caused by ChaCha20 on recent ARM 64 bit processors is at least 50% less than AES-256-GCM, on equal terms, which translates into dramatic performance boost and longer battery life (if you have ever tested Wireguard on an ARM based device you know what we mean).

OpenVPN 3 is a client library. However, OpenVPN 2.5, which is currently in beta testing and includes all the necessary servers features, supports ChaCha20 on the Data Channel. Therefore, making OpenVPN 3 with ChaCha20 available to our users and allowing a real life test will be a matter of days. We will progressively release beta clients for Android, Linux, OpenBSD and FreeBSD, in this order. We are considering a porting to OpenIndiana as well.

Internal alpha testing has concluded successfully. We have already pulled a merge request to OpenVPN 3 main branch, to let the whole community take advantages from our code, and let OpenVPN developers merge the new code into the main branch if they wish so. https://github.com/OpenVPN/openvpn3/pull/78

Implementation has been designed, developed and programmed for AirVPN by ProMIND, who is also Eddie Android edition developer.

Stay tuned, more will come!

UPDATE: https://airvpn.org/forums/topic/44069-openvpn-3-development-by-airvpn/

The above linked topic is now the central thread to discuss anything related to OpenVPN 3 development and testing.

Kind regards and datalove
AirVPN Staff

[go558a83nk 364]

Do you have any data to report on ChaCha20 performance on CPUs that *do* support AES-NI?  That is, AES-256-GCM accelerated by AES-NI vs ChaCha20?

The following site suggests that those of us with AES-NI CPU should stick with ciphers that are accelerated by AES-NI.  Do you concur?

https://calomel.org/aesni_ssl_performance.html

[zsam288 36]

Glad to be subscribed to a service so concerned with the future and development of new techniques. Great job AirVPN.

[arteryshelby 25]

54 minutes ago, go558a83nk said:

Do you have any data to report on ChaCha20 performance on CPUs that *do* support AES-NI?  That is, AES-256-GCM accelerated by AES-NI vs ChaCha20?

Yes AES-GCM will perform better with AES-NI support then ChaCha20.

Thats the reason why Cloudflare uses ChaCha20 for mobile but AES-GCM for desktop.

[twan69666 1]

Id be happy if Open VPN3 moved to a more efficient multi-core implementation for a connection vs a single core.

Anyway, thanks for being on the lookout for your members

[Staff 10014]

2 hours ago, go558a83nk said:

Do you have any data to report on ChaCha20 performance on CPUs that *do* support AES-NI?  That is, AES-256-GCM accelerated by AES-NI vs ChaCha20?

The following site suggests that those of us with AES-NI CPU should stick with ciphers that are accelerated by AES-NI.  Do you concur?

https://calomel.org/aesni_ssl_performance.html

We agree, when AES-NI are supported. Note that some processors do support AES-NI but the system doesn't use them (examples: AES-NI disabled at BIOS level; OpenSSL or other SSL library not properly compiled).

Also see https://tools.ietf.org/html/rfc8439#appendix-B
(however note that the comparison is made between AES-128-GCM and ChaCha20 but a more correct comparison would be with AES-256-GCM because of the 256 bit key size of ChaCha20).

Not only the appendix but also important considerations in the introduction and later.

Kind regards
 

[Staff 10014]

1 hour ago, twan69666 said:

Id be happy if Open VPN3 moved to a more efficient multi-core implementation for a connection vs a single core.

Anyway, thanks for being on the lookout for your members

Thank you!

Of course. The idea has been floating around since several years ago https://community.openvpn.net/openvpn/wiki/RoadMap

The OpenVPN 3 Core Library is based on a different approach, implementing the OpenVPN protocol as a C++ library. This gives lots of the same possibilities and modularity as this draft tried to resolve. Further, OpenVPN 3 is multi-thread capable and integrates with ASIO for all asynchronous processing and socket handling.

[Maggie144 12]

I just red through your PullRequest on github - this guy "schwabe" is no joke..
Are you still going forward with the ChaCha20 implementation? Sounds really promising - thank you for your work ProMIND

[Staff 10014]

34 minutes ago, Maggie144 said:

I just red through your PullRequest on github - this guy "schwabe" is no joke..
Are you still going forward with the ChaCha20 implementation? Sounds really promising - thank you for your work ProMIND

Yes, we're very glad to confirm that the implementation of ChaCha20-Poly1305 on OpenVPN 3 Data Channel is complete and fully working according to our tests, which have been quite thorough.

Schwabe's objections are questionable and never enter into the real argument: look at the previous source code of OpenVPN 3 and the new code by ProMIND. You will see all you need to know.

Of course our OpenVPN 3 source code will remain available to the community and we want to underline that the style is compliant to the most up to date Knuth's guidelines on the Art of computer programming, while OpenVPN 3 source code is not. We have doubts to comply to Schwabe's requirements and we need to consider the matter carefully: if higher standards are deemed as a problem, then the real problem lies probably in the low standards, not in the higher ones.

We now need an additional commit to OpenVPN 3 (almost ready to be published, already tested successfully) and then we will start to develop and release all the software according to the plans we have published. We are talking about days, stay tuned!

Kind regards

 

[frechdax 0]

3 minutes ago, Staff said:

Yes, we're very glad to confirm that the implementation of ChaCha20-Poly1305 on OpenVPN 3 Data Channel is complete and fully working according to our tests, which have been quite thorough.

Schwabe's objections are questionable and never enter into the real argument: look at the previous source code of OpenVPN 3 and the new code by ProMIND. You will see all you need to know.

Of course our OpenVPN 3 source code will remain available to the community and we want to underline that the style is compliant to the most up to date Knuth's guidelines on the Art of computer programming, while OpenVPN 3 source code is not. We have doubts to comply to Schwabe's requirements and we need to consider the matter carefully: if higher standards are deemed as a problem, then the real problem lies probably in the low standards, not in the higher ones.

We now need an additional commit to OpenVPN 3 (almost ready to be published, already tested successfully) and then we will start to develop and release all the software according to the plans we have published. We are talking about days, stay tuned!

Kind regards

 

"I think we prefer real names in commits." This schwabe guy complains over anything, he is so damn annoying.
However, I'm really exited for the upcoming days. Keep it up!

[OpenSourcerer 1441]

I would like to defend Mr. Schwabe there. I tend to go with him as he does make some very valid points. It's his software, his implementation, he made a certain coding style the standard for his project, and by contributing you are the guest. If such a guest just outright tries to get his name into the code and pushes his own opinion on how code should be styled, even if it's based on some alleged standard, it's outright rude. I would find it rude at least. I would not if someone asked me to reconsider the style.
If you had contributed to the Linux kernel like that, Linus would tear you to tiny bits. Murder by words, I believe Reddit calls this.

ProMIND claims he tags his commits in the code with his name to make his changes better visible. A commit like "based on xyz by ProMIND" is a bit of advertising for a software made by him, wouldn't you think? Schwabe's right if he asks what it has to do with anything, because it does not have to do with anything in relation to OpenVPN3 code. He didn't even need to tag it at all, as Schwabe said, git blame will do, and there's also git log --author=xyz...

It's just so cruel to see you simply close the PR as if you are the offended when he clearly told you of the simple things to do to get it merged. Don't be that guy, please.

[Staff 10014]

10 hours ago, giganerd said:

ProMIND claims he tags his commits in the code with his name to make his changes better visible. A commit like "based on xyz by ProMIND" is a bit of advertising for a software made by him, wouldn't you think? Schwabe's right if he asks what it has to do with anything, because it does not have to do with anything in relation to OpenVPN3 code. He didn't even need to tag it at all, as Schwabe said, git blame will do, and there's also git log --author=xyz...

It's just so cruel to see you simply close the PR as if you are the offended when he clearly told you of the simple things to do to get it merged. Don't be that guy, please.

Nonsense. The tags were meant to make the review easier and in the subsequent commit they were removed as required.

Kind regards