Live data from Hacker News

Gpg.fail

gpg.fail

71–80 of 376 posts

Re: Gpg.fail

#71
I don't mind gpg. I still use it a lot especially with the private keys on openpgp smartcards or yubikeys.

It's a pretty great ecosystem, most hardware smartcards are surrounded by a lot of black magic and secret handshakes and stuff like pkcs#11 and opensc/openct are much much harder to configure.

I use it for many things but not for email. Encrypted backups, password manager, ssh keys. For some there are other hardware options like fido2 but not for all usecases and not the same one for each usecase. So I expect to be using gpg for a long time to come.

Re: Gpg.fail

#72

Earlier quoted context omitted.

What are those better tools? I've been broadly looking into this space, but never ventured too deep.

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.

Re: Gpg.fail

#73
post #66
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…

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

Re: Gpg.fail

#74
post #35

Earlier quoted context omitted.

I did the switch this year after getting yet another personal computer. I have 4 in total (work laptop, personal sofa laptop, Mac Mini, Linux Tower). I used Yubi keys with gpg and resident ssh keys. All is fine but the configuration needed to get it too work on all the machines. I also tend to forget the finer details and have to relearn the skills of fetching the public keys into the keychain etc. I got rid of this…

How is 1password safer than the local keychain?

The keys never leave the 1Password store. So you don’t have the keys on the local file system. That and that these keys are shared over the cloud was the seller for me. I guess security wise it’s a bit of a downgrade compared to resident keys. But the agent support agent forwarding etc which wasn’t really working with yubi ssh resident keys. Also worth mentioning that I use 1Password. Bitwarden has a similar feature as far as I know. For the ones who want to self host etc might be the even better solution.

Re: Gpg.fail

#75
post #42
post #19

Earlier quoted context omitted.

They presented critical parser flaws in all major PGP implementations, not just GNU PGP, also sequoia, minisign and age. But gpg made the worst impression to us. wontfix

Since when are age or minisign PGP implementations?

The talk title includes "& Friends", for what it's worth.

Re: Gpg.fail

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

> already trusted because it was downloaded over HTTPS from a trusted server (making PGP kind of redundant in some ways)

That's mostly incorrect in both counts. One is that lots of mirrors are still http-only or http default https://launchpad.net/ubuntu/+archivemirrors

The other is that if you get access to one of the mirrors and replace a package, it's the signature that stops you. Https is only relevant for mitm attacks.

> they'd be more likely to start a migration away from PGP

The discussions started ages ago:

Debian https://wiki.debian.org/Teams/Apt/Spec/AptSign

Fedora https://lists.fedoraproject.org/archives/list/packaging@list...

Re: Gpg.fail

#77
post #74

Earlier quoted context omitted.

How is 1password safer than the local keychain?

The keys never leave the 1Password store. So you don’t have the keys on the local file system. That and that these keys are shared over the cloud was the seller for me. I guess security wise it’s a bit of a downgrade compared to resident keys. But the agent support agent forwarding etc which wasn’t really working with yubi ssh resident keys. Also worth mentioning that I use 1Password. Bitwarden has a similar feature…

> The keys never leave the 1Password store. So you don’t have the keys on the local file system.

Keychain and 1Password are doing variants of the same thing here: both store an encrypted vault and then give you credentials by decrypting the contents of that vault.

Re: Gpg.fail

#79
post #68

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…

Your mail either needs to be encrypted reliably against real adversaries or it doesn't. A private emailing circle doesn't change that. If the idea here is, a private group of friends can just agree never to put anything in their subjects, or to accidentally send unencrypted replies, I'll just say I ran just such a private circle at Matasano, where we used encrypted mail to communicate about security assessment projects, and unencrypted replies happened.

Re: Gpg.fail

#80
post #66
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…

> 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-established channel) or devolves to the other party serving up their pubkey over HTTPS on their website.

Post reply on HN