Hi Arne, >Since the original thread was not on the mailing list I am missing your >goal but if your crypto acelator already works with OpenSSL, then it >will also work with the "normal" OpenVPN
Yes, it wokrs with "normal" OpenVPN(OpenVPN2), but according to the test result, it's still not fast(about 60Mbps). The bottleneck is not encryption operation any more. It comes from the switch of user space and kernel space in the OpenVPN2, which makes the poor CPU of embedded device very busy. That's why we need OpenVPN3 running in the kernel space. Tony Tony <383181...@qq.com> 于2020年11月26日周四 下午5:32写道： > > > > ------------------ 原始邮件 ------------------ > *发件人:* "Arne Schwabe" <a...@rfc2549.org>; > *发送时间:* 2020年11月26日(星期四) 下午5:22 > *收件人:* "Tony He"<huangy...@gmail.com>;"Antonio Quartulli"<a...@unstable.cc>; > *抄送:* "lev"<l...@openvpn.net>;"openvpn-devel"< > openvpn-devel@lists.sourceforge.net>; > *主题:* Re: [Openvpn-devel] [ovpn-dco] Is cbc-hmac supported? > > Am 26.11.20 um 01:46 schrieb Tony He: > >>OpenSSL directly talks to the crypto engine via a proprietary interface > >>that the FW/driver exposes to userspace. The *data* flow does not cross > >>the linux kernel crypto API > > > > No, OpenSSL doesn't directly talk to the crypto engine via a > > proprietary interface that the FW/driver exposes to userspace. > > "cryptodev engine" is NOT the "HW engine" chip vendor provides. It's a > > common interface and its source is not from > > > To be honest. We currently aim to feature current state of the art > support. And with supporting only the AEAD algorithm we support all > clients of 2.4 and later. > > Since the original thread was not on the mailing list I am missing your > goal but if your crypto acelator already works with OpenSSL, then it > will also work with the "normal" OpenVPN. > > If you look over the fence at IPSec accleration in Intel NIC hardware, > you will find that those also only support AES-GCM. And that with even > hardware that came out almost 10 years ago. > > Or look at TLS 1.3. De facto there is only AES-GCM and Chacha20-Poly1305 > left as standard. TLS1_3_RFC_AES_128_CCM_8_SHA256 is specified but you > need to specifically configure your TLS library to support this. This > inclusion of AES-CCM is specifically to cater for use use cases like yours. > > Since AES-CCM is an AEAD cipher supporting that makes more sense and > might very straightforword if it is supported by the AEAD APIs we > already use. > > Arne > > > _______________________________________________ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel >
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
