Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Chuck Lever <cel@kernel.org>
Cc: Benjamin Coddington <bcodding@hammerspace.com>,
	Chuck Lever <chuck.lever@oracle.com>,
	Jeff Layton <jlayton@kernel.org>, NeilBrown <neil@brown.name>,
	Trond Myklebust <trondmy@kernel.org>,
	Anna Schumaker <anna@kernel.org>,
	linux-nfs@vger.kernel.org, linux-crypto@vger.kernel.org
Subject: Re: [PATCH v1 6/7] NFSD: Add filehandle crypto functions and helpers
Date: Sun, 28 Dec 2025 12:45:14 -0800	[thread overview]
Message-ID: <20251228204514.GC2431@quark> (raw)
In-Reply-To: <bc74d1a3-d128-486e-939a-f7b3dc560931@app.fastmail.com>

On Sat, Dec 27, 2025 at 08:34:18PM -0500, Chuck Lever wrote:
> I'd feel more comfortable if the crypto community had a look
> to ensure that we're utilizing the APIs in the most efficient
> way possible. Adding linux-crypto ...

Many crypto algorithms (especially hash algorithms and MACs) have
library APIs now.  They're much easier to use than the traditional APIs.

But it's too soon to be discussing which API to use.  Looking at the
whole series in lore, there doesn't seem to be any explanation of what
problem this series is trying to solve and how cryptography is being
used to solve that problem.

The choice of AES-CBC encryption is unusual.  It's unlikely to be an
appropriate choice for the problem.

I suspect you're really looking to protect the authenticity of the file
handles, not their confidentiality; i.e., you'd like to prevent clients
from constructing their own file handles.  In that case you'd probably
need a MAC, such as SipHash or HMAC-SHA256.  This would be similar to
the kernel's existing implementations of TCP SYN and SCTP cookies: the
system sends out cookies that encode some information, and it uses a MAC
to verify that any received cookie is a previously sent one.

But that's just what I suspect.  I can't know for sure since this series
doesn't provide any context about what it's trying to achieve.

- Eric

  reply	other threads:[~2025-12-28 20:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1766848778.git.bcodding@hammerspace.com>
     [not found] ` <0688787cf4764d5add06c8ef1fecc9ea549573d7.1766848778.git.bcodding@hammerspace.com>
2025-12-28  1:34   ` [PATCH v1 6/7] NFSD: Add filehandle crypto functions and helpers Chuck Lever
2025-12-28 20:45     ` Eric Biggers [this message]
2025-12-29 13:39       ` Benjamin Coddington

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=20251228204514.GC2431@quark \
    --to=ebiggers@kernel.org \
    --cc=anna@kernel.org \
    --cc=bcodding@hammerspace.com \
    --cc=cel@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=jlayton@kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neil@brown.name \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox