| Message ID | 20220111180318.591029-1-roberto.sassu@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | KEYS: Add support for PGP keys and signatures | expand |
On 11.01.2022 19:03, Roberto Sassu wrote: > Support for PGP keys and signatures was proposed by David long time ago, > before the decision of using PKCS#7 for kernel modules signatures > verification was made. After that, there has been not enough interest to > support PGP too. > > Lately, when discussing a proposal of introducing fsverity signatures in > Fedora [1], developers expressed their preference on not having a separate > key for signing, which would complicate the management of the distribution. > They would be more in favor of using the same PGP key, currently used for > signing RPM headers, also for file-based signatures (not only fsverity, but > also IMA ones). Aren't PGP keys simply RSA / ECC / EdDSA keys with additional metadata? Can't they be unwrapped from their (complex) PGP format in userspace and loaded raw into the kernel, in a similar way as they are sometimes used for SSH authentication? This will save us from having to add complex parsers (a well-known source of bugs) into the kernel - I guess there aren't any plans to add an in-kernel PGP Web of Trust implementation. Thanks, Maciej
> From: Maciej S. Szmigiero [mailto:mail@maciej.szmigiero.name] > Sent: Tuesday, January 11, 2022 9:33 PM > On 11.01.2022 19:03, Roberto Sassu wrote: > > Support for PGP keys and signatures was proposed by David long time ago, > > before the decision of using PKCS#7 for kernel modules signatures > > verification was made. After that, there has been not enough interest to > > support PGP too. > > > > Lately, when discussing a proposal of introducing fsverity signatures in > > Fedora [1], developers expressed their preference on not having a separate > > key for signing, which would complicate the management of the distribution. > > They would be more in favor of using the same PGP key, currently used for > > signing RPM headers, also for file-based signatures (not only fsverity, but > > also IMA ones). > > Aren't PGP keys simply RSA / ECC / EdDSA keys with additional metadata? > Can't they be unwrapped from their (complex) PGP format in userspace and > loaded raw into the kernel, in a similar way as they are sometimes used > for SSH authentication? Probably, this would be possible by introducing a new asymmetric key subtype parsing PGP keys and signatures in a more simple format, after conversion by user space. But still, a parser would be required. To be honest, I would prefer to implement (actually David did) a parser following an RFC, than developing a new one. > This will save us from having to add complex parsers (a well-known source > of bugs) into the kernel - I guess there aren't any plans to add an > in-kernel PGP Web of Trust implementation. I extensively tested the implementation with an ad-hoc fault injector, to see if the code can correctly handle errors. I also developed a fuzzer to corrupt the data before it is read by the kernel. Finally, I checked that there are not memory leaks. But I agree, there could still be bugs. If you mean that a key can be added to the kernel if is vouched for by another key in the built-in keyring, I actually implemented this (was missing in the original implementation). Some keyrings, e.g. .ima, have this restriction. The way this works is that, whenever you add a PGP key to the kernel, the parser takes not only the public key and the user ID, but also its signature by the same or another PGP key. The signature is verified when the key is added to the keyring with that restriction, and only if the verification is successful the key can be added. Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua > Thanks, > Maciej
On 12.01.2022 10:16, Roberto Sassu wrote: >> From: Maciej S. Szmigiero [mailto:mail@maciej.szmigiero.name] >> Sent: Tuesday, January 11, 2022 9:33 PM >> On 11.01.2022 19:03, Roberto Sassu wrote: >>> Support for PGP keys and signatures was proposed by David long time ago, >>> before the decision of using PKCS#7 for kernel modules signatures >>> verification was made. After that, there has been not enough interest to >>> support PGP too. >>> >>> Lately, when discussing a proposal of introducing fsverity signatures in >>> Fedora [1], developers expressed their preference on not having a separate >>> key for signing, which would complicate the management of the distribution. >>> They would be more in favor of using the same PGP key, currently used for >>> signing RPM headers, also for file-based signatures (not only fsverity, but >>> also IMA ones). >> >> Aren't PGP keys simply RSA / ECC / EdDSA keys with additional metadata? >> Can't they be unwrapped from their (complex) PGP format in userspace and >> loaded raw into the kernel, in a similar way as they are sometimes used >> for SSH authentication? > > Probably, this would be possible by introducing a new asymmetric > key subtype parsing PGP keys and signatures in a more simple format, > after conversion by user space. But still, a parser would be required. > To be honest, I would prefer to implement (actually David did) a > parser following an RFC, than developing a new one. A parser in userspace is preferred to one in kernel since if there is a bug somewhere its consequences are much less severe. And experience shows that parsers are especially prone to bugs. A userspace implementation can also be tightly sandboxed for extra security. There are many existing OpenPGP parsing libraries to choose from. >> This will save us from having to add complex parsers (a well-known source >> of bugs) into the kernel - I guess there aren't any plans to add an >> in-kernel PGP Web of Trust implementation. > > I extensively tested the implementation with an ad-hoc fault injector, > to see if the code can correctly handle errors. I also developed a > fuzzer to corrupt the data before it is read by the kernel. Finally, > I checked that there are not memory leaks. But I agree, there could > still be bugs. > > If you mean that a key can be added to the kernel if is vouched for > by another key in the built-in keyring, I actually implemented this > (was missing in the original implementation). Some keyrings, e.g. .ima, > have this restriction. > > The way this works is that, whenever you add a PGP key to the > kernel, the parser takes not only the public key and the user ID, > but also its signature by the same or another PGP key. > > The signature is verified when the key is added to the keyring > with that restriction, and only if the verification is successful > the key can be added. I understand but it would be great to make use as much as possible of the existing in-kernel signature verification mechanisms. > Roberto Thanks, Maciej
> From: Maciej S. Szmigiero [mailto:mail@maciej.szmigiero.name] > Sent: Wednesday, January 12, 2022 9:16 PM > On 12.01.2022 10:16, Roberto Sassu wrote: > >> From: Maciej S. Szmigiero [mailto:mail@maciej.szmigiero.name] > >> Sent: Tuesday, January 11, 2022 9:33 PM > >> On 11.01.2022 19:03, Roberto Sassu wrote: > >>> Support for PGP keys and signatures was proposed by David long time ago, > >>> before the decision of using PKCS#7 for kernel modules signatures > >>> verification was made. After that, there has been not enough interest to > >>> support PGP too. > >>> > >>> Lately, when discussing a proposal of introducing fsverity signatures in > >>> Fedora [1], developers expressed their preference on not having a separate > >>> key for signing, which would complicate the management of the > distribution. > >>> They would be more in favor of using the same PGP key, currently used for > >>> signing RPM headers, also for file-based signatures (not only fsverity, but > >>> also IMA ones). > >> > >> Aren't PGP keys simply RSA / ECC / EdDSA keys with additional metadata? > >> Can't they be unwrapped from their (complex) PGP format in userspace and > >> loaded raw into the kernel, in a similar way as they are sometimes used > >> for SSH authentication? > > > > Probably, this would be possible by introducing a new asymmetric > > key subtype parsing PGP keys and signatures in a more simple format, > > after conversion by user space. But still, a parser would be required. > > To be honest, I would prefer to implement (actually David did) a > > parser following an RFC, than developing a new one. > > A parser in userspace is preferred to one in kernel since if there is > a bug somewhere its consequences are much less severe. > And experience shows that parsers are especially prone to bugs. > A userspace implementation can also be tightly sandboxed for extra > security. > > There are many existing OpenPGP parsing libraries to choose from. I understand your point. However, it does not seem to me less risky to define a new format to upload the RSA key and the signature to avoid the complexity of PGP. Also, it does not seem more complex than PKCS#7, which is already in the kernel. In addition, there are aspects of PGP that anyway have to be taken into account. One example is the digest calculation, which depends also on the PGP packet. Whenever the kernel verifies the signature, the additional data need to be appended to the original data. This risks to create more confusion, as the consumer of the data being verified might not be prepared to handle the additional data required for signature verification. The kernel has already a well-defined way to process data with a signature. It expects a data structure called module_signature at the end of the data to verify, which include information required for the verification such as the digest algorithm, key ID, etc. It also has a selector called PKEY_ID_PGP, so that the code would handle a PGP signature. This data structure does not include space for the additional data required for the signature verification. This patch set instead offers the new function verify_pgp_signature(), which takes the same arguments as verify_pkcs7_signature(), and can be used as in the example I mentioned above in a switch() where the selector is the signature type. This patch set also offers the individual functions called inside verify_pgp_signature(), to support the case where the signature verification process is split in multiple parts (e.g. security/integrity/ima/ima_modsig.c). Also in this case, the arguments passed to the PGP-related functions are similar to the PKCS#7 ones. Another concern that I have is that, the approach of using an OpenPGP library still requires the Linux distribution vendors to do a transformation from the source data they have to another format. They have anyway to certify this transformation, even if it is done in user space. Maybe it is easier to keep the original data and verify the minimum necessary to handle PGP keys and signature in the kernel, rather than verifying a library running in user space with many other functions. > >> This will save us from having to add complex parsers (a well-known source > >> of bugs) into the kernel - I guess there aren't any plans to add an > >> in-kernel PGP Web of Trust implementation. > > > > I extensively tested the implementation with an ad-hoc fault injector, > > to see if the code can correctly handle errors. I also developed a > > fuzzer to corrupt the data before it is read by the kernel. Finally, > > I checked that there are not memory leaks. But I agree, there could > > still be bugs. > > > > If you mean that a key can be added to the kernel if is vouched for > > by another key in the built-in keyring, I actually implemented this > > (was missing in the original implementation). Some keyrings, e.g. .ima, > > have this restriction. > > > > The way this works is that, whenever you add a PGP key to the > > kernel, the parser takes not only the public key and the user ID, > > but also its signature by the same or another PGP key. > > > > The signature is verified when the key is added to the keyring > > with that restriction, and only if the verification is successful > > the key can be added. > > I understand but it would be great to make use as much as possible of > the existing in-kernel signature verification mechanisms. Yes. I think this is the purpose of the asymmetric subtypes. They introduce a parser for the specific format, but once the relevant information are extracted, the in-kernel mechanisms are used. Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua > > Roberto > > Thanks, > Maciej
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. 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, similar to signify or minisign? Very minimal code in the kernel, in userspace, and very few moving parts to break. Jason
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
> From: Jason A. Donenfeld [mailto:Jason@zx2c4.com] > Sent: Monday, January 17, 2022 3:35 PM > 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. Hi Jason thanks a lot for the additional information. They could make people more aware of the risks so that they transition to more secure schemes. The problem is that I don't see that transition coming soon. Transition from PGP to another scheme would require Linux distribution vendors to do an huge amount of work. It could probably take years before that transition occurs. More specifically, the first task would be to modify how RPMs are signed (and thus how they are verified). The second task would be to have a different way to certify the public key. Lastly, Linux distribution vendors would have to change their building infrastructure to use the new certified key, a new version of the rpm package manager which takes as input the new key, produces a different type of signature and embeds it in the RPM header. In this discussion: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JE2HGLJMLEKUJW3YBP6MQJWP43CSTC57/ people were concerned about the lifecycle of the secondary key used for fsverity signatures. Likely, completely replacing the key infrastructure would raise even bigger concerns. The aim of this patch set is to make some security features available in a short time, by significantly reducing the burden of Linux distribution vendors for managing those security features. I mentioned fsverity, but my primary use case would be for DIGLIM (extract reference values for file digests from RPM headers and use them for IMA measurement or appraisal). The main advantage of this patch set, at least for DIGLIM, is that it completely removes the need of changing the building infrastructure. To show the DIGLIM benefits, I retrofitted two already released Linux distributions (Fedora 34 and openSUSE Leap 15.3) with DIGLIM and the necessary changes in IMA, so that they prevent the execution of binaries and shared libraries which were not released by the distribution (the mechanism is completely configurable by the user to trust his binaries, if he wishes to). If you are interested, here is the link of the demo I developed: https://lore.kernel.org/linux-integrity/48cd737c504d45208377daa27d625531@huawei.com/ If in the future the transition from PGP to another scheme occurs, support for PGP keys and signatures can be still deprecated. Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua > 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, similar to signify or minisign? Very > minimal code in the kernel, in userspace, and very few moving parts to > break. > > Jason
On Mon, Jan 17, 2022 at 03:34:54PM +0100, Jason A. Donenfeld wrote: > 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, similar to signify or minisign? Very > minimal code in the kernel, in userspace, and very few moving parts to > break. I am concerned that ed25519 private key management is very rudimentary -- more often than not it is just kept somewhere on disk, often without any passphrase encryption. With all its legacy warts, GnuPG at least has decent support for hardware off-load via OpenPGP smartcards or TPM integration in GnuPG 2.3, but the best we have with ed25519 is passhprase protection as implemented in minisign (and even that is rudimentary -- if you need to sign 10 things, you will need to type in your passphrase 10 times, as there is no passphrase agent of any kind). The most promising non-PGP development of PKI signatures that I've seen lately is the openssh FIDO2 integration (the -sk keys) and support for signing/verifying arbitrary external content using `ssh-keygen -n`. It even does fairly sane things with identity/revocation/expiration via its allowed_signers implementation, even if I'm less excited about it all being in a single file. Everything else is just treating key management as something out of scope, and I'm worried that it's going to result in a net loss in overall security. -K
On Mon, Jan 17, 2022 at 11:59:33AM -0500, Konstantin Ryabitsev wrote: > The most promising non-PGP development of PKI signatures that I've seen lately > is the openssh FIDO2 integration (the -sk keys) and support for > signing/verifying arbitrary external content using `ssh-keygen -n`. It even Typo fix: that should be `ssh-keygen -Y` -K
On 17.01.2022 17:59, Konstantin Ryabitsev wrote: > On Mon, Jan 17, 2022 at 03:34:54PM +0100, Jason A. Donenfeld wrote: >> 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, similar to signify or minisign? Very >> minimal code in the kernel, in userspace, and very few moving parts to >> break. > > I am concerned that ed25519 private key management is very rudimentary -- more > often than not it is just kept somewhere on disk, often without any passphrase > encryption. > > With all its legacy warts, GnuPG at least has decent support for hardware > off-load via OpenPGP smartcards or TPM integration in GnuPG 2.3, but the best > we have with ed25519 is passhprase protection as implemented in minisign (and I am not sure that I understood your point here correctly, but GnuPG already supports ed25519 keys, including stored on a smartcard - for example, on a YubiKey [1]. While the current software support for ed25519 might be limited, there is certainly progress being made, RFC 8410 allowed these algos for X.509 certificates. Support for such certificates is already implemented in OpenSSL [2]. ECDSA, on the other hand, is very fragile with respect to random number generation at signing time. We know that people got burned here in the past. Thanks, Maciej [1]: https://developers.yubico.com/PGP/YubiKey_5.2.3_Enhancements_to_OpenPGP_3.4.html [2]: https://blog.pinterjann.is/ed25519-certificates.html
On Mon, Jan 17, 2022 at 09:59:22PM +0100, Maciej S. Szmigiero wrote: > > I am concerned that ed25519 private key management is very rudimentary -- more > > often than not it is just kept somewhere on disk, often without any passphrase > > encryption. > > > > With all its legacy warts, GnuPG at least has decent support for hardware > > off-load via OpenPGP smartcards or TPM integration in GnuPG 2.3, but the best > > we have with ed25519 is passhprase protection as implemented in minisign (and > > I am not sure that I understood your point here correctly, but GnuPG > already supports ed25519 keys, including stored on a smartcard - for > example, on a YubiKey [1]. Yes, I know, but you cannot use ed25519-capable OpenPGP smartcards to create non-PGP signatures. The discussion was about using ed25519 signatures directly (e.g. like signify/minisign do). Jason pointed out to me on IRC that it's possible to do it with YubiHSM, but it's an expensive device ($650 USD from Yubico). > While the current software support for ed25519 might be limited, there > is certainly progress being made, RFC 8410 allowed these algos for X.509 > certificates. > Support for such certificates is already implemented in OpenSSL [2]. > > ECDSA, on the other hand, is very fragile with respect to random number > generation at signing time. > We know that people got burned here in the past. I think this is taking us far away from the main topic (which signing/verification standards to use in-kernel). -K
Hi Roberto, Thanks for your detailed reply. On Mon, Jan 17, 2022 at 4:21 PM Roberto Sassu <roberto.sassu@huawei.com> wrote: > The problem is that I don't see that transition coming soon. > Transition from PGP to another scheme would require Linux > distribution vendors to do an huge amount of work. It could > probably take years before that transition occurs. > More specifically, the first task would be to modify how > RPMs are signed (and thus how they are verified). The second > task would be to have a different way to certify the public key. > Lastly, Linux distribution vendors would have to change their > building infrastructure to use the new certified key, a new > version of the rpm package manager which takes as input > the new key, produces a different type of signature and embeds > it in the RPM header. Hm, yea, I see your dilemma. On the one hand, you recognize the problems with what currently exists. On the other hand, you[r organization] hasn't made the transition to something better. So, rather than putting in what might be a lot of work to transition to something better (which includes actually evaluating *what* the better thing would be), you'd prefer to put in a smaller amount of work to make the current thing satisfy some of your needs, even though you recognize its flaws. It seems like this is one of those "short term" vs "long term" investment tradeoffs. I don't have a whole lot _technical_ to say about long term vs short term thinking, but it does strike me that PGP is one of these cases where people have known about the flaws for decades, but the ecosystem keeps being extended because people continue to go with the short term solutions, one by one, and now they've wound up here, at the doorstep of the kernel. Maybe if at some point somebody puts down the foot and says, "the road of short term intentions stops here," there might gradually be impetus toward looking into long term solutions, e.g. viable PGP replacements? Just a thought. > If in the future the transition from PGP to another scheme > occurs, support for PGP keys and signatures can be still > deprecated. Things in the kernel rarely disappear. At best, they become subtly neglected, and then somebody gets bit by some security bug. At worst, we're stuck maintaining a PGP implementation until the end of eternity. On the technical front, though, I had sort of the same thought as Maciej: is there some way that you can unwrap the PGP data in userspace, and re-encode it in ASN.1, and somehow magically account for the various metadata included in the signatures? The devil here might be in the details, and I'm not sure whether it's feasible. But if it is, this would seem to be a much nicer solution. I'm not the hugest fan of having an ASN.1 parser in the kernel either, but it's _already_ there, and if you could somehow piggyback on top of it, that means we'd be able to avoid importing this PGP implementation. Concretely, it looks like the hardest part of this is the fact that pgp_digest_signature seems to hash in some PGP-specific metadata, not just the raw data. Am I reading that right, and that's the case? If so, that might spell trouble. You also mentioned in that other thread the possibility of using a new/custom PGP packet type for this? Is the idea there that you'd come up with something that could be unwrapped into an ASN.1-verifable blob, as a custom extension of PGP that distros could then distribute? Jason
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
On Tue, Jan 18, 2022 at 09:50:21PM +0100, Antony Vennard wrote: > > 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." > It's worth noting that if fs-verity built-in signatures are used, a trusted userspace program is still required to determine and enforce the policy of which files are required to be signed. The kernel only handles the actual signature verification. This was basically a proof-of-concept which reused the kernel's module signature verification code (which happens to use PKCS#7). I'd encourage new users to either go all-in on a userspace solution, using a trusted userspace program to verify signatures of fs-verity file digests; *or* go all-in on an in-kernel solution, using the IMA support for fs-verity which Mimi Zohar is working on. A userspace solution could use a simple signature format, using a modern algorithm such as Ed25519. IMA uses a simple signature format too, though it uses a complex format (X.509) for public keys. - Eric
> From: Antony Vennard [mailto:antony@vennard.ch] > Sent: Tuesday, January 18, 2022 9:50 PM > 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 One of the problems, but I need to verify that, is that the key used for signing kernel modules might be available only when the kernel package is built. The GPG key should be available for every RPM. If the GPG key is the only available, then probably the least-effort option would be to load the GPG key as it is. Or you have to create a dummy, unsigned X509 certificate with the public key extracted from the GPG key. The other option I mentioned in this discussion was to introduce a simple format to upload the key to the kernel, which still does not eliminate the risks due to parsing data. In addition to that, there is the problem of maintaining the correct key IDs. If you create a dummy X509 certificate, this means calculating a new ID and using them in the signatures. The last problem of trying to reuse the GPG key and convert it to a dummy X509 certificate is that the keyring restriction will not work. IMA and EVM keyrings requires that the key being added is signed with one of the keys in the built-in or secondary keyring. With the dummy X509 certificate, using those keyrings would not be possible. Maybe you could include the signature in the X509 certificate, but you probably would not be able to calculate the digest for verifying the signature in the same way PGP does. > 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). It could be even easier. IMA has already a very simple signature format. However, the main problem is the management of the keys required to verify the signatures. After several iterations, trying to remove anything that was not essential from the patch set, I came to the conclusion that having the logic for both the keys and the signatures was the best compromise. True, it means more maintenance effort for the kernel, but this ensures the best interoperability with the current ecosystem. I think the code is not particularly complicated that would be impractical to review. > 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. It just needs to parse the key, user ID and the signature packet and subpackets. Consider also that after parsing, nothing about PGP remains in the kernel. The asymmetric key type maintains just the public key, the key ID and the signature of the key (optionally). > 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. We are using PGP just for a very specific purpose, verifying signatures. Outdated cryptography could be disabled, if we wish. > 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. Sorry, I think that forcing all Linux distributions to do it seems unrealistic. Parsing data in the PGP format seems to be the only barrier. Once we are confident that we parse this small number of packets correctly, the rest is just reusing the mechanisms already in place. And we make it easier for people to adopt security features. Thanks Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
> From: Eric Biggers [mailto:ebiggers@kernel.org] > Sent: Wednesday, January 19, 2022 12:04 AM > On Tue, Jan 18, 2022 at 09:50:21PM +0100, Antony Vennard wrote: > > > > 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." > > > > It's worth noting that if fs-verity built-in signatures are used, a trusted > userspace program is still required to determine and enforce the policy of which > files are required to be signed. The kernel only handles the actual signature > verification. This was basically a proof-of-concept which reused the kernel's > module signature verification code (which happens to use PKCS#7). Just to show how the fsverity code will look like after adding support for PGP signatures: + switch (vi->type) { + case PKEY_ID_PKCS7: + err = verify_pkcs7_signature(d, sizeof(*d) + hash_alg->digest_size, + signature, sig_size, fsverity_keyring, + VERIFYING_UNSPECIFIED_SIGNATURE, + NULL, NULL); + break; + case PKEY_ID_PGP: + err = verify_pgp_signature(d, sizeof(*d) + hash_alg->digest_size, + signature, sig_size, fsverity_keyring, + VERIFYING_UNSPECIFIED_SIGNATURE, + NULL, NULL); + break; + default: + err = -EOPNOTSUPP; + } As you can see, the change will be straightforward. On user space side, I plan to add the capability to fsverity-utils to produce a PGP signature with the GPG key passed by rpmsign. > I'd encourage new users to either go all-in on a userspace solution, using a > trusted userspace program to verify signatures of fs-verity file digests; > *or* go all-in on an in-kernel solution, using the IMA support for fs-verity > which Mimi Zohar is working on. A userspace solution could use a simple Probably, there is also the third option of an LSM (such as IPE) that gets from fsverity the information if the signature was validated, and decide depending on a policy. I would also expose the information about the restriction imposed on the keyring from which the key used to verify the signature was found. Maybe IMA could use this approach too, which would avoid the need of introducing another signature format. If that is desired, you might want to coordinate with the authors of a Fedora feature: https://fedoraproject.org/wiki/Changes/FsVerityRPM which, as far as I know, plan to use the signature format already upstreamed. Thanks Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua > signature format, using a modern algorithm such as Ed25519. IMA uses a simple > signature format too, though it uses a complex format (X.509) for public keys. > > - Eric
> From: Roberto Sassu [mailto:roberto.sassu@huawei.com] > Sent: Wednesday, January 19, 2022 2:25 PM > > From: Eric Biggers [mailto:ebiggers@kernel.org] > > Sent: Wednesday, January 19, 2022 12:04 AM > > On Tue, Jan 18, 2022 at 09:50:21PM +0100, Antony Vennard wrote: > > > > > > 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." > > > > > > > It's worth noting that if fs-verity built-in signatures are used, a trusted > > userspace program is still required to determine and enforce the policy of > which > > files are required to be signed. The kernel only handles the actual signature > > verification. This was basically a proof-of-concept which reused the kernel's > > module signature verification code (which happens to use PKCS#7). > > Just to show how the fsverity code will look like after adding support > for PGP signatures: > > + switch (vi->type) { > + case PKEY_ID_PKCS7: > + err = verify_pkcs7_signature(d, sizeof(*d) + hash_alg->digest_size, > + signature, sig_size, fsverity_keyring, > + VERIFYING_UNSPECIFIED_SIGNATURE, > + NULL, NULL); > + break; > + case PKEY_ID_PGP: > + err = verify_pgp_signature(d, sizeof(*d) + hash_alg->digest_size, > + signature, sig_size, fsverity_keyring, > + VERIFYING_UNSPECIFIED_SIGNATURE, > + NULL, NULL); > + break; > + default: > + err = -EOPNOTSUPP; > + } > > As you can see, the change will be straightforward. > > On user space side, I plan to add the capability to fsverity-utils > to produce a PGP signature with the GPG key passed by rpmsign. At the end, it was not necessary. With this patch set, rpmsign is able to produce a PGP signature without modifications to fsverity-utils: https://github.com/robertosassu/rpm/commits/fsverity-gpg-v1 The modifications are very minimal, basically consist in introducing the new function rpmVeritySignFileGPG() that creates a file with the fsverity_formatted_digest structure, and signs it with the exposed function makeGPGSignatureArgs(). The fsverity rpm plugin works without modification, and the kernel takes care of the verification of the PGP signatures when a package is installed. I wrote a more detailed procedure to sign and install a package with fsverity signatures in the PGP format. It can be found here: https://www.spinics.net/lists/fedora-devel/msg296562.html Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua > > I'd encourage new users to either go all-in on a userspace solution, using a > > trusted userspace program to verify signatures of fs-verity file digests; > > *or* go all-in on an in-kernel solution, using the IMA support for fs-verity > > which Mimi Zohar is working on. A userspace solution could use a simple > > Probably, there is also the third option of an LSM (such as IPE) that gets > from fsverity the information if the signature was validated, and decide > depending on a policy. I would also expose the information about the > restriction imposed on the keyring from which the key used to verify > the signature was found. > > Maybe IMA could use this approach too, which would avoid the need > of introducing another signature format. If that is desired, you might > want to coordinate with the authors of a Fedora feature: > > https://fedoraproject.org/wiki/Changes/FsVerityRPM > > which, as far as I know, plan to use the signature format already > upstreamed. > > Thanks > > Roberto > > HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 > Managing Director: Li Peng, Zhong Ronghua > > > signature format, using a modern algorithm such as Ed25519. IMA uses a > simple > > signature format too, though it uses a complex format (X.509) for public keys. > > > > - Eric
On 19/01/2022 00:03, Eric Biggers wrote: > On Tue, Jan 18, 2022 at 09:50:21PM +0100, Antony Vennard wrote: >> >> Hi All, > It's worth noting that if fs-verity built-in signatures are used, a trusted > userspace program is still required to determine and enforce the policy of which > files are required to be signed. The kernel only handles the actual signature > verification. This was basically a proof-of-concept which reused the kernel's > module signature verification code (which happens to use PKCS#7). > > I'd encourage new users to either go all-in on a userspace solution, using a > trusted userspace program to verify signatures of fs-verity file digests; > *or* go all-in on an in-kernel solution, using the IMA support for fs-verity > which Mimi Zohar is working on. A userspace solution could use a simple > signature format, using a modern algorithm such as Ed25519. IMA uses a simple > signature format too, though it uses a complex format (X.509) for public keys. FWIW I checked some of the options for hardware key storage. Thales HSMs support Ed25519, at least according to their marketing materials. Similarly Javacard 3.1 supports (will support) X/Ed 25519/448, so when tokens supporting this emerge (if they haven't already) hardware support for modern algorithms should exist too. I therefore agree. Use Ed25519. Antony
Support for PGP keys and signatures was proposed by David long time ago, before the decision of using PKCS#7 for kernel modules signatures verification was made. After that, there has been not enough interest to support PGP too. Lately, when discussing a proposal of introducing fsverity signatures in Fedora [1], developers expressed their preference on not having a separate key for signing, which would complicate the management of the distribution. They would be more in favor of using the same PGP key, currently used for signing RPM headers, also for file-based signatures (not only fsverity, but also IMA ones). Another envisioned use case would be to add the ability to appraise RPM headers with their existing PGP signature, so that they can be used as an authenticated source of reference values for appraising remaining files [2]. To make these use cases possible, introduce support for PGP keys and signatures in the kernel, and load provided PGP keys in the built-in keyring, so that PGP signatures of RPM headers, fsverity digests, and IMA digests can be verified from this trust anchor. In addition to the original version of the patch set, also introduce support for signature verification of PGP keys, so that those keys can be added to keyrings with a signature-based restriction (e.g. .ima). PGP keys are searched with partial IDs, provided with signature subtype 16 (Issuer). Search with full IDs could be supported with draft-ietf-openpgp-rfc4880bis-10, by retrieving the information from signature subtype 33 (Issuer Fingerprint). Due to the possibility of ID collisions, the key_or_keyring restriction is not supported. The patch set includes two preliminary patches: patch 1 introduces mpi_key_length(), to get the number of bits and bytes of an MPI; patch 2 introduces rsa_parse_priv_key_raw() and rsa_parse_pub_key_raw(), to parse an RSA key in RAW format if the ASN.1 parser returns an error. Patches 3-5 introduce the library necessary to parse PGP keys and signatures, whose support is added with patches 6-10. Patch 11 introduces verify_pgp_signature() to be used by kernel subsystems (e.g. fsverity and IMA). Patch 12 is for testing of PGP signatures. Finally, patches 13-14 allow loading a set of PGP keys from a supplied blob at boot time. I generated the diff from [3] (rebased). It is available at: https://github.com/robertosassu/linux/compare/pgp-signatures-v1-orig..pgp-signatures-v1 Changelog v0 [3]: - style fixes - move include/linux/pgp.h and pgplib.h to crypto/asymmetric_keys - introduce verify_pgp_signature() - replace KEY_ALLOC_TRUSTED flag with KEY_ALLOC_BUILT_IN - don't fetch PGP subkeys - drop support for DSA - store number of MPIs in pgp_key_algo_p_num_mpi array - replace dynamic memory allocations with static ones in pgp_generate_fingerprint() - store only keys with capability of verifying signatures - remember selection of PGP signature packet and don't repeat parsing - move search of the PGP key to verify the signature from the beginning to the end of the verification process (to be similar with PKCS#7) - don't retry key search in the session keyring from the signature verification code, let the caller pass the desired keyring - for the PGP signature test key type, retry the key search in the session keyring - retry key search in restrict_link_by_signature() with a partial ID (provided in the PGP signature) [1] https://fedoraproject.org/wiki/Changes/FsVerityRPM [2] https://fedoraproject.org/wiki/Changes/DIGLIM [3] https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-modsign.git/log/?h=pgp-parser David Howells (8): PGPLIB: PGP definitions (RFC 4880) PGPLIB: Basic packet parser PGPLIB: Signature parser KEYS: PGP data parser KEYS: Provide PGP key description autogeneration KEYS: PGP-based public key signature verification PGP: Provide a key type for testing PGP signatures KEYS: Provide a function to load keys from a PGP keyring blob Roberto Sassu (6): mpi: Introduce mpi_key_length() rsa: add parser of raw format KEYS: Retry asym key search with partial ID in restrict_link_by_signature() KEYS: Calculate key digest and get signature of the key verification: introduce verify_pgp_signature() KEYS: Introduce load_pgp_public_keyring() MAINTAINERS | 1 + certs/Kconfig | 11 + certs/Makefile | 7 + certs/system_certificates.S | 18 + certs/system_keyring.c | 91 ++++ crypto/asymmetric_keys/Kconfig | 38 ++ crypto/asymmetric_keys/Makefile | 13 + crypto/asymmetric_keys/pgp.h | 206 ++++++++ crypto/asymmetric_keys/pgp_library.c | 620 ++++++++++++++++++++++++ crypto/asymmetric_keys/pgp_parser.h | 18 + crypto/asymmetric_keys/pgp_preload.c | 110 +++++ crypto/asymmetric_keys/pgp_public_key.c | 484 ++++++++++++++++++ crypto/asymmetric_keys/pgp_signature.c | 507 +++++++++++++++++++ crypto/asymmetric_keys/pgp_test_key.c | 129 +++++ crypto/asymmetric_keys/pgplib.h | 74 +++ crypto/asymmetric_keys/restrict.c | 10 +- crypto/rsa.c | 14 +- crypto/rsa_helper.c | 69 +++ include/crypto/internal/rsa.h | 6 + include/crypto/pgp.h | 35 ++ include/linux/mpi.h | 2 + include/linux/verification.h | 23 + lib/mpi/mpicoder.c | 33 +- 23 files changed, 2506 insertions(+), 13 deletions(-) create mode 100644 crypto/asymmetric_keys/pgp.h create mode 100644 crypto/asymmetric_keys/pgp_library.c create mode 100644 crypto/asymmetric_keys/pgp_parser.h create mode 100644 crypto/asymmetric_keys/pgp_preload.c create mode 100644 crypto/asymmetric_keys/pgp_public_key.c create mode 100644 crypto/asymmetric_keys/pgp_signature.c create mode 100644 crypto/asymmetric_keys/pgp_test_key.c create mode 100644 crypto/asymmetric_keys/pgplib.h create mode 100644 include/crypto/pgp.h