I'm following the discussion of using Sequoia PGP for rpm.
Recently, I submitted a patch set for the kernel to support new keys
and signature formats transparently. Parsing those formats is offloaded
to user space. The kernel gets from user space only minimal
information: the public key or signature, the algorithm, the key
This is the link of the patch set:
I was wondering if Sequoia PGP can be used on user space side. It gets
the key or signature blob, parses them, and replies to the kernel with
the information the latter needs.
I had a brief look at the documentation of the openpgp crate, and maybe
it could be done, but I don't have a precise idea.
Just wanted to ask your opinion on this, as the part of Sequoia PGP I
would need is very minimal (the parsing part). Also the binary itself
should be statically linked (I aim to execute it early in the boot to
load the GPG keys of the Linux distribution to the kernel).
Another point would be to avoid external dependencies, like a crypto
library, and to use the kernel Crypto API instead (through
socket(AF_ALG) in user space). Not the highest priority (as it would
require to rewrite some parts of your library), but nice to have.
What do you think?
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 . 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  that the patches
that they proposed for inclusion in the kernel  were not merged.
I looked up the relevant thread , 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 .
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.
Thank you for your time!