Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gpg.fail

gpg.fail

Post reply on HN
Print view View original

81–90 of 376 posts

Re: Gpg.fail

#81

Post by IshKebab »

cpach wrote: post #27
woodruffw wrote: post #22

Earlier quoted context omitted.

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…

GPG is indeed deprecated. Most people have never heard of it and never used it.

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.

Re: Gpg.fail

#82

Post by LtWorf »

woodruffw wrote: post #57
LtWorf wrote: post #54

Earlier quoted context omitted.

Being signed by some entity which is not the author is hardly more effective. (I think you already know this as well)

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.

Not really, uploading via trusted publishers I don't own any private key, as you probably know having implemented it yourself I presume.

Re: Gpg.fail

#83

Post by singpolyma3 »

akerl_ wrote: post #72
singpolyma3 wrote: post #49

Earlier quoted context omitted.

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

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.

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.

Re: Gpg.fail

#84

Post by kpil »

kaoD wrote: post #73
65a wrote: post #66

Earlier quoted context omitted.

> 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 els…

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?

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.

Re: Gpg.fail

#85

Post by zzo38computer »

ameliaquining wrote: post #60
elric wrote: post #13

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 m…

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

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.

Re: Gpg.fail

#86

Post by akerl_ »

singpolyma3 wrote: post #83
akerl_ wrote: post #72

Earlier quoted context omitted.

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.

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.

So then why do a bunch of these affect Sequoia as well?

Re: Gpg.fail

#87

Post by upofadown »

singpolyma3 wrote: post #15

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.

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

Re: Gpg.fail

#88

Post by akulbe »

tptacek wrote: post #51
oefrha wrote: post #33

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 sur…

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 attac…

Is there a better alternative to GPG?

Re: Gpg.fail

#89

Post by tptacek »

akulbe wrote: post #88
tptacek wrote: post #51

Earlier quoted context omitted.

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 attac…

Is there a better alternative to GPG?

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.

Re: Gpg.fail

#90

Post by [deleted] »

akulbe wrote: post #88
tptacek wrote: post #51

Earlier quoted context omitted.

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 attac…

Is there a better alternative to GPG?

[deleted]
Post reply on HN