Devel August 2023

devel@lists.sequoia-pgp.org

1 participants
2 discussions

Minimal PGP implementation for kernel keys
by Roberto Sassu 10 Aug '23

10 Aug '23

Hi everyone 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 fingerprint, etc. This is the link of the patch set: https://lore.kernel.org/bpf/20230425173557.724688-1-roberto.sassu@huaweiclo… 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? Thanks Roberto

3 9

Kernel Crypto exposing asymmetric operations to userland via libkcapi
by Wiktor Kwapisiewicz 10 Aug '23

10 Aug '23

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. Thank you for your time! Kind regards, Wiktor [0]: https://gitlab.com/sequoia-pgp/sequoia/-/issues/1030 [1]: https://lists.sequoia-pgp.org/hyperkitty/list/devel@lists.sequoia-pgp.org/t… [2]: https://github.com/smuellerDD/libkcapi/issues/164 [3]: https://github.com/smuellerDD/libkcapi/blob/master/kernel-patches/4.15-rc3/… [4]: https://lkml.kernel.org/lkml/9859277.cZClo5B21s@tauon.atsec.com/T/#m0dfdbd3… [5]: https://gitlab.com/sequoia-pgp/sequoia-keystore

2 2

2024

2023

2022

2021

2020

2019

2018

Devel August 2023