From dhowells@redhat.com  Wed Mar  5 09:33:36 2025
From: dhowells@redhat.com (David Howells)
Date: Wed, 05 Mar 2025 09:33:36 +0000
Subject: [AFS3-std] Re: RFE: Support for client-side content encryption in AFS
In-Reply-To: <20250305022353.GB20133@sol.localdomain>
References: <20250305022353.GB20133@sol.localdomain> <3324492.1740742954@warthog.procyon.org.uk>
Message-ID: <4114838.1741167216@warthog.procyon.org.uk>

Eric Biggers <ebiggers@kernel.org> wrote:

> First, CephFS already supports fscrypt.  Have you looked at how it works=
 and
> solves some of these issues?

Yes.  I've been looking into it very deeply:

https://web.git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/=
log/?h=3Dceph-iter

I'm not sure which issues you're referring to specifically that you think =
ceph
might have a usable solution, but note that Ceph has the ability to store
extra data, such as the "sparse map" that AFS doesn't have, unfortunately.
It's not easy to extend AFS because the volume transfer protocol/backup
protocol would need to change.

And with regard to filename encryption, the traditional AFS directory form=
at
has a limit on the maximum directory size, so increasing the size of filen=
ames
by a third would be a problem.

> Second, per-block keys would be really inefficient and are unnecessary. =
 The
> way that fscrypt works is that the keys are (usually) per-file, and with=
in
> each file each block has a different IV (initialization vector).  That i=
s
> sufficient to make each block be encrypted differently.

Okay.  Sounds good.

David