Re: [PATCH v2 1/9] crypto: Provide a wrapper for zeroizing crypto_aes_ctx

On Tue, Aug 04, 2026 at 11:21:30AM +0900, Simon Richter wrote:
> Hi,
> 
> On 8/4/26 4:05 AM, Eric Biggers wrote:
> 
> > I guess we should start using __cleanup with type-specific zeroization
> > functions like this more often.
> Frame challenge: should key material be copied that often that we need a
> mechanism to keep track of it?

This seems to be yet another case where you are responding to some
thread and trying to start a mostly unrelated discussion.

There are many cases where data on the stack can be sensitive, and this
has always been the case.  If __cleanup helps to manage such data, it's
probably worth using more often.

> My feeling is that this wasn't a conscious decision, but is the result of
> two other decisions (that individually make sense): contexts need to be
> self-contained (so need to include key material), and context creation
> should be cheap (so stack contexts are allowed).

The entire point of "crypto_aes_ctx" is that it is an expanded AES key.
The callers of it are using it to compute the round keys.

If you're actually referring to the contexts for per-message incremental
calculation (e.g. sha256_ctx) offered by the library API, those are a
bit different.  Sometimes they contain key material, sometimes they
don't.  Even if the algorithm is unkeyed, it may still contain key
material, since the user could be hashing a key.  Either way, the
finalization function for each algorithm zeroizes it.  The caller needs
to zeroize only if it abandons a context without zeroizing it.

> 2. allow contexts to refer to key material stored elsewhere to avoid the
> copy. That opens the lifetime tracking can of worms, but the on-stack crypto
> context is rather short-lived.

That is already what is being done in most cases.  The exception is the
HMAC library code since the 'ostate' is not very large.  But again the
per-message contexts are supposed to be zeroized anyway.  Also, if the
one-shot functions are used, then no context is exposed to the caller...

- Eric