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

111–120 of 376 posts

Re: Gpg.fail

#111

Post by some_furry »

johnisgood wrote: post #108
some_furry wrote: post #102

Earlier quoted context omitted.

> I need an alternative to "gpg --encrypt --armor --recipient " That's literally age. https://github.com/FiloSottile/age

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.

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.

Re: Gpg.fail

#112

Post by baobun »

johnisgood wrote: post #97
akerl_ wrote: post #96

Earlier quoted context omitted.

https://www.latacora.com/blog/2019/07/16/the-pgp-problem/#th...

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

sq (sequoia) should be able to sort that.

Re: Gpg.fail

#113

Post by johnisgood »

some_furry wrote: post #111
johnisgood wrote: post #108

Earlier quoted context omitted.

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.

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.

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

Re: Gpg.fail

#114

Post by upofadown »

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…

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, particularly when such a change could possibly introduce other vulnerabilities.

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

Re: Gpg.fail

#115

Post by landr0id »

some_furry wrote: post #105
acoustics wrote: post #104

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

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.

Yeah, instead they have a cargo-cult of self-proclaimed OSS contribution experts who harass anyone that critiques or challenges ffmpeg's twitter account.

Re: Gpg.fail

#116

Post by johnisgood »

baobun wrote: post #112
johnisgood wrote: post #97

Earlier quoted context omitted.

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

sq (sequoia) should be able to sort that.

I know, I have been using it recently.

Re: Gpg.fail

#117

Post by soatok »

johnisgood wrote: post #113
some_furry wrote: post #111

Earlier quoted context omitted.

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.

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

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

Re: Gpg.fail

#118

Post by tptacek »

upofadown wrote: post #114
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…

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

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.

Re: Gpg.fail

#119

Post by dale_glass »

kpil wrote: post #84
kaoD wrote: post #73

Earlier quoted context omitted.

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.

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

Re: Gpg.fail

#120

Post by 65a »

akerl_ wrote: post #80
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…

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

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.
Post reply on HN