diff options
| author | Eric Biggers <ebiggers@kernel.org> | 2026-03-21 00:53:38 -0700 |
|---|---|---|
| committer | Eric Biggers <ebiggers@kernel.org> | 2026-03-25 12:06:33 -0700 |
| commit | 1546d3feb5e533fbee6710bd51b2847b2ec23623 (patch) | |
| tree | 52ee0d002ef042f3c474fe7272eede2cffa1dd4a /drivers/message/i2o/git@git.tavy.me:linux.git | |
| parent | 4377a22d84f726f0a650927edf75cdc0698baf06 (diff) | |
fscrypt: use AES library for v1 key derivation
Convert the implementation of the v1 (original / deprecated) fscrypt
per-file key derivation algorithm to use the AES library instead of an
"ecb(aes)" crypto_skcipher. This is much simpler.
While the AES library doesn't support AES-ECB directly yet, we can still
simply call aes_encrypt() in a loop. While that doesn't explicitly
parallelize the AES encryptions, it doesn't really matter in this case,
where a new key is used each time and only 16 to 64 bytes are encrypted.
In fact, a quick benchmark (AMD Ryzen 9 9950X) shows that this commit
actually greatly improves performance, from ~7000 cycles per key derived
to ~1500. The times don't differ much between 32 bytes and 64 bytes
either, so clearly the bottleneck is API stuff and key expansion.
Granted, performance of the v1 key derivation is no longer very
relevant: most users have moved onto v2 encryption policies. The v2 key
derivation uses HKDF-SHA512 (which is ~3500 cycles on the same CPU).
Still, it's nice that the simpler solution is much faster as well.
Compatibility verified with xfstests generic/548.
Link: https://lore.kernel.org/r/20260321075338.99809-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Diffstat (limited to 'drivers/message/i2o/git@git.tavy.me:linux.git')
0 files changed, 0 insertions, 0 deletions
