Re: [PATCH v3 1/2] rust: crypto: add AES-128, AES-CMAC, SHA-256, and HMAC bindings

[Eric Biggers]

On Mon, Aug 31, 2026 at 05:51:11PM +0100, Mike Lothian wrote:
> On Wed, 26 Aug 2026, Eric Biggers wrote:
> > There's an aes_ctr() function now.
> >
> > With that, is bare AES still needed?
> 
> Not for the CTR, no. It is not in the tree this was based on --
> drm-rust-next as of 2026-08-06, where lib/crypto has aes.c, aescfb.c and
> aesgcm.c and no CTR at all -- which is why I built it out of a prepared
> key schedule instead.
> 
> The driver's two CTR sites are plain SP 800-38A: a 64-bit nonce, four
> zero bytes, and a 32-bit big-endian block counter. aes_ctr() replaces
> both loops outright, and the key-schedule reuse that this patch was
> partly justifying stops mattering.
> 
> That leaves exactly one caller of the bare block cipher: the HDCP 2.2
> dKey derivation, which is a single AES-128 ECB block encrypt. So the
> question I would put back to you is whether lib/crypto is willing to
> expose a one-shot single-block encrypt for that, or whether you would
> rather that one caller kept using aes_prepareenckey() and aes_encrypt()
> directly. Either way I will cut the rest of the AES from this patch.
> 
> Mike

I'm not currently planning to make the crypto library expose AES
functions that take raw keys, since computing the AES round keys is
fairly slow and most users use their AES keys multiple times.  So in
this case I guess keep planning to use the sequence that is already
supported: aes_prepareenckey() + aes_encrypt() + memzero_explicit().
For CTR mode, use aes_prepareenckey() + aes_ctr() + memzero_explicit().

But if you're using either key multiple times you should call
aes_prepareenckey() just once and cache the result, as that is what it
is for.

- Eric