Hi Roberto,
On 28.04.2023 16:16, Roberto Sassu wrote:
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).
This is definitely what Sequoia can be used for. Actually the parsing part is a large part of the codebase. Take a look here:
https://docs.rs/sequoia-openpgp/latest/sequoia_openpgp/parse/trait.Parse.htm...
Things can be parsed into their respective data types, e.g. for example this one for public keys:
https://docs.rs/sequoia-openpgp/latest/sequoia_openpgp/crypto/mpi/enum.Publi...
It'd be good if you had a concrete "input/expected-output" examples then we can assist you in writing small proof of concepts that do exactly that. (The other route is exploring Sequoia's extensive test suite).
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.
Currently Sequoia supports a number of cryptographic backends (for full list see: https://gitlab.com/sequoia-pgp/sequoia/-/tree/main/openpgp#crypto-backends ). Adding Kernel Crypto API would be yet another backend. This is doable in practice, it's never brought into question (related: https://gitlab.com/sequoia-pgp/sequoia/-/issues/333).
Not sure if there's a Rust crate that already exposes some kind of API or whether that would be part of the task. (For time-complexity estimation note that adding OpenSSL backend took me ~3 months).
What do you think?
For me it looks like a very nice idea. Do you have any further resources we could read to get familiar with Kernel Crypto API and the user-space parsing part?
Have a nice day!
Kind regards, Wiktor