Re: [PATCH 00/14] KEYS: Add support for PGP keys and signatures

[Antony Vennard]

Hi All,

On 17/01/2022 16:02, James Bottomley wrote:
> On Mon, 2022-01-17 at 15:34 +0100, Jason A. Donenfeld wrote:
> > Hi,
> >
> > While it looks like you put a lot of work into this patchset, I think
> > the general idea of adding PGP *to the kernel* is a pretty daunting
> > proposition. The general consensus in the crypto engineering world is
> > that PGP ought to be on its way out. We definitely don't want to
> > perpetuate this project-on-life-support into the permanence of kernel
> > code. Some quick Google searches will reveal a litany of blog posts
> > to the tune of, "why oh why are people still using this?" Here's one
> > from 2019:
> > https://latacora.micro.blog/2019/07/16/the-pgp-problem.html . I
> > think these are arguments to take seriously. And even if you disagree
> > with some parts, you may want to consider whether the remaining parts
> > warrant a bit of pause before adding this to the kernel and
> > perpetuating PGP's design further.

So while I understand why this is being proposed and clearly effort has 
gone into it, I also think it is not the right approach. It seems this 
proposal is to include a full PGP packet parser and verification logic 
in the kernel as an equivalent to allow PGP signatures to be submitted 
via FS_IOC_ENABLE_VERITY:

"FS_IOC_ENABLE_VERITY accepts a pointer to a PKCS#7 formatted detached 
signature in DER format of the file’s fs-verity digest."

I may be misinterpreting, but as I understand it logic for X.509/PKCS 
validation already exists in-kernel because of UEFI and module signing, 
so this signature would be verified up to trusted roots. The proposal is 
to duplicate all of this logic but in terms of PGP-formatted keys.

I believe this is unnecessary. Since it seems to require both a 
signature and verification up to a root, and distributions like Fedora 
already deal with x509 module signing keys for their kernel modules, I 
can't see the merit in including the full PGP system too. The 
least-effort approach, I would suggest, is to include an x509 
representation of the signature in the RPM and use the existing API to 
push that up into the kernel, with the trust anchor the same as is used 
for module signing keys, or whatever distributions prefer (they, after 
all, control the kernel trust anchors).

I understand this requires some effort, but so too does maintaining a 
fully fledged PGP packet parser as privileged code for all time, and I 
think maintaining this in userspace is a) easier and b) less costly than 
doing it in kernel. As an added bonus, a PGP-parsing library in a 
memory-safe language could be used in userspace.

A slightly more drastic step would be to wholesale move to PKCS 
signatures for packaging. Linux distributions could be their own trusted 
roots for this purpose if they so desired, and since they control 
certificate bundles anyway they've no need to add them to the browser 
list if that is a concern, and can issue certs without SSL Client/SSL 
Server types and OIDs.

> The reason is simple though: for all the detractors and whining, no-
> one's actually been able to come up with a more usable replacement.
> Very few people who complain about GPG actually submit patches to fix
> it.  A few come up with their own infrastructure which tends to have
> even more problems.

Probably replacing with PKCS is a non-starter, but it is at least 
possible and it is highly likely distros package one or more tools 
capable of validating such signatures in their base installs.

There are multiple problems with PGP that receive complaints. They are:

 1) No forward secrecy in messaging-based crypto.
 2) The data format.
 3) Outdated cryptography still supported.
 4) UX.

Of these, all four could be levelled against PKCS standards and related 
tools too (except TLS protocols for the first point), and only 2 and 3 
are relevant here since we are concerned with signature validation only.

I'm not "against" PGP per se, but I'm not convinced by the idea of 
adding PGP support just for fs-verity.

> > If you're looking for a simple signature mechanism to replace the use
> > of X.509 and all of that infrastructure, may I suggest just coming up
> > with something simple using ed25519,
>
> Please, no, use universally supported crypto that we can use TPM
> hardware for, which for EC currently means P-256.  It may be possible
> to get the TCG and the other security bodies to add Edwards signatures
> but the rate of progression of quantum means that Grover's Algorithm
> will likely get there first and we'll need P-521 or X448.

I agree: whatever is chosen should in my view have decent support for 
hardware-backed keys, because I strongly hope that is what distribution 
key storage looks like. If not I might need to move to Gentoo.

The current RPM signing keys for Fedora are RSA-4096, which in my 
opinion does not actually meet the bar for "good hardware support for 
algorithm". RSA-2048 tokens are common, but 4096 much less so.

Unfortunately for this reason signify/minisign is not ideal as tools: so 
far as I can see it has no support for hardware-backed keys. That's not 
to say they couldn't, although they both use ed25519.

I am not sure if we'll end up in the situation where Grover's algorithm 
is efficient but Shor is not, but this is all guesswork until we get 
closer to a quantum computer with enough logical Qubits. But your 
substantive point I think is valid: hardware vendors are disappointingly 
slow at adopting edwards curves.

> >   similar to signify or minisign? Very minimal code in the kernel, in
> > userspace, and very few moving parts to break.
>
> Heh, this is the classic cryptographers dilemma: go for something
> pejorative which can be minimal but which has only a relatively small
> set of possible use cases and no future proofing or go for something
> extensible which ends up more complex and others then criticize as
> being a "swiss army knife".

I think this is the wrong framing for the problem. We already have one 
extensible system that is complicated in the kernel. This patch proposes 
to add a second one achieving the same purpose instead of a userspace 
solution to take advantage of the existing code, which I think would be 
preferable and safer.

Antony