Live data from Hacker News

The PGP Problem

latacora.micro.blog

281–290 of 369 posts

Re: The PGP Problem

#281
Until a better solution is brought forward, my team implemented a PGP packet library to make everyone's lives a little bit easier: https://github.com/summitto/pgp-packet-library

Using our library you can generate PGP keys using any key derivation mechanism for a large variety of key types! When using it right, this will greatly improve how you can generate and back up your keys!

Re: The PGP Problem

#282
post #79

I was an engineer at PGP from 2004-2011 and ended up running the server team as lead engineer. I wouldn't disagree with most of the points brought up by the author, both the code base and standard has accreted over time and it's incredibly complex. There were only a couple of people on the team that really understood all the facets of either the OpenPGP or SMIME/x509 standards. It's made worse in that it was a hack o…

Until a better solution is brought forward, my team implemented a PGP packet library to make everyone's lives a little bit easier: https://github.com/summitto/pgp-packet-library

Using our library you can generate PGP keys using any key derivation mechanism for a large variety of key types! When using it right, this will greatly improve how you can generate and back up your keys!

Re: The PGP Problem

#283

Until a better solution is brought forward, my team implemented a PGP packet library to make everyone's lives a little bit easier: https://github.com/summitto/pgp-packet-library Using our library you can generate PGP keys using any key derivation mechanism for a large variety of key types! When using it right, this will greatly improve how you can generate and back up your keys!

Does this improve on gpg2 —list-packets for practical debugging/auditing of extant GPG setups, or is just useful for people who want to do alchemy on top of the OpenPGP packet format?

Re: The PGP Problem

#284
post #21

First, thanks enormously for writing this -- and for all the other recent articles that have appeared here the vein of "PGP is as bad as it is unpleasant to use". It's a point I didn't really appreciate (at least as much as I (sh/c)ould have) and I'm sure I'm not alone. It seems that the state of package distribution for many distributions is poor, security-wise. (OpenBSD, to nobody's surprise, is an exception.) For…

I don't know where you found MD5, most PKGBUILDs have `sha256sums` in them. Package signing is (hot take!) overrated and can be somewhat theater. It helps if your package manager connects to third party mirrors, but otherwise, the only threat it protects against is "the https server is compromised but the package build farm is not". I don't know why anyone would worry so much about that.

> the only threat it protects against is "the https server is compromised but the package build farm is not"

Looking at an /etc/apt/sources.list, it doesn't look Ubuntu is using HTTPS for package distribution. Since you don't need both package signing and transport security, and I suspect that the list of packages you're downloading is a fairly trivial conversation length analysis anyways, I don't think the setup of signed packages over HTTP is meaningfully less secure than unsigned packages over HTTPS.

Re: The PGP Problem

#285
For backups, I would recommend Restic. The author mentions Tarsnap, and if you don't want to back up five terabytes that is probably great, but after a few gigabytes it's just not economical for private persons. If you're on hacker news (i.e. the 'engineer' the author was talking about), odds are that storing a hard drive connected to a raspberry pi at your parents' and using Restic as client is an extremely cheap way of backing up many terabytes securely.

Re: The PGP Problem

#286
post #165
post #97

I don't understand why the use of Yubikeys for a non-exportable key isn't valid for folks that care about security. I mean, I get that not everyone will use it. The vast majority won't. However, the vast majority don't care about security at this level. So... what is the actual criticism? If you care about security, use the keys, right? That feels no different from "use some other product."

The only thing in this world more complicated than setting up GPG is setting up GPG with Yubikey. The fact that I have `fix-gpg` script to restart gpg-agent somewhere in $PATH that I run when for some reason it can't find my YubiKey tells me that it's not a viable solution for 99% of people. PS. Actual command from GPG: > help ... sex change card holder's sex ...

On older machines, I agree. On recent installs, it just worked.

Getting it to work with my phone is slightly dumber. But still not super hard.

Re: The PGP Problem

#287
post #117

Telling people to treat email as insecure and thus not use it for anything serious is terrible bad advice. I am reminded of BGP (Border Gateway Protocol). Anyone who has even glanced at the RFC of BGP could write an essay of the horrible mess of compatibility, extensions, non-standard design of BGP. It also lack any security consideration. The problem is that it is the core infrastructure of the Internet. Defining so…

People that use email to convey sensitive messages will be putting themselves and others at risk, whether or not they use PGP, for the indefinite future. That's a simple statement of fact. I understand that you don't like that fact --- nobody does! --- but it remains true no matter how angry it makes you.

I would say that people that use any critical infrastructure not designed with security in mind is putting themselves and others at risk if they convey sensitive information. This is why plain text protocols should be considered insecure.

It would be great if we could replace the whole Internet with modern technology rather than relying on ancient systems like BGP and email.

Re: The PGP Problem

#288

Earlier quoted context omitted.

So even Latacora-advised startups use plain old email for bug bounties. Why then does the blog post recommend using Signal for that?

Because Signal would be better than the PGP theater. In practice, though, it doesn't matter; people are just going to use plain old email no matter what. They're not going to encrypt their findings to you.

> PGP theater

Hmm I don't see it as theater if you are unable to intercept and decrypt my message. Or forge my signature, etc.

Re: The PGP Problem

#289
post #285

For backups, I would recommend Restic. The author mentions Tarsnap, and if you don't want to back up five terabytes that is probably great, but after a few gigabytes it's just not economical for private persons. If you're on hacker news (i.e. the 'engineer' the author was talking about), odds are that storing a hard drive connected to a raspberry pi at your parents' and using Restic as client is an extremely cheap wa…

For Windows users that were wondering, Restic doesn't back up files that are opened exclusively.

VSS support on Windows is an open issue:

https://github.com/restic/restic/issues/340

Re: The PGP Problem

#290
post #51
post #47

Earlier quoted context omitted.

Signal does a great job of supporting activists. That's basically its intentional product focus. Everything an open source proponent engineer might want to promote is secondary. The focus on activism and trying to deal with large actors definitely looks like #1. Everything else about their product is secondary to that. Signal's product focus has been at best un-encouraging to those who want to use it for anything els…

The byzantine packet format in PGP buys PGP nothing. There is no engineering reason for PGP to work that way, and PGP continues to suffer security issues because of it. I'm not arguing that PGP's original designers were incompetent, nor am I considering that argument, because it is totally uninteresting to me. What is relevant to me is the fact that today, that design is costly and bad. What more is there to think ab…

I can probably agree on the packet format, it's excessively flexible and easy to implement insecurely.
Post reply on HN