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

191–200 of 376 posts

Re: Gpg.fail

#191

Post by xeonmc »

some_furry wrote: post #99
johnisgood wrote: post #91

Earlier quoted context omitted.

Now can you give us a list of all the features of PGP and a tool that does one specific thing really well?

https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ I wrote this to answer this exact question last year.

offtopic question:

as a recent dabbling reader of introductory popsci content in cryptography, I've been wondering about what are the different segmentation of expert roles in the field?

e.g. in Filippo's blogpost about Age he clarified that he's not a cryptographer but rather a cryptography engineer, is that also what your role is, what are the concrete divisions of labor, and what other related but separate positions exists in the overall landscape?

where is the cutoff point of "don't roll your own crypto" in the different levels of expertise?

Re: Gpg.fail

#192

Post by darkwater »

MobiusHorizons wrote: post #182
ekjhgkejhgk wrote: post #172

Earlier quoted context omitted.

It's harmful if the license of the rewrites if less protective of users, and then the rewrite ends up being very popular.

Seems like the users are voting with their feet, right? Maybe respect the users wishes and stop preaching what users should be wanting?

Or maybe the users are just not aware. Licenses flame wars were a thing over 20 years ago, people nowadays can totally don't know about what can happen to a MIT-licensed software.

Re: Gpg.fail

#193

Post by Valodim »

For anyone relatedly wondering about the "schism", i.e. GnuPG abandoning the OpenPGP standard and doing their own self-governed thing, I found this email particularly insightful on the matter: https://lists.gnupg.org/pipermail/gnupg-devel/2025-September...

> As others have pointed out, GnuPG is a C codebase with a long history (going on 28 years). On top of that, it's a codebase that is mostly uncovered by tests, and has no automated CI. If GnuPG were my project, I would also be anxious about each change I make. I believe that because of this the LibrePGP draft errs on the side of making minimal changes, with the unspoken goal of limiting risks of breakage in a brittle codebase with practically no tests. (Maybe the new formats in RFC 9580 are indeed "too radical" of an evolutionary step to safely implement in GnuPG. But that's surely not a failing of RFC 9580.)

Re: Gpg.fail

#194

Post by Valodim »

derleyici wrote: post #17

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

This doesn't explain why he decided to WONTFIX what is obviously a parser bug that allows injection of data into output through the headers.

But werner at this point has a history of irresponsible decisions like this, so it's sadly par for the course by now.

Another particularly egregious example: https://dev.gnupg.org/T4493

Re: Gpg.fail

#195

Post by johnisgood »

stackghost wrote: post #174
johnisgood wrote: post #129

Earlier quoted context omitted.

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

>Personal backup encryption with a long-lived key, passphrase-protected private key, and offline storage is a legitimate threat model ... If you're going to use a passphrase anyway why not just use a symmetric cipher? In fact for file storage why not use an encrypted disk volume so you don't need to use PGP?

That was just me being goofy in that bit (and only that), but I hope the rest of my message went across. :)

> In fact for file storage why not use an encrypted disk volume so you don't need to use PGP?

Different threat models. Disk encryption (LUKS, VeraCrypt, plain dm-crypt) protects against physical theft. Once mounted, everything is plaintext to any process with access. File-level encryption protects files at rest and in transit: backups to untrusted storage, sharing with specific recipients, storing on systems you do not fully control. You cannot send someone a LUKS volume to decrypt one file, and backups of a mounted encrypted volume are plaintext unless you add another layer.

Re: Gpg.fail

#197

Post by johnisgood »

xeonmc wrote: post #191
some_furry wrote: post #99

Earlier quoted context omitted.

https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ I wrote this to answer this exact question last year.

offtopic question: as a recent dabbling reader of introductory popsci content in cryptography, I've been wondering about what are the different segmentation of expert roles in the field? e.g. in Filippo's blogpost about Age he clarified that he's not a cryptographer but rather a cryptography engineer, is that also what your role is, what are the concrete divisions of labor, and what other related but separate positio…

You did not ask me, but you should do your due diligence because there are way too many armchair cryptographers around here.

Re: Gpg.fail

#198

Post by kuschku »

woodruffw wrote: post #106
LtWorf wrote: post #101

Earlier quoted context omitted.

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

No? With let's encrypt the certificate is rotated, but the private key remains the same, and importantly, let's encrypt never gets to see it, and anything is logged.

Re: Gpg.fail

#199

Post by raphinou »

I'm working on a multi sig file authentication solution based on minisign. Anyone knows the response of the dev regarding minisign's listed vulnerability? If I'm not mistaken, the response of the authors are not included in the vulnerabilities' descriptions.

Re: Gpg.fail

#200

Post by kuschku »

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…

Even my doctor's office and local government agencies support PGP encrypted emails, and refuse to send personal data via unencrypted email, but tech nerds still claim no one can use it?
Post reply on HN