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

101–110 of 376 posts

Re: Gpg.fail

#101

Post by LtWorf »

woodruffw wrote: post #92
LtWorf wrote: post #82

Earlier quoted context omitted.

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

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…

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.

Re: Gpg.fail

#102

Post by some_furry »

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

> I need an alternative to "gpg --encrypt --armor --recipient "

That's literally age.

https://github.com/FiloSottile/age

Re: Gpg.fail

#103

Post by jcranmer »

upofadown wrote: post #78
IAmLiterallyAB wrote: post #62

Another related writeup https://www.latacora.com/blog/2019/07/16/the-pgp-problem/

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

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.

Re: Gpg.fail

#104

Post by acoustics »

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

Re: Gpg.fail

#105

Post by some_furry »

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.

Re: Gpg.fail

#106

Post by woodruffw »

LtWorf wrote: post #101
woodruffw wrote: post #92

Earlier quoted context omitted.

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…

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.

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.

Re: Gpg.fail

#107

Post by baobun »

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?

sq (sequoia) is compatible and is available in your favorite distro. It's the recommended replacement.

https://book.sequoia-pgp.org/about_sequoia.html

Re: Gpg.fail

#108

Post by johnisgood »

some_furry wrote: post #102
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 ". :)

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

Re: Gpg.fail

#109

Post by cpach »

johnisgood wrote: post #93
arccy wrote: post #55

Earlier quoted context omitted.

ssh or minisign for signing age for file encryption

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!

Those people should perhaps ponder if it’s a reasonable thing to insist on using this broken standard/tool in 2025.

Re: Gpg.fail

#110

Post by jcranmer »

p2detar wrote: post #68
ameliaquining wrote: post #59

Earlier quoted context omitted.

https://www.latacora.com/blog/2019/07/16/the-pgp-problem/#th... lists a bunch of them.

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

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