Re: setkey -- twofish-cbc unsupported algorithm

[Greg Troxel <gdt%lexort.com@localhost>]

Pierre-Philipp Braun <pbraun%nethence.com@localhost> 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.