Pierre-Philipp Braun <pbr...@nethence.com> writes: >> I'm not clear on if Chacha20 is specified for IPsec. > > It was not there originally of course, but it's coming (proposed standards) > > ChaCha20 & Poly1305 for IPsec > https://tools.ietf.org/html/rfc7634
Well, I guess you have an opportunity to add support :-) In all seriousness, I am not aware of anyone actively working on the IPsec code, but I would expect a patch to add a recommended algorithm would be welcome, modulo the usual concerns about licensing and code quality. >> NetBSD has support for various crypto offload devices. Aside from >> AES-NI instrucions, my impression is that offload devices are mostly >> useful for public-key operations. > > Hmm maybe in some very specific cases but when we consider hardware > crypto accel, the most common case it the CPU flags to do AES (and > eventually Camellia which is compatible). To me, this is 99% of the > crypto hardware accel in the world and it's symmetric. Today, that's true. Back when the frameworks were created, the main thing was offboard accelerators. > I've personally experienced how too much SSL load can crash down a > service. I was running Jitsi Meet on good but old enterprise-class > servers with 16 Xeon cores and guess what happened when serving 10+ > video streams?... All cores went 100% and there were incidents. The > culprit: CPUs were to old w/o AES-NI, AVX nor AVX2. In a nutshell, we > absolutely need hardware accel for SSL and AES. >> Run "openssl engine" and read any associated man pages. > > Yep for the record, on a netbsd-9 guest with hw accel I get > > (devcrypto) /dev/crypto engine > (rdrand) Intel RDRAND engine > (dynamic) Dynamic engine loading support > > while on another netbsd-9 w/o hw accel I get > > (cryptodev) BSD cryptodev engine > (dynamic) Dynamic engine loading support > (4758cca) IBM 4758 CCA hardware engine support > (aep) Aep hardware engine support > (atalla) Atalla hardware engine support > (cswift) CryptoSwift hardware engine support > (chil) CHIL hardware engine support > (nuron) Nuron hardware engine support > (sureware) SureWare hardware engine support > (ubsec) UBSEC hardware engine support > (gost) Reference implementation of GOST engine > > I wonder why the second one got more options, but in any case /dev/crypto is > missing. I am really not clear on the details. It would be a useful contribution to the community to figure it all out.
