Hi Antonio, Understood. We have dicussed this in the OpenWRT forum. Maybe some kind OpenWRT guys will implement aead hmac-sha256-cbc-aes for ovpn-dco module in the future.
https://forum.openwrt.org/t/ipq806x-nss-drivers/12613/2180?u=tony.he Tony Antonio Quartulli <a...@unstable.cc> 于2020年11月26日周四 下午3:49写道： > Hi Tony, > > On 26/11/2020 01:46, Tony He wrote: > >>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 > > chip vendor. Please refer to: > > https://github.com/cryptodev-linux/cryptodev-linux > > <https://github.com/cryptodev-linux/cryptodev-linux> > > > https://openwrt.org/docs/techref/hardware/cryptographic.hardware.accelerators > > < > https://openwrt.org/docs/techref/hardware/cryptographic.hardware.accelerators > > > > Thanks for clarifying! > I thought you were talking about the crypto engine offload provided by > OpenSSL via vendor library. > > So, if I understand this correctly, what you are saying is that the > vendor provides kernel patches in order to add HW support to the kernel > crypto API for an architecture that is normally not supported by the > upstream kernel. Then cryptodev is used to allow userspace to use the > kernel API. > > This said, I am sorry, but I am not sure we should continue this > discussion any further, because as of now we have no plan to introduce > yet another crypto family in ovpn-dco. > > One of the goal with ovpn-dco is to leave behind the legacy from > openvpn2 in userspace and focus on those features we believe to be > "state of the art". This is why we decided to only support AEAD with > only AES-GCM and CHACHA20POLY1305, DATA_V2 only, etc. > > Focus is on keeping the code simple and ensure it can be accepted > upstream in the Linux kernel quickly. > > It was an hard decision to make, but the whole group decided to take > this direction. People that want to use different > configurations/settings will still be able to do so by using openvpn2 in > userspace, as it happened until now. > > > Cheers, > > > > > > Tony > > > > > > Antonio Quartulli <a...@unstable.cc> 于2020年11月26日周四 上午12:19写道： > > > > Hi Tony, > > > > > OpenVPN-> openssl->crypodev engine->cryptodev-linux->Linux kernel > > crypto API->HW engine crypto API-> HW engine driver-> HW engine > > > > Now I understand better what you have in mind. > > > > To the best of my knowledge, this is not how it works. > > > > 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. > > > > Moist of the time this special interfaces are made "to work with > openssl > > only", so I am not even sure how the kernel API could use it. > > > > Do you have any pointer saying otherwise? > > > > > > -- > > Antonio Quartulli > > > > -- > Antonio Quartulli >
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
