4 ms·
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 attacker
by tptacek 11mo ago
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 11mo agoIs there a better alternative to GPG?
- tptacek 11mo agoEverything 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 11mo agoNow can you give us a list of all the features of PGP and a tool that does one specific thing really well?
- akerl_ 11mo agohttps://www.latacora.com/blog/2019/07/16/the-pgp-problem/#the-answers https://www.latacora.com/blog/2019/07/16/the-pgp-problem/#th...
- johnisgood 11mo agoSaw 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_ 11mo agoI guess we'll have to live with you being unimpressed.
- some_furry 11mo ago> I need an alternative to "gpg --encrypt --armor --recipient <foo>" That's literally age. https://github.com/FiloSottile/age https://github.com/FiloSottile/age
- johnisgood 11mo agoNo, 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 11mo ago
- palata 11mo ago> It survives only because nerds have a parasocial relationship with it. I really would like to replace PGP with the "better" tool, but: * Using my Yubikey for signing (e.g. for git) has a better UX with PGP instead of SSH * I have to use PGP to sign packages I send to Maven Maybe I am a nerd emotionally attached to PGP, but after a year signing with SSH, I went back to PGP and it was so much better...
- computerfriend 11mo ago> better UX with PGP instead of SSH This might be true of comparing GPG to SSH-via-PIV, but there's a better way with far superior UX: derive an SSH key from a FIDO2 slot on the YubiKey.
- palata 11mo agoI do it with FIDO2. It's inconvenient when having multiple Yubikeys (I always end up adding the entry manually with ssh-agent), and I have to touch the Yubikey everytime it signs. That makes it very annoying when rebasing a few tens of commits, for instance. With GPG it just works.
- ahlCVA 11mo agoFor what it's worth: You can set no-touch-required on a key (it's a generation-time option though).
- palata 11mo agoSure, but then it is set to no-touch for every FIDO2 interaction I have. I don't want to touch for signing, but I want to touch when using it as a passkey, for instance.
- Avamander 11mo agoUse the PIV applet for SSH and signing Git commits instead? Git supports S/MIME and SSH can use keys over PKCS#11 basically out-of-box on OSs that don't ship gpg-agent (that just interferes with SmartCard usage in general).
- josephg 11mo agoThe thing I can't get past with PGP / GPG is that it tries to work around MITM attacks by encouraging users to place their social network on the public record (via public key attestation). This is so insane to me. The whole point of using cryptography is to keep private information private. Its hard to think of ways PGP could fail more as a security / privacy tool.
- upofadown 11mo agoDo you mean keyservers? Keyservers have nothing to do with the identity verification required to prevent MITM attacks. There is only one method available for PGP. Comparison of key fingerprints/IDs. Keyservers are simply a convenient way to get a public key (identity). Most people don't have to use them.
- benchloftbrunch 11mo agoWhat is the alternative to PGP for the specific use case of secure email? That doesn't mandate dealing with the X509 certificate bureaucracy?
- tptacek 11mo agoDon't encrypt email. https://www.latacora.com/blog/2020/02/19/stop-using-encrypted-email/ https://www.latacora.com/blog/2020/02/19/stop-using-encrypte...
- teddyh 11mo agoThe only alternative suggested by the linked article is giving up email completely in favor of centralized solutions like Signal. My short answer is “no”. My long answer is: <https://news.ycombinator.com/item?id=45390332 https://news.ycombinator.com/item?id=45390332>
- tptacek 11mo agoI wrote the linked article. I don't care what secure messenger you use. But if you choose encrypted email over Signal because "centralization", you're LARPing. The first criteria for a secure messenger has to be that it is plausibly secure, and email isn't. You'd use encrypted email (for "decentralization") because you understand the cost of losing the plaintext of your message is nil. If you tell strangers to do that, without certainty that their messages are also valueless, you're committing malpractice.
- Natanael_L 11mo agoWhat's your usecase here? Internal or external messaging?
- pseudohadamard 11mo agoUse case? We're crypto LARPing dammit, we don't need a use case!
- 11mo ago
- deleted 11mo ago[deleted]
- coppsilgold 11mo agoDepending 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 https://github.com/FiloSottile/age>
- baobun 11mo agosq (sequoia) is compatible and is available in your favorite distro. It's the recommended replacement. https://book.sequoia-pgp.org/about_sequoia.html https://book.sequoia-pgp.org/about_sequoia.html
- zimmerfrei 11mo agoThis is the right answer. The problem mostly concerns the oldest parts of PGP (the protocol), which gpg (the implementation) doesn't want or cannot get rid of.
- vbezhenar 11mo agoage
- lagniappe 11mo agoage https://github.com/FiloSottile/age https://github.com/FiloSottile/age
- deleted 11mo ago[deleted]
- upofadown 11mo agoAre 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, particularly when such a change could possibly introduce other vulnerabilities. [1] https://articles.59.ca/doku.php?id=pgpfan:pgpauth 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 11mo agoIn 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.