Re: [PATCH 0/3] crypto: Remove arch-optimized des and des3_ede code

[Eric Biggers <ebiggers@kernel.org>]

On Fri, Mar 27, 2026 at 06:59:21PM +0900, Simon Richter wrote:
> On 3/27/26 5:27 AM, Eric Biggers wrote:
> 
> > In general that's good of course, but DES and 3DES?  Really?  Why is
> > effort going into these obsolete algorithms at all?
> 
> If there's dedicated instructions, we need to emulate them, even if the
> kernel stops using them, because userspace might still use them. The
> alternative is implementing them as a trap in the kernel that delegates to
> the crypto subsystem, and nobody wants that. O_O

While I appreciate the sudden eagerness to implement these instructions
in QEMU after them not being supported for 15 years, I'd suggest that
the instructions for the more modern algorithms should be prioritized.

> I wonder if it would make sense to split between "crypto" and "offload"
> subsystems, so the "crypto" side can focus on a small number of contemporary
> algorithms and give them simple, easily auditable interfaces, and move all
> the complexity of asynchronous request processing in offload hardware over
> to the "offloading" side. The userspace API would also move to the
> "offloading" subsystem.

lib/crypto/ and crypto/ already largely provides that distinction, no?

> This would give the offloading subsystem a bit more flexibility in API
> design as well, so we could maybe represent offload capabilities in network
> or storage hardware as well

The kernel already has perfectly good support for inline storage
encryption in the block layer.  See
Documentation/block/inline-encryption.rst.  It's a completely different
model from non-inline crypto engines.  Trying to create some common
abstraction is not going to succeed.

> However, even from the "crypto" perspective I believe that we can't get
> around support for asynchronous offload devices, because of mobile devices.
> I suspect no one would be building dedicated silicon for asynchronous AES
> into mobile CPUs if that wasn't worth it somehow

They do it anyway.  It's a checkbox feature.  I.e. the purpose is for it
to be advertised on a list of features.

> so if such a device is
> present, we want to use it as much as possible, because the expectation is
> that while the difference in performance compared to the CPU is hardly
> noticeable, the difference in battery lifetime is (that's why dropping async
> request support from fscrypt makes it largely useless on mobile).

I'm quite familiar with how fscrypt is being used on mobile, thanks.
Most people do use hardware offload with fscrypt, but it is *inline*
hardware offload.  That remains fully supported via blk-crypto and is
unrelated to the crypto API.  The rest just use the CPU.

I've only ever heard of one case almost a decade ago where someone
intentionally used a non-inline offload engine with fscrypt.  And I even
recently showed that on the same line of SoCs that was being used in
that case, it is no longer worth it, if it ever was.

Every other case has just been someone using one by mistake and getting
their performance tanked or encountering driver bugs as a result.

Anyway, this seems very off-topic for this thread, which is about
whether the architecture-optimized DES and 3DES code should be removed.

- Eric