Re: [PATCH v4 13/13] lib/crypto: Add documentation about zeroization of key and context data
From: Thomas Huth
Date: Thu Oct 01 2026 - 02:54:15 EST
On 30/09/2026 22.14, Eric Biggers wrote:
On Wed, Sep 16, 2026 at 11:50:15AM +0200, Thomas Huth wrote:Agreed, adding some wording about raw keys makes sense. However, I'll be very short in time during the next one or two weeks, so if you would like to do it, please go ahead and send a patch. Otherwise I'll look into this in a week or two when I've got some more spare time again.
+What to zeroize
+---------------
+
+The following types of structures hold sensitive material and should be
+zeroized after use:
+
+- **Key structures** (e.g. ``struct aes_key``, ``struct hmac_sha256_key``):
+ contain expanded round keys or prepared key material.
+
+- **HMAC/MAC context structures** (e.g. ``struct hmac_sha256_ctx``,
+ ``struct aes_cmac_ctx``): contain inner and outer hash states derived from
+ the key.
+
+- **Hash context structures** (e.g. ``struct sha256_ctx``): may contain
+ sensitive data being hashed.
+
+Not all of these require explicit cleanup by callers. Many ``..._final()``
+functions already zeroize their context internally (see `Automatic vs. manual
+zeroization`_ below).
This should mention that the raw key that the key struct was prepared
from needs to be zeroized as well. Every in-kernel user of a keyed
algorithm has to deal with this problem, as to "prepare" a key, you need
to have the key already in the first place (whether it's passed in from
userspace, or derived from some other key, or something else).
Zeroizing a 'struct aes_key' for example is kind of useless if the
actual raw AES key is still in memory somewhere.
Any interest in sending a follow-up patch that clarifies this? It
really should clarify that users of cryptography in the kernel should
apply zeroization to the full flow of their keys through the system
including system calls, key derivation, key preparation, etc.
Thanks,
Thomas