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

[Trond Myklebust <trondmy@kernel.org>]

On Wed, 2026-01-14 at 09:19 -0500, Chuck Lever wrote:
> On 1/14/26 8:19 AM, Jeff Layton wrote:
> > On Wed, 2026-01-14 at 07:39 -0500, Benjamin Coddington wrote:
> > > On 13 Jan 2026, at 19:42, Eric Biggers wrote:
> > > 
> > > > 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.
> > > 
> > > I'm not confusing them, and you're absolutely correct - if an
> > > encrypted
> > > filehandle were tampered with we'd be relying on the decoded
> > > filehandle
> > > being garbage - the routines to decode the fsid and fileid would
> > > return
> > > errors, because a filehandle's data is meaningful and well-
> > > structured.
> > > 
> > > That's a big difference from what using a MAC would provide -
> > > immediate
> > > knowledge the filehandle had been modified.
> > > 
> > 
> > I think a MAC is a better idea here too:
> > 
> > One thing that people keep pointing out is that you could
> > potentially
> > sniff traffic and just nab the encrypted filehandles, and match
> > them
> > with inode numbers, etc.
> > 
> > If you append a MAC though and check it on the server, you could
> > give
> > out filehandles that are limited-use. For instance, with v4, you
> > could
> > salt the hash with the long-form clientid and ensure that that
> > filehandle is only usable by that client. Anyone else gets back
> > NFS4ERR_STALE.
> > 
> > Couple that with TLS and you'd have a pretty decent guard against
> > sniffing and filehandle guessing attacks.
> 
> A sniffing attack is easier than guessing a file handle or
> constructing
> one. Neither encrypting a filehandle nor signing it protects against
> sniffing attacks. But using full in-transit encryption does, and we
> have that implemented already.
> 
> With full in-transit encryption, the plaintext is much much less
> predictable as well.
> 
> Just sayin'
> 

Protection against sniffing and protection against spoofing are two
completely orthogonal problems. Please don't muddle the already murky
waters in this thread by confusing the two.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@kernel.org, trond.myklebust@hammerspace.com