Re: [PATCH v3 1/2] rust: crypto: add AES-128, AES-CMAC, SHA-256, and HMAC bindings
From: Eric Biggers <ebiggers@kernel.org>
Date: 2026-08-31 17:05:48
On Mon, Aug 31, 2026 at 05:51:11PM +0100, Mike Lothian wrote:
On Wed, 26 Aug 2026, Eric Biggers wrote:quoted
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