linux-kernel - Re: Chaining is dead

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z-toNJtPYsOmRcFM@gondor.apana.org.au>
Date: Tue, 1 Apr 2025 12:14:44 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: Chaining is dead

On Mon, Mar 31, 2025 at 09:08:52PM -0700, Eric Biggers wrote:
>
> Interesting seeing this argument coming from you when the whole Crypto API is
> built around forcing software crypto to use interfaces designed for hardware.

Perhaps you should take your rose-coloured glasses off? :)

> aes_expandkey() if we switch to that) for every I/O request.  The blk-crypto
> interface could be reworked to support pre-expansion of the key, but that would
> differ from what actual inline encryption hardware needs.  So this is just
> another case where the needs of hardware vs. software diverge...

If we're going to converge on one interface, then it better put
the needs of software crypto first and foremost.  Now that doesn't
mean throwing out support for hardware altogether, but hardware
does need to take a backseat every now and then.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt