[HN Gopher] Gpg.fail
___________________________________________________________________
Gpg.fail
Author : todsacerdoti
Score : 226 points
Date : 2025-12-27 17:05 UTC (5 hours ago)
(HTM) web link (gpg.fail)
(TXT) w3m dump (gpg.fail)
| rurban wrote:
| Zero-days from the CCC talk
| https://fahrplan.events.ccc.de/congress/2025/fahrplan/event/...
|
| But trust in Werner Koch is gone. Wontfix??
| corndoge wrote:
| I am curious what you mean by "trust in Werner Koch is gone".
| Can you elaborate?
| karambahh wrote:
| OP is complaining about GPG team rejecting issues with
| "wontfix" statuses.
| cpach wrote:
| To be frank, at this point, GPG has been a lost cause for
| basically decades.
|
| People who are serious about security use newer, better tools
| that replace GPG. But keep in mind, there's no "one ring to
| rule them all".
| perching_aix wrote:
| What are those better tools? I've been broadly looking into
| this space, but never ventured too deep.
| singpolyma3 wrote:
| Sequoia for example has been doing a great job and
| implements the latest version of the standard which brings
| a lot of cryptography up to date
| perching_aix wrote:
| I'm yet to finish watching the talk, but it starts with
| them confirming the demo fraudulent .iso with sequoia
| also (they call it out by name), so this really makes me
| think. :)
| tptacek wrote:
| Sequioa hasn't fixed the attack from the beginning of the
| talk, the one where they convert between cleartext and
| full signature formats and inject unsigned bytes into the
| output because of the confusion.
| akerl_ wrote:
| The latest version of a bad standard is still bad.
|
| This page is a pretty direct indicator that GPG's
| foundation is fundamentally broken: you're not going to
| get to a good outcome trying to renovate the 2nd story.
| singpolyma3 wrote:
| That's just not true. Nothing in this page is a problem
| with the standard and everything in this page is the
| outdated parts of the old standard.
| akerl_ wrote:
| So then why do a bunch of these affect Sequoia as well?
| arccy wrote:
| ssh or minisign for signing age for file encryption
| johnisgood wrote:
| There are people who use GPG for more than that. Those
| that are fine with just those two features, sure. Heck,
| you can encrypt with "openssh", no need for age. :D I
| have a bash function for encryption and decryption!
| cpach wrote:
| Those people should perhaps ponder if it's a reasonable
| thing to insist on using this broken standard/tool in
| 2025.
| ameliaquining wrote:
| https://www.latacora.com/blog/2019/07/16/the-pgp-
| problem/#th... lists a bunch of them.
| p2detar wrote:
| > Encrypting email
|
| > Don't.
|
| https://www.latacora.com/blog/2019/07/16/the-pgp-
| problem/#en...
|
| I'm not sure I completely agree here. For private use,
| this seems fine. However, this isn't how email encryption
| is typically implemented in an enterprise environment.
| It's usually handled at the mail gateway rather than on a
| per-user basis. Enterprises also ensure that the
| receiving side supports email encryption as well.
|
| edit: formatting
| tptacek wrote:
| Your mail either needs to be encrypted reliably against
| real adversaries or it doesn't. A private emailing circle
| doesn't change that. If the idea here is, a private group
| of friends can just agree never to put anything in their
| subjects, or to accidentally send unencrypted replies,
| I'll just say I ran just such a private circle at
| Matasano, where we used encrypted mail to communicate
| about security assessment projects, and unencrypted
| replies happened.
| jcranmer wrote:
| There's like one or two use cases where encrypting email
| could work. The best case I've come across--Bugzilla has
| the ability to let the user upload a public key to
| encrypt emails for updates to non-public bugs. It's not a
| _big_ use case--pretty much the intersection of "must
| use email" and "can establish identity out of band,"
| which does not describe most communication that uses
| email. (As tptacek notes in a sibling comment, you pretty
| much have to limit this to one-and-done stuff too, not
| anything that's going to be in an ongoing discussion,
| because leaks via unencrypted replies are basically
| guaranteed).
| GaryBluto wrote:
| > brb, were on it!!!!
| WesolyKubeczek wrote:
| gpg.fail fail: "brb, we're on it!"
| _haxx0rz wrote:
| hug of death?
| rurban wrote:
| Nope. Not yet enabled. It was submitted to HN right after the
| talk where they promised to make it public "really soon" after
| the talk. We all saw the talk live or on the stream
| smallerize wrote:
| Seems to be down? Here's a thread with a summary of exploits
| presented in the talk:
| https://bsky.app/profile/filippo.abyssdomain.expert/post/3ma...
| orblivion wrote:
| Maybe the site is overloaded. But as for the "brb, were on
| it!!!!" - this page had the live stream of the talk when it was
| happening. Hopefully they'll replace it with the recording when
| media.ccc.de posts it, which should be within a couple hours.
| karambahh wrote:
| Also expect contents referred in the slides (every "chapter"
| of the presentation referred to a url such as
| https://gpg.fail/clearsig or https://gpg.fail/minisig and so
| on)
| kleiba wrote:
| _> this page had the live stream of the talk when it was
| happening_
|
| As they said, they _were_ on it...
| selfbottle wrote:
| it's online now
| orblivion wrote:
| Took me a second but I got your joke
| elric wrote:
| This is depressing.
|
| From what I can piece together while the site is down, it seems
| like they've uncovered 14 exploitable vulnerabilities in GnuPG,
| of which most remain unpatched. Some of those are apparently met
| by refusal to patch by the maintainer. Maybe there are good
| reasons for this refusal, maybe someone else can chime in on
| that?
|
| Is this another case of XKCD-2347? Or is there something else
| going on? Pretty much every Linux distro depends on PGP being
| pretty secure. Surely IBM & co have a couple of spare developers
| or spare cash to contribute?
| collinfunk wrote:
| Haven't read it since it is down, but based on other comments,
| it seems to be an issue with cleartext signatures.
|
| I haven't seen those outside of old mailing list archives.
| Everyone uses detached signatures nowadays, e.g. PGP/MIME for
| emails.
| bytehamster wrote:
| If I understood their first demo correctly, they verified a
| fedora iso with a detached signature. The booted iso then
| printed "hello 39c3".
| https://streaming.media.ccc.de/39c3/relive/1854
| unscaled wrote:
| It was a cleartext signature, not a detached signature.
|
| Edit: even better. It was both. There is a signature type
| confusion attack going on here. I still didn't watch the
| entire thing, but it seems that unlike gpg, they do have to
| specify --cleartext explicitly for Sequoia, so there is no
| confusion going on that case.
| akerl_ wrote:
| > Surely IBM & co have a couple of spare developers or spare
| cash to contribute?
|
| A major part of the problem is that GPG's issues aren't cash or
| developer time. It's fundamentally a bad design for
| cryptographic usage. It's so busy trying to be a generic Swiss
| Army knife for every possible user or use case that it's
| basically made of developer and user footguns.
|
| The way you secure this is by moving to alternative, purpose-
| built tools. Signal/WhatsApp for messaging, age for file
| encryption, minisign for signatures, etc.
| ameliaquining wrote:
| If by "pretty much every Linux distro depends on PGP being
| pretty secure" you're referring to its use to sign packages in
| Linux package managers, it's worth noting that they use PGP in
| fairly narrowly constrained ways; in particular, the data is
| often already trusted because it was downloaded over HTTPS from
| a trusted server (making PGP kind of redundant in some ways).
| So most PGP vulnerabilities don't affect them.
|
| If there were a PGP vulnerability that actually made it
| possible to push unauthorized updates to RHEL or Fedora
| systems, then probably IBM would care, but if they concluded
| that PGP's security problems were a serious threat then I
| suspect they'd be more likely to start a migration away from
| PGP than to start investing in making PGP secure; the former
| seems more tractable and would have maintainability benefits
| besides.
| viraptor wrote:
| > already trusted because it was downloaded over HTTPS from a
| trusted server (making PGP kind of redundant in some ways)
|
| That's mostly incorrect in both counts. One is that lots of
| mirrors are still http-only or http default
| https://launchpad.net/ubuntu/+archivemirrors
|
| The other is that if you get access to one of the mirrors and
| replace a package, it's the signature that stops you. Https
| is only relevant for mitm attacks.
|
| > they'd be more likely to start a migration away from PGP
|
| The discussions started ages ago:
|
| Debian https://wiki.debian.org/Teams/Apt/Spec/AptSign
|
| Fedora https://lists.fedoraproject.org/archives/list/packagin
| g@list...
| zzo38computer wrote:
| Downloading over HTTPS does not help with that (although it
| can prevent spies from seeing what files you are downloading)
| unless you can independently verify the server's keys. The
| certificate is intended to do this but the way that standard
| certificate authorities work will only verify the domain
| name, and has some other limitations. TLS does have other
| benefits, but it does a different thing. Using only TLS to
| verify the packages is not very good, especially with the
| existing public certificate authorities.
|
| If you only need a specific version and you already know what
| that one is, then using a cryptographic hash will be a better
| way to verify packages, although that only applies for one
| specific version of one specific package. So, using an
| encrypted protocol (HTTPS or any other one) alone will not
| help, although it will help in combination with other things;
| you will need to do other things as well, to improve the
| security.
| singpolyma3 wrote:
| AFAICT this is GnuPG specific and not OpenPGP related? Since
| GnuPG has pulled out of standards compliance anyway there are
| many better options. Sequoia chameleon even has drop in tooling
| for most workflows.
| rurban wrote:
| They presented critical parser flaws in all major PGP
| implementations, not just GNU PGP, also sequoia, minisign and
| age. But gpg made the worst impression to us. wontfix
| akerl_ wrote:
| Since when are age or minisign PGP implementations?
| some_furry wrote:
| The talk title includes "& Friends", for what it's worth.
| somethrowa123 wrote:
| no, some clearsig issues are a problem in openpgp standard
| itself
| Analemma_ wrote:
| The specific bugs are with GPG, but a lot of the reason they
| can exist to begin with is PGP's convoluted architecture which,
| IMO, makes these sorts of issues inevitable. I think they are
| effectively protocol bugs.
| upofadown wrote:
| I think it would be more accurate (and more helpful) to say
| that the two factions in the OpenPGP standards schism[1] have
| pulled away from the idea of consensus. There is a fundamental
| philosophical difference here. The LiberePGP faction (GnuPGP)
| is following the traditional PGP minimalism when it comes to
| changes and additions to the standard. The RFC-9580 faction
| (Sequoia) is following a kind of maximalist approach where any
| potential issue might result in a change/addition.
|
| Fortunately, it turned out that there wasn't anything
| particularly wrong with the current standards so we can just do
| that for now and avoid the standards war entirely. Then we will
| have interoperability across the various implementations. If
| some weakness comes up that actually requires a standards
| change then I suspect that consensus will be much easier to
| find.
|
| [1] https://articles.59.ca/doku.php?id=pgpfan:schism
| tptacek wrote:
| I'm sure getting a "nothing's particularly wrong with the
| current standards" vibe from this talk.
| singpolyma3 wrote:
| The talk doesn't even cover anything from the current
| afaict
| tptacek wrote:
| I believe that's incorrect but we may be referring to
| different things as "current".
| upofadown wrote:
| Some of these are suggesting that an attacker might trick
| the victim into decrypting a message before sending to the
| attacker. If that is really the best sort of attack you can
| do against PGP then, yeah, that is the kind of vibe you
| might get.
| derleyici wrote:
| Werner Koch from GnuPG recently (2025-12-26) posted this on their
| blog: https://www.gnupg.org/blog/20251226-cleartext-
| signatures.htm...
|
| Archive link:
| https://web.archive.org/web/20251227174414/https://www.gnupg...
| woodruffw wrote:
| This feels pretty unsatisfying: something that's been
| "considered harmful" for _three decades_ should be deprecated
| and then removed in a responsible ecosystem.
|
| (PGP/GPG are of course hamstrung by their own decision to be a
| Swiss Army knife/only loosely coupled to the secure operation
| itself. So the even more responsible thing to do is to discard
| them for purposes that they _can't_ offer security properties
| for, which is the vast majority of things they get used for.)
| LtWorf wrote:
| Well python discarded signing entirely so that's one way to
| solve it :)
| woodruffw wrote:
| Both CPython and distributions on PyPI are more effectively
| signed than they were before.
|
| (I think you already know this, but want to relitigate
| something that's not meaningfully controversial in Python.)
| LtWorf wrote:
| Being signed by some entity which is not the author is
| hardly more effective.
|
| (I think you already know this as well)
| woodruffw wrote:
| It is, in fact, signed by the author. It's just a PKI, so
| you intermediate trust in the author through an
| authority.
|
| This is exactly analogous to the Web PKI, where you trust
| CAs to identify individual websites, but the websites
| themselves control their keypairs. The CA's presence
| intermediates the trust but does not somehow imply that
| the CA itself does the signing for TLS traffic.
| LtWorf wrote:
| Not really, uploading via trusted publishers I don't own
| any private key, as you probably know having implemented
| it yourself I presume.
| woodruffw wrote:
| Trusted Publishing doesn't involve any signing keys
| (well, there's an IdP, but the IdP's signature is over a
| JWT that the index verifies, not an end signature).
| You're thinking of attestations, which do indeed involve
| a local ephemeral private key.
|
| Again, I must emphasize that this is identical in
| construction to the Web PKI; that was intentional. There
| are good criticisms of PKIs on grounds of centrality,
| etc., but "the end entity doesn't control the private
| key" is facially untrue and sounds more like conspiracy
| than anything else.
| LtWorf wrote:
| Conspiracy in what way? Can you explain?
|
| On my web server where the certificate is signed by
| letsencrypt I do have a file which contains a private
| key. On pypi there is no such thing. I don't think the
| parallel is correct.
| woodruffw wrote:
| With Let's Encrypt, your private key is (typically)
| rotated every 90 days. It's kept on disk because 90 days
| is too long to reliably keep a private key resident in
| memory on unknown hardware.
|
| With attestations on PyPI, the issuance window is 15
| minutes instead of 90 days. So the private key is kept in
| memory and discarded as soon as the signing operation is
| complete, since the next signing flow will create a new
| one.
|
| At no point does the private key leave your machine. The
| only salient differences between the two are file versus
| memory and the validity window, but in both cases PyPI's
| implementation of attestations prefers the _more_ ideal
| thing with respect to reducing the likelihood of local
| private key disclosure.
| LtWorf wrote:
| I think you are conflating a CI runner I don't really
| control with my machine?
| cpach wrote:
| GPG is indeed deprecated.
|
| Most people have never heard of it and never used it.
| woodruffw wrote:
| Can you provide a source this? To my understanding, the
| GnuPG project (and by extension PGP as an ecosystem)
| considers itself very much alive, even though practically
| speaking it's effectively moribund and irrelevant.
|
| (So I agree that it's _de facto_ dead, but that's not the
| same thing as formal deprecation. The latter is what you do
| _explicitly_ to responsibly move people away from something
| that's not suitable for use anymore.)
| cpach wrote:
| Ah. I meant in the _de facto_ sense.
| IshKebab wrote:
| I would be very much surprised if GPG has ever really
| achieved anything other than allowing crypto nerds to
| proclaim that things were encrypted or signed. Good for
| them I guess, but not of any practical importance, unlike
| SSH, TLS, 7Zip encryption, etc.
| tptacek wrote:
| They allow some kind of nerd to claim that, but nobody
| who nerds out on cryptography defends PGP. Cryptographers
| hate PGP.
| stackghost wrote:
| It must be tough to be Werner Koch, and have poured so much
| time and energy into GPG only to have it demonstrated again and
| again that you're incompetent, and GPG is unfixably broken at a
| fundamental level.
| clacker-o-matic wrote:
| its back up!
| selfbottle wrote:
| writeups are online :))
| somethrowa123 wrote:
| the writeup is now available and the recording lives at
| https://media.ccc.de/v/39c3-to-sign-or-not-to-sign-practical...
| oefrha wrote:
| Okay, since there's so much stuff to digest here and apparently
| there are issues designated as wontfix by GnuPG maintainers, can
| someone more in the loop tell us whether using gpg signatures on
| git commits/tags is vulnerable? And is there any better
| alternative going forward? Like is signing with SSH keys
| considered more secure now? I certainly want to get rid of gpg
| from my life if I can, but I also need to make sure commits/tags
| bearing my name actually come from me.
| larusso wrote:
| I did the switch this year after getting yet another personal
| computer. I have 4 in total (work laptop, personal sofa laptop,
| Mac Mini, Linux Tower). I used Yubi keys with gpg and resident
| ssh keys. All is fine but the configuration needed to get it
| too work on all the machines. I also tend to forget the finer
| details and have to relearn the skills of fetching the public
| keys into the keychain etc. I got rid of this all by moving to
| 1Password ssh agent and git ssh signing. Removes a lot of
| headaches from my ssh setup. I still have the yubi key(s)
| though as a 2nd factor for certain web services. And the gpg
| agent is still running but only as a fallback. I will turn this
| off next year.
| hk1337 wrote:
| > 1Password ssh agent and git ssh signing
|
| I'm still working through how to use this but I have it
| basically setup and it's great!
| hirako2000 wrote:
| How is 1password safer than the local keychain?
| larusso wrote:
| The keys never leave the 1Password store. So you don't have
| the keys on the local file system. That and that these keys
| are shared over the cloud was the seller for me. I guess
| security wise it's a bit of a downgrade compared to
| resident keys. But the agent support agent forwarding etc
| which wasn't really working with yubi ssh resident keys.
| Also worth mentioning that I use 1Password. Bitwarden has a
| similar feature as far as I know. For the ones who want to
| self host etc might be the even better solution.
| akerl_ wrote:
| > The keys never leave the 1Password store. So you don't
| have the keys on the local file system.
|
| Keychain and 1Password are doing variants of the same
| thing here: both store an encrypted vault and then give
| you credentials by decrypting the contents of that vault.
| xorcist wrote:
| These are not vulnerabilities in the "remote exploit" sense.
| They should be taken seriously, you should be careful not to
| run local software on untrusted data, and GPG should probably
| do more to protect users from shooting themselves in the foot,
| but the worst thing you could do is panic and throw out a
| process your partners and colleagues trust. There is nothing
| here that will disturb your workflow signing commits or apt-get
| install-ing from your distribution.
|
| If you use crypographic command line tools to verify data sent
| to you, be mindful on what you are doing and make sure to
| understand the attacks presented here. One of the slides is
| titled "should we even use command line tools" and yes, we
| should because the alternative is worse, but we must be
| diligent in treating all untrusted data as adversarial.
| akerl_ wrote:
| A huge part of GPG's purported use case is getting a
| signed/encrypted/both blob from somebody and using GPG to
| confirm it's authentic. This is true for packages you
| download and for commits with signatures.
|
| Handling untrusted input is core to that.
| xorcist wrote:
| It is, and other software handling untrusted data should
| also treat it as adversarial. For example, your package
| tool should probably not output raw package metadata to the
| terminal.
| akerl_ wrote:
| I think you're missing the forest for the trees.
| tgsovlerkhgsel wrote:
| It reads to me like attempting to verify a malicious ascii-
| armoured signature is potential RCE.
| tptacek wrote:
| One of those WONTFIX's is on an insane vulnerability: you can
| bitflip known plaintext in a PGP message to switch it into
| handling compression, allowing attackers to instruct GnuPG
| packet processing to look back to arbitrary positions in the
| message, all while suppressing the authentication failure
| message. GPG's position was: they print, in those
| circumstances, _an error of some sort_ , and that's enough.
| It's an attack that reveals plaintext bytes!
| akulbe wrote:
| Is there a better alternative to GPG?
| tptacek wrote:
| Everything is better than PGP (not just GPG --- all PGP
| implementations).
|
| The problem with PGP is that it's a Swiss Army Knife. It
| does too many things. The scissors on a Swiss Army Knife
| are useful in a pinch if you don't have real scissors, but
| tailors use real scissors.
|
| Whatever it is you're trying to do with encryption, you
| should use the real tool designed for that task. Different
| tasks want altogether different cryptosystems with
| different tradeoffs. There's no one perfect multitasking
| tool.
|
| When you look at the problem that way, surprisingly few
| real-world problems ask for "encrypt a file". People need
| backup, but backup demands backup cryptosystems, which do
| much more than just encrypt individual files. People need
| messaging, but messaging is _wildly_ more complicated than
| file encryption. And of course people want packet
| signatures, ironically PGP 's most mainstream usage, ironic
| because it relies on only a tiny fraction of PGP's
| functionality _and still somehow doesn 't work_.
|
| All that is before you get to the absolutely deranged 1990s
| design of PGP, which is a complex state machine that
| switches between different modes of operation based on
| attacker-controlled records (which are mostly invisible to
| users). Nothing modern looks like PGP, because PGP's
| underlying design predates modern cryptography. It survives
| only because nerds have a parasocial relationship with it.
| johnisgood wrote:
| Now can you give us a list of all the features of PGP and
| a tool that does one specific thing really well?
| akerl_ wrote:
| https://www.latacora.com/blog/2019/07/16/the-pgp-
| problem/#th...
| johnisgood wrote:
| Saw it, not impressed, GnuPG has a lot of more features
| than signing and file encryption.
|
| And there are lots of tools for file encryption anyways.
| I have a bash function using openssh, sometimes I use
| croc (also uses PAKE), etc.
|
| I need an alternative to "gpg --encrypt --armor
| --recipient <foo>". :)
| akerl_ wrote:
| I guess we'll have to live with you being unimpressed.
| some_furry wrote:
| > I need an alternative to "gpg --encrypt --armor
| --recipient <foo>"
|
| That's literally age.
|
| https://github.com/FiloSottile/age
| johnisgood wrote:
| No, because there is no keyring and you have to supply
| people's public key each time. It is not suitable for
| large-scale public key management (with unknown
| recipients), and it does not support automatic discovery,
| trust management. Age does NOT SUPPORT signing at all
| either.
| some_furry wrote:
| Why is a keyring important to you?
|
| Would "fetch a short-lived age public key" serve your use
| case? If so, then an age plugin that build atop the
| AuxData feature in my Fediverse Public Key Directory spec
| might be a solution. https://github.com/fedi-e2ee/public-
| key-directory-specificat...
|
| But either way, you shouldn't have long-lived public keys
| used for confidentiality. It's a bad design to do that.
| johnisgood wrote:
| > you shouldn't have long-lived public keys used for
| confidentiality.
|
| This statement is generic and misleading. Using long-
| lived keys for confidentiality is bad in real-time
| messaging, but for non-ephemeral use cases (file
| encryption, backups, archives) it is completely fine AND
| desired.
|
| > Would "fetch a short-lived age public key" serve your
| use case?
|
| Sadly no.
| soatok wrote:
| (This is some_furry, I'm currently rate-limited. I
| thought this warranted a reply, so I switched to this
| account to break past the limit for a single comment.)
|
| > This statement is generic and misleading.
|
| It may be generic, but it's not misleading.
|
| > Using long-lived keys for confidentiality is bad in
| real-time messaging, but for non-ephemeral use cases
| (file encryption, backups, archives) it is completely
| fine.
|
| What exactly do you mean by "long-lived"?
|
| The "lifetime" of a key being years (for a long-lived
| backup) is less important than how many encryptions are
| performed with said key.
|
| The thing you don't want is to encrypt 2^50 messages
| under the same key. Even if it's cryptographically safe
| to do that, any post-compromise key rotation will be a
| fucking nightmare.
|
| The primary reason to use short-lived public keys is to
| limit the blast radius. Consider these two companies:
|
| Alice Corp. uses the same public key for 30+ years.
|
| Bob Ltd. uses a new public key for each quarter over the
| same time period.
|
| Both parties might retain the secret key indefinitely, so
| that if Bob Ltd. needs to retrieve a backup from 22 years
| ago, they still can.
|
| Now consider what happens if both of them lose their
| currently-in-use secret key due to a Heartbleed-style
| attack. Alice has 30 years of disaster recovery to
| contend with, while Bob only has up to 90 days.
|
| Additionally, file encryption, backups, and archives
| typically use _ephemeral symmetric keys_ at the bottom of
| the protocol. Even when a password-based key derivation
| function is used (and passwords are, for whatever reason,
| reused), the password hashing function usually has a
| random salt, thereby guaranteeing uniqueness.
|
| The idea that "backups" magically mean "long-lived" keys
| are on the table, without nuance, is extremely
| misleading.
|
| > > Would "fetch a short-lived age public key" serve your
| use case?
|
| > Sadly no.
|
| _shrug_ Then, ultimately, there is no way to securely
| satisfy your use case.
| johnisgood wrote:
| You introduced "short-lived" vs "long-lived", not me.
| Long-lived as wall-clock time (months, years) is the
| default interpretation in this context.
|
| > The "lifetime" of a key being years is less important
| than how many encryptions are performed with said key.
|
| This clarifies your position but does not vindicate the
| original statement. If it were not misleading, the
| clarification would not be necessary, IMO.
|
| As for the rest: the Alice / Bob comparison is asymmetric
| in a misleading way. You state Bob Ltd retains all
| private keys indefinitely. A Heartbleed-style attack on
| their key storage infrastructure still compromises 30
| years of backups, not 90 days. Rotation only helps if
| _only_ the current operational key is exposed, which is
| an optimistic threat model you did not specify.
|
| Additionally, your symmetric key point actually supports
| what I said. If data is encrypted with ephemeral
| symmetric keys and the asymmetric key only wraps those,
| the long-lived asymmetric key's exposure does not enable
| bulk decryption without obtaining each wrapped key
| individually.
|
| > "There is no way to securely satisfy your use case"
|
| No need to be so dismissive. Personal backup encryption
| with a long-lived key, passphrase-protected private key,
| and offline storage is a legitimate threat model. Real-
| world systems validate this: SSH host keys, KMS master
| keys, and yes, even PGP, all use long-lived asymmetric
| keys for confidentiality in non-ephemeral contexts.
|
| Your point about high-fan-out keys with large blast
| radius is correct. That is different from "long-lived
| keys are bad for confidentiality".
| baobun wrote:
| sq (sequoia) should be able to sort that.
| johnisgood wrote:
| I know, I have been using it recently.
| some_furry wrote:
| https://soatok.blog/2024/11/15/what-to-use-instead-of-
| pgp/
|
| I wrote this to answer this exact question last year.
| coppsilgold wrote:
| Depending on what you are after, an alternative could be
| using SSH keys for signatures and age[1] for encryption
| targeting SSH keys.
|
| [1] <https://github.com/FiloSottile/age>
| baobun wrote:
| sq (sequoia) is compatible and is available in your
| favorite distro. It's the recommended replacement.
|
| https://book.sequoia-pgp.org/about_sequoia.html
| upofadown wrote:
| Are you referring to "Encrypted message malleability checks
| are incorrectly enforced causing plaintext recovery attacks"?
|
| Seems like a legitimate difference of opinion. The researcher
| wants a message with an invalid format to return an integrity
| failure message. Presumably the GnuPGP project thinks that
| would be better handled by some sort of bad format error.
|
| The exploit here is a variation on the age old idea of
| tricking a PGP user into decrypting an encrypted message and
| then sending the result to the attacker. The novelty here is
| the idea of making the encrypted message look like a PGP key
| (identity) and then asking the victim to decrypt the fake
| key, sign it and then upload it to a keyserver.
|
| Modifying a PGP message file will break the normal PGP
| authentication[1] (that was not acknowledged in the attack
| description). So here is the exploit:
|
| * The victim receives a unauthenticated/anonymous (unsigned
| or with a broken signature) message from the attacker. The
| message looks like a public key.
|
| * Somehow (perhaps in another anonymous message) the attacker
| claims they are someone the victim knows and asks them to
| decrypt, sign and upload the signed public key to a
| keyserver.
|
| * They see nothing wrong with any of this and actually do
| what the attacker wants ignoring the error message about the
| bad message format.
|
| So this attack is also quite unlikely. Possibly that affected
| the decision of the GnuPG project to not change behaviour in
| this case.
|
| [1] https://articles.59.ca/doku.php?id=pgpfan:pgpauth
|
| Added: Wait. How would the victim import the bogus PGP key
| into GPG so they could sign it? There would normally be a
| preexisting key for that user so the bogus key would for sure
| fail to import. It would probably fail anyway. It will be
| interesting to see what the GnuPG project said about this in
| their response.
| tptacek wrote:
| In the course of this attack, just in terms of what happens
| in the mechanics of the actual protocol, irrespective of
| the scenario in which these capabilities are abused, the
| attacker:
|
| (1) Rewrites the ciphertext of a PGP message
|
| (2) Introducing an entire new PGP packet
|
| (3) That flips GPG into DEFLATE compression handling
|
| (4) And then reroutes the handling of the subsequent real
| message
|
| (5) Into something parsed as a plaintext comment
|
| This happens without a security message, but rather just
| (apparently) a zlib error.
|
| In the scenario presented at CCC, they used the keyserver
| example to demonstrate plaintext exfiltration. I kind of
| don't care. It's what's happening under the hood that's
| batshit; the "difference of opinion" is that the GnuPG
| maintainers (and, I guess, you) think this is an acceptable
| end state for an encryption tool.
| alphazard wrote:
| It's a fundamentally bad idea to have a single key that
| applications are supposed to look for in a particular place,
| and then use to sign things. There is inherent complexity
| involved in making multi-context key use safe, and it's better
| to just avoid it architecturally.
|
| Keys (even quantum safe) are small enough that having one per
| application is not a problem at all. If an application needs
| multi-context, they can handle it themselves. If they do it
| badly, the damage is contained to that application. If someone
| really wants to make an application that just signs keys for
| other applications to say "this is John Smith's key for git"
| and "this is John Smith's key for email" then they could do
| that. Such an application would not need to concern itself with
| permissions for other applications calling into it. The user
| could just copy and paste public keys, or fingerprints when
| they want to attest to their identity in a specific
| application.
|
| The keyring circus (which is how GPG most commonly intrudes
| into my life) is crazy too. All these applications insist on
| connecting to some kind of GPG keyring instead of just writing
| the secrets to the filesystem in their own local storage. The
| disk is fully encrypted, and applications should be isolated
| from one another. Nothing is really being accomplished by
| requiring the complexity of yet another program to "extra
| encrypt" things before writing them to disk.
|
| I'm sure these bad ideas come from the busy work invented in
| corporate "security" circles, which invent complexity to keep
| people employed without any regard for an actual threat model.
| akerl_ wrote:
| > The disk is fully encrypted, and applications should be
| isolated from one another.
|
| For most apps on non-mobile devices, there isn't filesystem
| isolation between apps. Disk/device-level encryption solves
| for a totally different threat model; Apple/Microsoft/Google
| all ship encrypted storage for secrets (Keychain, Credential
| Manager, etc), because restricting key material access within
| the OS has merit.
|
| > I'm sure these bad ideas come from the busy work invented
| in corporate "security" circles, which invent complexity to
| keep people employed without any regard for an actual threat
| model.
|
| Basically everything in PGP/GPG predates the existence of
| "corporate security circles".
| 65a wrote:
| > I certainly want to get rid of gpg from my life if I can
|
| I see this sentiment a lot, but you later hint at the problem.
| Any "replacement" needs to solve for secure key distribution.
| Signing isn't hard, you can use a lot of different things other
| than gpg to sign something with a key securely. If that part of
| gpg is broken, it's a bug, it can/should be fixed.
|
| The real challenge is distributing the key so someone else can
| verify the signature, and almost every way to do that is
| fundamentally flawed, introduces a risk of operational errors
| or is annoying (web of trust, trust on first use, central
| authority, in-person, etc). I'm not convinced the right answer
| here is "invent a new one and the ecosystem around it".
| woodruffw wrote:
| A lot of people are using PGP for things that don't require
| any kind of key distribution. If you're just using it to
| encrypt files (even between pointwise parties), you can
| probably just switch to age.
|
| (We're also _long_ past the point where key distribution has
| been a significant component of the PGP ecosystem. The PGP
| web of trust and original key servers have been dead and
| buried for years.)
| kaoD wrote:
| This is not the first time I see "secure key distribution"
| mentioned in HN+(GPG alternatives) context and I'm a bit
| puzzled.
|
| What do you mean? Web of Trust? Keyservers? A combination of
| both? Under what use case?
| kpil wrote:
| I'm assuming they mean the old way of signing each others
| signatures.
|
| As a practical implementation of "six degrees of Kevin
| Bacon", you could get an organic trust chain to random
| people.
|
| Or at least, more realistically, to few nerds. I think I
| signed 3-4 peoples signatures.
|
| The process had - as they say - a low WAF.
| dale_glass wrote:
| > As a practical implementation of "six degrees of Kevin
| Bacon", you could get an organic trust chain to random
| people.
|
| GPG is terrible at that.
|
| 0. Alice's GPG trusts Alice's key tautologically. 1.
| Alice's GPG can trust Bob's key because it can see
| Alice's signature. 2. Alice's GPG can trust Carol's key
| because Alice has Bob's key, and Carol's key is signed by
| Bob.
|
| After that, things break. GPG has no tools for finding
| longer paths like Alice -> Bob -> ??? -> signature on
| some .tar.gz.
|
| I'm in the "strong set", I can find a path to damn near
| anything, but only with a lot of effort.
|
| The good way used to be using the path finder, some
| random website maintained by some random guy that
| disappeared years ago. The bad way is downloading a
| .tar.gz, checking the signature, fetching the key, then
| fetching every key that signed in, in the hopes somebody
| you know signed one of those, and so on.
|
| And GPG is terrible at dealing with that, it hates having
| tens of thousands of keys in your keyring from such
| experiments.
|
| GPG never grew into the modern era. It was made for
| persons who mostly know each other directly. Addressing
| the problem of finding a way to verify the keys of random
| free software developers isn't something it ever did
| well.
| tptacek wrote:
| What's funny about this is that the whole idea of the
| "web of trust" was (and, as you demonstrate, is)
| literally PGP punting on this problem. That's how they
| talked about it at the time, in the 90s, when the concept
| was introduced! But now the precise mechanics of that
| punt have become a critically important PGP feature.
| 65a wrote:
| In a signature context, you probably want someone else to
| know that "you" signed it (I can think of other cases, but
| that's the usual one). The way to do that requires them to
| know that the key which signed the data belongs to you. My
| only point is that this is actually the hard part, which
| any "replacement" crypto system needs to solve for, and
| that solving that is hard (none of the methods are
| particularly good).
| akerl_ wrote:
| It's not like GPG solves for secure key distribution. GPG
| keyservers are a mess, and you can't trust their contents
| anyways unless you have an out of band way to validate the
| public key. Basically nobody is using web-of-trust for this
| in the way that GPG envisioned.
|
| This is why basically every modern usage of GPG either
| doesn't rely on key distribution (because you already know
| what key you want to trust via a pre-established channel) or
| devolves to the other party serving up their pubkey over
| HTTPS on their website.
| 65a wrote:
| Yes, not saying that web of trust ever worked. "Pre-
| established channel" are the other mechanisms I mentioned,
| like a central authority (https) or TOFU (just trust the
| first key you get). All of these have some issues, that any
| alternative must also solve for.
| akerl_ wrote:
| So if we need a pre-established channel anyways, why
| would people recommending a replacement for GPG workflows
| need to solve for secure key distribution?
|
| This is a bit like looking at electric cars and saying
| ~"well you can't claim to be a viable replacement for gas
| cars until you can solve flight"
| SSLy wrote:
| https://media.ccc.de/v/39c3-to-sign-or-not-to-sign-practical...
| tptacek wrote:
| A thru-line of some of the gnarliest vulnerabilities here is
| PGP's insane packet system, where a PGP message is a practically
| arbitrary stream of packets, some control and some data, with
| totally incoherent cryptographic bindings. It's like something in
| between XMLDSIG (which pulls cryptographic control data out of
| random places in XML messages according to attacker-controlled
| tags) and SSL2 (with no coherent authentication of the complete
| handshake).
|
| The attack on detached signatures (attack #1) happens because
| GnuPG needs to run a complicated state machine that can put
| processing into multiple different modes, among them three
| _different_ styles of message signature. In GPG, that whole state
| machine apparently collapses down to a binary check of "did we
| see any data so that we'd need to verify a signature?", and you
| can selectively flip that predicate back and forth by shoving
| different packets into message stream, even if you've already
| sent data that needs to be verified.
|
| The malleability bug (attack #4) is particularly slick. Again,
| it's an incoherent state machine issue. GPG can "fail" to process
| a packet because it's cryptographically invalid. But it can also
| fail because the message framing itself is corrupted. Those
| latter non-cryptographic failures are handled by aborting the
| processing of the message, putting GPG into an unexpected state
| where it's handling an error and "forgetting" to check the
| message authenticator. You can CBC-bitflip known headers to force
| GPG into processing DEFLATE compression, and mangle the message
| such that handling the message prints the plaintext in its
| output.
|
| The formfeed bug (#3) is downright weird. GnuPG has special
| handling for `\f`; if it occurs at the end of a line, you can
| inject arbitrary unsigned data, because of GnuPG's handling of
| line truncation. Why is this even a feature?
|
| Some of these attacks look situational, but that's deceptive,
| because PGP is (especially in older jankier systems) used as an
| encryption backend for applications --- Mallory getting Alice to
| sign or encrypt something on her behalf is an extremely realistic
| threat model (it's the same threat model as most cryptographic
| attacks on secure cookies: the app automatically signs stuff for
| users).
|
| There is _no reason_ for a message encryption system to have this
| kind of complexity. It 's a deep architectural flaw in PGP. You
| want extremely simple, orthogonal features in the format, ideally
| treating everything as clearly length-delimited opaque binary
| blobs. Instead you get a Weird Machine, and talks like this one.
|
| Amazing work.
| oskarw85 wrote:
| Thank you for this excellent explanation!
| IAmLiterallyAB wrote:
| Another related writeup
| https://www.latacora.com/blog/2019/07/16/the-pgp-problem/
| upofadown wrote:
| There is some misleading stuff in that article. To save time I
| made an article to provide my commentary:
|
| * https://articles.59.ca/doku.php?id=pgpfan:tpp
| jcranmer wrote:
| Don't you think it's time to update it, given you start by
| saying that "If someone, while trying to sell you some high
| security mechanical system, told you that the system had
| remained unbreached for the last 20 years you would take that
| as a compelling argument"?
|
| Because you're clearly presenting it as a defense of PGP on a
| thread from a presentation clearly delineating breaks in it
| using exactly the kind of complexity that the article you're
| responding to predicts would cause it to break.
| 1317 wrote:
| [video]
| wkat4242 wrote:
| I don't mind gpg. I still use it a lot especially with the
| private keys on openpgp smartcards or yubikeys.
|
| It's a pretty great ecosystem, most hardware smartcards are
| surrounded by a lot of black magic and secret handshakes and
| stuff like pkcs#11 and opensc/openct are much much harder to
| configure.
|
| I use it for many things but not for email. Encrypted backups,
| password manager, ssh keys. For some there are other hardware
| options like fido2 but not for all usecases and not the same one
| for each usecase. So I expect to be using gpg for a long time to
| come.
| acoustics wrote:
| I don't understand the disappointment expressed here in the
| maintainers deciding to WONTFIX these security bugs.
|
| Isn't this what ffmpeg did recently? They seemed to get a ton of
| community support in their decision not to fix a vulnerability
| some_furry wrote:
| ffmpeg doesn't have a cargo-cult of self-proclaimed "privacy
| experts" that tell activists and whistleblowers to use their
| thing instead of other tools cryptographers actually recommend.
| landr0id wrote:
| Yeah, instead they have a cargo-cult of self-proclaimed OSS
| contribution experts who harass anyone that critiques or
| challenges ffmpeg's twitter account.
___________________________________________________________________
(page generated 2025-12-27 23:00 UTC)