DES and 3DES are cryptographically obsolete and insecure by modern
standards.  Continuing to maintain highly specific, complex assembly and
glue code for them, especially when the code isn't testable in QEMU
(s390 and sparc), is unnecessary and risky.

Thus, this series removes the architecture-optimized DES and 3DES code
for the three architectures that had it: s390, sparc, and x86.

This series is targeting cryptodev/master.

Eric Biggers (3):
  crypto: s390 - Remove des and des3_ede code
  crypto: sparc - Remove des and des3_ede code
  crypto: x86 - Remove des and des3_ede code

 arch/s390/configs/debug_defconfig |   1 -
 arch/s390/configs/defconfig       |   1 -
 arch/s390/crypto/Kconfig          |  16 -
 arch/s390/crypto/Makefile         |   1 -
 arch/s390/crypto/des_s390.c       | 502 ------------------
 arch/sparc/crypto/Kconfig         |  14 -
 arch/sparc/crypto/Makefile        |   2 -
 arch/sparc/crypto/des_asm.S       | 419 ---------------
 arch/sparc/crypto/des_glue.c      | 482 -----------------
 arch/x86/crypto/Kconfig           |  14 -
 arch/x86/crypto/Makefile          |   3 -
 arch/x86/crypto/des3_ede-asm_64.S | 831 ------------------------------
 arch/x86/crypto/des3_ede_glue.c   | 391 --------------
 13 files changed, 2677 deletions(-)
 delete mode 100644 arch/s390/crypto/des_s390.c
 delete mode 100644 arch/sparc/crypto/des_asm.S
 delete mode 100644 arch/sparc/crypto/des_glue.c
 delete mode 100644 arch/x86/crypto/des3_ede-asm_64.S
 delete mode 100644 arch/x86/crypto/des3_ede_glue.c


base-commit: f9bbd547cfb98b1c5e535aab9b0671a2ff22453a
-- 
2.53.0

On Thu, 2026-03-26 at 13:12 -0700, Eric Biggers wrote:
> DES and 3DES are cryptographically obsolete and insecure by modern
> standards.  Continuing to maintain highly specific, complex assembly and
> glue code for them, especially when the code isn't testable in QEMU
> (s390 and sparc), is unnecessary and risky.

We're working on getting crypto instructions added to QEMU though.

Adrian


-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

On Thu, Mar 26, 2026 at 09:20:51PM +0100, John Paul Adrian Glaubitz wrote:
> On Thu, 2026-03-26 at 13:12 -0700, Eric Biggers wrote:
> > DES and 3DES are cryptographically obsolete and insecure by modern
> > standards.  Continuing to maintain highly specific, complex assembly and
> > glue code for them, especially when the code isn't testable in QEMU
> > (s390 and sparc), is unnecessary and risky.
> 
> We're working on getting crypto instructions added to QEMU though.
> 
> Adrian

In general that's good of course, but DES and 3DES?  Really?  Why is
effort going into these obsolete algorithms at all?

- Eric

Hi,

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

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.

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, or allow userspace to set policies 
or find an optimized routing, without compromising security in the 
crypto subsystem.

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 -- 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).

Most of the other offload scenarios are already handled bypassing the 
crypto subsystem: the network stack has its own offloading mechanism, 
while nx-gzip is a regular device driver and does not even register an 
acomp algorithm (even though that would be really cool for zram/zswap, 
and would benefit dozens (dozens!) of users).

A lot of the resistance to changes in the crypto subsystem comes from 
the long tail, either hardware that is somewhat seldom, or built for 
some special purpose where the crypto APIs are already a limiting 
factor, and further consolidation towards standard PCs is making the 
situation worse.

I can certainly see that the complexity in the API that would be needed 
to support all the interesting use cases is somewhat undesirable, hence 
the idea to split off generic transforms and allow the interfaces there 
to become more expressive (on-device dmabufs, in-place operation, 
device-side contexts, device-side queues, device-to-device transfer 
offload, ...).

The current state where these use cases are technically inside the scope 
of the crypto subsystem, but deemed out of scope by the crypto subsystem 
leaves them in a kind of limbo, and that is very frustrating.

I don't know if it will be worth it to dedicate a weekend to 
implementing nx-gzip support as an acomp module, or nx-aes support as 
acrypt, or if that work would be rejected or removed in half a year, and 
I'm sure maintainers of ports to older hardware feel similar.

    Simon

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

On Thu, Mar 26, 2026 at 01:27:33PM -0700, Eric Biggers wrote:
> On Thu, Mar 26, 2026 at 09:20:51PM +0100, John Paul Adrian Glaubitz wrote:
> > On Thu, 2026-03-26 at 13:12 -0700, Eric Biggers wrote:
> > > DES and 3DES are cryptographically obsolete and insecure by modern
> > > standards.  Continuing to maintain highly specific, complex assembly and
> > > glue code for them, especially when the code isn't testable in QEMU
> > > (s390 and sparc), is unnecessary and risky.
> > 
> > We're working on getting crypto instructions added to QEMU though.
> > 
> > Adrian
> 
> In general that's good of course, but DES and 3DES?  Really?  Why is
> effort going into these obsolete algorithms at all?
> 
> - Eric

I would suggest focusing your efforts on more modern algorithms, like
AES (which has its own SPARC instructions and code), and not worrying
about DES and 3DES.  It's just not worth it anymore.  Note that I'm
proposing dropping the x86 DES and 3DES code as well.

- Eric