On Thu, 27 Jul 2023 at 14:59, Wiktor Kwapisiewicz wiktor@metacode.biz wrote:

Hi Kernel Crypto folks,

I've got a question about the Kernel Crypto API.

I'm working on adding a cryptographic backend based on the Kernel Crypto API to Sequoia PGP [0][1]. Sequoia supports several cryptographical backends already but using Kernel Crypto would allow us to significantly reduce dependencies when running on Linux.

After implementing hashes, AEAD encryption and symmetric ciphers, I noticed that the libkcapi API for asymmetric ciphers (and ECDH) is not working. The libkcapi maintainer kindly explained [2] that the patches that they proposed for inclusion in the kernel [3] were not merged.

I looked up the relevant thread [4], read it thoroughly and from what I can see most of the arguments are about private keys not being sufficiently protected and extensibility concerns with regards to keys stored in hardware security modules (TPMs etc.).

However, these are mostly irrelevant to the Sequoia PGP use case, since private keys in software that we read do not need additional protection (as they are available for software anyway). We'd still like to use them for signing, decryption, verification and encryption. As for keys stored in HSMs we handle access to them in userland via our keystore module [5].

My question is: Would it be possible to revisit the decision to expose operations with asymmetric keys (including ECDH) in Linux Crypto thus allowing libkcapi to work with non-patched kernels?

I'd like to help make this happen and I think there are other projects that are interested in a complete cryptographic suite of Kernel Crypto functions available in user-land.

AF_ALG was never intended to provide a general purpose crypto library to user space, but only to expose asynchronous hardware crypto accelerators that are DMA based and managed by the OS.

Exposing the pure-software crypto implementations via AF_ALG was a mistake IMHO. Making system calls into a privileged environment just to run some algorithm that could easily run unprivileged as well is a bad idea both for performance as well as for security/robustness. (On top of that, SIMD based implementations need to execute with preemption disabled, increasing scheduling jitter)

Due to the kernel's rigid 'no regressions' policy, AF_ALG will retain support for the modes and algorithms it supports today, but I don't think we should extend this support unless we limit it to implementations provided by hardware accelerators. If it can be done in software, it should be done in user space, not in the kernel.