AF_ALG if I remember correctly predates userspace-accessible crypto acceleration and was way more important back when it meant you had actual need for "SSL accelerator" cards in servers, among other things

Yes, I remember that time, it was back when I wasn't allowed to know anything about what servers were doing other than to look it up in the internal leak, which was never maintained

*intenral wiki

Hi, embedded firmware engineer here. I give it a B-

There's a weird area between the workloads that fit on a microcontroller, and the stuff that demands a full-blown CPU. Think softcore processors on FPGAs, super tiny MIPS and RISC-V cores on an ASIC, etc. Typically you run something like Yocto on a core like that. Maybe MontaVista or QNX if you've got the right nerd running the show.

So you have serious compute needs, and security concerns that justify virtual memory. But you don't have infinite space to work with, so hardware acceleration is important. Having a standard API built into the kernel seems like a decent idea I guess.

And yet, I've never heard of AF_ALG. I've never seen it used. The thing is, if you have some bizzaro softcore, there's a good chance you also have a bizzaro crypto engine with no upstream kernel driver. If you're going to the trouble of rolling your own kernel with drivers for special crypto engines, why would you bother hooking it into this thing? Roll your own API that fits your needs and doesn't have a gigantic attack surface.

You should take note that this is written by the person that wrote the bad patch.

So grain of salt.

I've said I'm not sure about the validity of that reasoning.

I've liked it nevertheless for context, as augmentation to parent's post.

I feel like it should be possible to fulfill these advantages with a minimal, not very complex API. I.e. the grandparent's comment about IPsec implementation details doesn't make the cut, but a hardware accelerated cipher implementation does.

A hardware accelerated DMA-capable cipher implementation is an odd thing, and it’s generally not useful on its own. You might want to set up a whole chain of operations (encrypt, checksum, send to network, for example), but I’ve never encountered a case where you actually want to ask an accelerator to asynchronously encrypt application data and return the encrypted data to the application.

Unless you're pushing a ton of extra work into a network-capable accelerator, that sounds exactly like what you'd want for, e.g., an encrypted S3 implementation. You have encryption, RS encoding, striped checksumming, sending fragments to multiple hosts, some sort of potentially interesting partial failure handling, etc.

You could push that all down to the accelerator, but if there are even a few such use cases you might want a dedicated DMA-capable implementation instead.

But is it true or not? Whoever wrote it. (for objective truth the subjects are unimportant)

It might have been true in 2002 but it hasn't been true since at least about 2010.

You've almost certainly never had a system that supported any hardware accelerated crypto that also required a kernel module.

It's much easier to expose as cpu extensions.

When you can’t know the objective truth or when there isn’t one (as is the case in making decisions about security tradeoffs in software design), knowing the source of the argument is vital to interpreting its validity.

I disagree 100%. Software security tradeoffs are definitely the sort of thing where you can evaluate arguments on their merits.

This suggests that it is useful in some niche embedded use- cases, but should probably not be enabled by default on most desktop/server kennels