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
