From: Eric Biggers <ebiggers@kernel.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Benjamin Coddington <bcodding@hammerspace.com>,
Jeff Layton <jlayton@kernel.org>, NeilBrown <neil@brown.name>,
Trond Myklebust <trondmy@kernel.org>,
Anna Schumaker <anna@kernel.org>,
Rick Macklem <rick.macklem@gmail.com>,
linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-crypto@vger.kernel.org
Subject: Re: [PATCH v5 3/3] NFSD: Sign filehandles
Date: Mon, 9 Feb 2026 21:04:20 +0000 [thread overview]
Message-ID: <20260209210420.GA1062842@google.com> (raw)
In-Reply-To: <8574c412-31fb-4810-a675-edf72240ae29@oracle.com>
On Mon, Feb 09, 2026 at 03:29:07PM -0500, Chuck Lever wrote:
> On 2/9/26 1:09 PM, Benjamin Coddington wrote:
> > NFS clients may bypass restrictive directory permissions by using
> > open_by_handle() (or other available OS system call) to guess the
> > filehandles for files below that directory.
> >
> > In order to harden knfsd servers against this attack, create a method to
> > sign and verify filehandles using siphash as a MAC (Message Authentication
> > Code). Filehandles that have been signed cannot be tampered with, nor can
> > clients reasonably guess correct filehandles and hashes that may exist in
> > parts of the filesystem they cannot access due to directory permissions.
>
> It's been pointed out to me that siphash is a PRF designed for hash
> tables, not a standard MAC. We suggested siphash as it may be sufficient
> here for preventing 8-byte tag guessing, but the commit message and
> documentation calls it a "MAC" which is a misnomer. Can the commit
> message (or even the new .rst file) document why siphash is adequate for
> this threat model?
>
> Perhaps Eric has some thoughts on this.
PRFs are also MACs, though. So SipHash is also a MAC. See the original
paper: https://cr.yp.to/siphash/siphash-20120918.pdf
However, SipHash's tag size is only 64 bits, which limits its resistance
to forgeries. There will always be at least a 1 in 2^64 chance of a
forgery.
In addition, the specific variant of SipHash implemented by the kernel's
siphash library is SipHash-2-4. That's the performance-optimized
variant. While no attack is known on that variant, and the SipHash
paper claims that even this variant is a cryptographically strong PRF
and thus also a MAC, SipHash-4-8 is the more conservative variant.
If you'd like to be more conservative with the cryptographic primitive
and also bring the forgery chance down to 1 in 1^128, HMAC-SHA256 or
BLAKE2s with 128-bit tags could be a good choice.
(In commit 2f3dd6ec901f29aef5fff3d7a63b1371d67c1760, I used HMAC-SHA256
with 256-bit tags for SCTP cookies. Probably overkill, but the struct
already had 256 bits reserved for the tag.)
But again, SipHash (even SipHash-2-4) is indeed considered to be a MAC.
So if the only concern is that it's "a PRF but not a MAC", that's not
correct.
- Eric
next prev parent reply other threads:[~2026-02-09 21:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-09 18:09 [PATCH v5 0/3] kNFSD Signed Filehandles Benjamin Coddington
2026-02-09 18:09 ` [PATCH v5 1/3] NFSD: Add a key for signing filehandles Benjamin Coddington
2026-02-09 20:29 ` Chuck Lever
2026-02-10 16:46 ` Benjamin Coddington
2026-02-10 17:03 ` Chuck Lever
2026-02-10 17:21 ` Benjamin Coddington
2026-02-10 20:59 ` Benjamin Coddington
2026-02-09 18:09 ` [PATCH v5 2/3] NFSD/export: Add sign_fh export option Benjamin Coddington
2026-02-09 18:09 ` [PATCH v5 3/3] NFSD: Sign filehandles Benjamin Coddington
2026-02-09 20:29 ` Chuck Lever
2026-02-09 21:04 ` Eric Biggers [this message]
2026-02-09 23:17 ` Chuck Lever
2026-02-10 16:56 ` Benjamin Coddington
2026-02-10 17:10 ` Chuck Lever
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260209210420.GA1062842@google.com \
--to=ebiggers@kernel.org \
--cc=anna@kernel.org \
--cc=bcodding@hammerspace.com \
--cc=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=rick.macklem@gmail.com \
--cc=trondmy@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.