Re: [PATCH v1 0/7] kNFSD Encrypted Filehandles

[Eric Biggers <ebiggers@kernel.org>]

On Tue, Jan 13, 2026 at 05:33:37PM -0500, Benjamin Coddington wrote:
> > - Individual filehandles are small, on the order of 32- or 64-bytes
> >
> > - But there are a lot of filehandles, perhaps billions, that would
> >   be encrypted or signed by the same key
> >
> > - The filehandle plaintext is predictable
> 
> Mostly, yes.  I think a strength of the AES-CBC implementation is that each
> 16-byte block is hashed with the results of the previous block.  So, by
> starting with the fileid (unique per-file) and then proceeding to the less
> unique block (fsid + fileid again), the total entropy for each encrypted
> filehandle is increased.

This sort of comment shows that the choice of AES-CBC still isn't well
motivated.  AES-CBC is an unauthenticated encryption algorithm that
protects a message's confidentiality.  It isn't a hash function, it
isn't a MAC, and it doesn't protect a message's authenticity.  AES-CBC
will successfully decrypt any ciphertext, even one tampered with by an
attacker, into some plaintext.  You may be confusing AES-CBC with
AES-CBC-MAC.

> > There are plenty of other kmalloc / alloc_page call sites in the
> > request path, and the server is designed around permitting synchronous
> > waits for memory allocated with GFP_KERNEL. If you don't want to wait
> > for memory reclaim, use GFP_NOFS or even GFP_ATOMIC but for such small
> > allocations, it's highly unlikely that an allocation request will fail.
> 
> I'm ok doing the allocation dance for every filehandle, but I think its an
> easy optimization to keep the buffers around if you know you're going to be
> using them - same way we do for RPC buffers.

In the kernel, several MACs (such as HMAC-SHA256, HMAC-SHA512, BLAKE2s,
and SipHash-2-4) have clean APIs that don't require dynamic memory
allocation, scatterlists, or CONFIG_CRYPTO.  If you do need a MAC, you
probably should use one of those algorithms and APIs.

I see that FIPS 140-3 got mentioned.  In the case where the kernel is
certified as a FIPS 140-3 module, I don't know whether this feature
would actually be considered a security function for FIPS purposes or
not.  That would determine whether it would actually be required to use
a FIPS-approved algorithm.  If you're choosing a MAC and want to use a
FIPS-approved one to be safe, you could choose HMAC-SHA256.

However, as I said before, the first thing to do is actually to evaluate
what security guarantees you need.  To me it seems like you want to
ensure that for a given client, only file handles that it was sent by
the server will be accepted by the server (provided that it can't snoop
on handles sent to other clients).  An unauthenticated encryption mode
like AES-CBC doesn't solve that problem.  I think a MAC is sufficient to
solve that problem.  An AEAD would too and would add confidentiality
protection, but that seems overkill / unnecessary here.

- Eric