Re: Is there any userland implementations of fscrypt

Re: Is there any userland implementations of fscrypt

[Eric Biggers]

[+Cc linux-fscrypt]

On Mon, Mar 20, 2023 at 06:49:29PM +0800, Xiubo Li wrote:
> Hi Eric,
> 
> BTW, I am planing to support the fscrypt in userspace ceph client. Is there
> any userland implementation of fscrypt ? If no then what should I use
> instead ?
> 

I assume that you mean userspace code that encrypts files the same way the
kernel does?

There's some code in xfstests that reproduces all the fscrypt encryption for
testing purposes
(https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/src/fscrypt-crypt-util.c?h=for-next).
It does *not* use production-quality implementations of the algorithms, though.
It just has minimal implementations for testing without depending on OpenSSL.

Similar testing code can also be found in Android's vts_kernel_encryption_test
(https://android.googlesource.com/platform/test/vts-testcase/kernel/+/refs/heads/master/encryption).
It uses BoringSSL for the algorithms when possible, but unlike the xfstest it
does not test filenames encryption.

There's also some code in mkfs.ubifs in mtd-utils
(http://git.infradead.org/mtd-utils.git) that supports creating encrypted files.
However, it's outdated since it only supports policy version 1.

Which algorithms do you need to support?  The HKDF-SHA512 + AES-256-XTS +
AES-256-CTS combo shouldn't be hard to support if your program can depend on
OpenSSL (1.1.0 or later).

- Eric

Re: Is there any userland implementations of fscrypt

[Xiubo Li]

On 21/03/2023 05:19, Eric Biggers wrote:
> [+Cc linux-fscrypt]
>
> On Mon, Mar 20, 2023 at 06:49:29PM +0800, Xiubo Li wrote:
>> Hi Eric,
>>
>> BTW, I am planing to support the fscrypt in userspace ceph client. Is there
>> any userland implementation of fscrypt ? If no then what should I use
>> instead ?
>>
> I assume that you mean userspace code that encrypts files the same way the
> kernel does?

Yeah, a library just likes the fs/crypto/ in kernel space.

I found the libkcapi, Linux Kernel Crypto API User Space Interface 
Library(http://www.chronox.de/libkcapi.html)  seems exposing the APIs 
from crypto/ not the fs/crypto/.

> There's some code in xfstests that reproduces all the fscrypt encryption for
> testing purposes
> (https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/src/fscrypt-crypt-util.c?h=for-next).
> It does *not* use production-quality implementations of the algorithms, though.
> It just has minimal implementations for testing without depending on OpenSSL.

This is performed in software.

> Similar testing code can also be found in Android's vts_kernel_encryption_test
> (https://android.googlesource.com/platform/test/vts-testcase/kernel/+/refs/heads/master/encryption).
> It uses BoringSSL for the algorithms when possible, but unlike the xfstest it
> does not test filenames encryption.

This too.

> There's also some code in mkfs.ubifs in mtd-utils
> (http://git.infradead.org/mtd-utils.git) that supports creating encrypted files.
> However, it's outdated since it only supports policy version 1.
>
> Which algorithms do you need to support?  The HKDF-SHA512 + AES-256-XTS +
> AES-256-CTS combo shouldn't be hard to support if your program can depend on
> OpenSSL (1.1.0 or later).

Yeah, ceph has already depended on the OpenSSL.

I think the OpenSSL will be the best choice for now.

Thanks Eric,

- Xiubo


> - Eric
>

Re: Is there any userland implementations of fscrypt

[Eric Biggers]

On Tue, Mar 21, 2023 at 09:03:02AM +0800, Xiubo Li wrote:
> On 21/03/2023 05:19, Eric Biggers wrote:
> > [+Cc linux-fscrypt]
> > 
> > On Mon, Mar 20, 2023 at 06:49:29PM +0800, Xiubo Li wrote:
> > > Hi Eric,
> > > 
> > > BTW, I am planing to support the fscrypt in userspace ceph client. Is there
> > > any userland implementation of fscrypt ? If no then what should I use
> > > instead ?
> > > 
> > I assume that you mean userspace code that encrypts files the same way the
> > kernel does?
> 
> Yeah, a library just likes the fs/crypto/ in kernel space.
> 
> I found the libkcapi, Linux Kernel Crypto API User Space Interface
> Library(http://www.chronox.de/libkcapi.html)  seems exposing the APIs from
> crypto/ not the fs/crypto/.

Much of fs/crypto/ is tightly coupled to how the Linux kernel implements
filesystems, so I'm not sure what you are expecting exactly!  The actual
cryptography can definitely be replicated in userspace, though.

> > There's some code in xfstests that reproduces all the fscrypt encryption for
> > testing purposes
> > (https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/src/fscrypt-crypt-util.c?h=for-next).
> > It does *not* use production-quality implementations of the algorithms, though.
> > It just has minimal implementations for testing without depending on OpenSSL.
> 
> This is performed in software.
> 
> > Similar testing code can also be found in Android's vts_kernel_encryption_test
> > (https://android.googlesource.com/platform/test/vts-testcase/kernel/+/refs/heads/master/encryption).
> > It uses BoringSSL for the algorithms when possible, but unlike the xfstest it
> > does not test filenames encryption.
> 
> This too.

So you are looking for something that is *not* performed in software?  What do
you mean by that, exactly?  Are you looking to use an off-CPU hardware crypto
accelerator?  The Linux kernel exposes those to userspace through AF_ALG.
Though, it's worth noting that that style of crypto acceleration has fallen a
bit out of favor these days, as modern CPUs have crypto instructions built-in.

> > There's also some code in mkfs.ubifs in mtd-utils
> > (http://git.infradead.org/mtd-utils.git) that supports creating encrypted files.
> > However, it's outdated since it only supports policy version 1.
> > 
> > Which algorithms do you need to support?  The HKDF-SHA512 + AES-256-XTS +
> > AES-256-CTS combo shouldn't be hard to support if your program can depend on
> > OpenSSL (1.1.0 or later).
> 
> Yeah, ceph has already depended on the OpenSSL.
> 
> I think the OpenSSL will be the best choice for now.

That seems like the right choice.  Note that that is "software" too, but I think
that's what you want!

- Eric