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

[James Bottomley]

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.

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.

> 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.

>  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".

James