Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The PGP Problem

latacora.micro.blog

Post reply on HN
Print view View original

271–280 of 369 posts

Re: The PGP Problem

#271

Post by dewyatt »

dchest wrote: post #165
taeric wrote: 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 ...

This is more an issue with GnuPG though, not OpenPGP.

Also, you may want to try using an actual OpenPGP Card (https://www.floss-shop.de/en/security-privacy/smartcards/13/...). (You can get a small one inside a USB token too)

Re: The PGP Problem

#272

Post by pgeorgi »

NoGravitas wrote: post #252
pgeorgi wrote: post #116

Earlier quoted context omitted.

I'm running a "beta test" of sorts of XMPP+OMEMA with non-technical people in my circles, and while Conversations (Android) and Monal (iOS) are getting there, there are still functionality and compatibility gaps. Gajim is a usable client for desktops, but it's certainly picky about which users it is friendly with (that is, I can't recommend it to non-technical folks). On the other hand "it uses IDs like email" is a c…

As far as usable desktop XMPP+OMEMO clients go, Dino is much friendlier to non-technical users, but paradoxically, it's only available on Unix-like OSes. It runs on WSL and is probably buildable for X on MacOS, but by that point, you've lost non-technical users in both cases.

Wow, that one looks good. Thanks for the pointer!

I wonder how much is in there that precludes cross-compiling to Windows.

Re: The PGP Problem

#273

Post by tialaramex »

connorlanigan wrote: post #205
tialaramex wrote: post #183

There's a few places where this engages in goalpost shifting that seems less than helpful even though I end up agreeing with the general thrust. Let's focus on one: > Put a Signal number on your security page to receive bug bounty reports, not a PGP key. We can reasonably assume in 2019 that this "security page" is from an HTTPS web site, so it's reasonably safe against tampering, but a "Signal number" is just a phon…

The safety number is only partly per-conversation. If you compare safety numbers of different conversations, you'll discover that one half of them is always the same (which half that is changes depending on the conversation). This part is the fingerprint of your personal key. The Signal blog states that "we designed the safety number format to be a sorted concatenation of two 30-digit individual numeric fingerprints.…

Ah! Yes, I see. You'd need to figure out which is "your" half, which the application as it exists today doesn't help you to do since that's not what they're going for. The person initiating would need to send something to establish a conversation, like "Er, hi?" and then once that conversation exists they can verify the number shown on your web page matches half of the displayed safety number as expected and actually proceed.

It's clunky, but less so than I feared. I can actually imagine a person doing this. I mean, they won't, but like PGP this is something a person _could_ do if they were motivated and competent.

Re: The PGP Problem

#274

Post by Natanael_L »

mikorym wrote: post #83

First of all, if you are signing something and want to prove that you are the author, then PGP will allow you to do that. If you want to encrypt something and prove you are the author, PGP will still allow you to do that. Does the author mean that PGP is bad for email specifically? Excel has many of the mentioned properties, such as backwards compatibility and inefficiency, but it gets the job done and you bet it wil…

With "Johnny you're fired", it's clear that many clients don't correctly validate PGP signatures

Re: The PGP Problem

#275

Post by dunkelheit »

lvh wrote: post #266
tptacek wrote: post #248

Earlier quoted context omitted.

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.

Anecdote about said startups: in 2y of the one big bounty that did have a PGP key, we got one PGPd report, and it was “session takeover”: if I copy the cookie out of Burp and into a new Incognito session, I will be logged in. Bounty plz? We also got super clever reports on that same bounty program. They just sent email.

Maybe all PGP users are morons, that's beside the point. My point is that if someone recommends something but doesn't follow their own recommendation, it is most likely that the recommendation is not well thought-out and can be ignored. In this case the recommendation to use Signal looks more like a refutation of the point brought up by PGP advocates and not something that anyone would actually do.

Re: The PGP Problem

#276

Post by Natanael_L »

mike_hearn wrote: post #270
Natanael_L wrote: post #232

Earlier quoted context omitted.

The CA system as set up today is a bit fragile and much too limited, though. If it was all we needed, everybody would be using S/MIME with signed certs. We need something more expressive than the current CA system, where you can make the choice to define your own trusted roots.

You can always edit the trust store to add or remove certs your local computer trusts. That's easy, there are even GUI tools available to do it. Heck on MacOS there's even a GUI wizard to create a local CA from scratch! Nobody does it because the hard part of being a CA isn't the protocol part, it's convincing everyone that you're going to do a good job of issuing certificates. The WoT just ignores that problem entir…

But you can't trivially define your own scopes wherein each has their own independent set of trusted CA:s. That's part of what's missing. But default it's universal or per program.

Just look at every kind of umbrella organization out there like industry specific auditors with a scope limited to a field (medical, finance, food safety), or even hobby organizations with a parent organization auditing local chapters.

You don't go to the social security office to look up your neighbors phone number when you need to talk to them. The attributes people care about are often more local, more narrow.

People first go to local trust anchors to get information about things (and their software clients could then traverse various directories up to a root and back down, if necessary). I need my client to be able to understand an assertion from an entity far more personal to me than a distant CA. The CA:s are most useful in ephemeral connection, not long term ones.

This is what I mean when I say the CA system isn't expressive enough.

Re: The PGP Problem

#277

Post by zaphar »

jlgaddis wrote: post #168
simonh wrote: post #78

Earlier quoted context omitted.

How does one list a public PGP key, is there a verified central listing service?

One of the major features of PGP is that you don't have to rely on -- trust -- a "verified central listing service". The "Web of Trust" [0] fills that role: > As time goes on, you will accumulate keys from other people that you may want to designate as trusted introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually accumulate and distribute with their key a collection of…

In practice a web of trust is only trustworthy 1 degree out from you. Just because you trust someone doesn't mean you should trust the people they trust. The web of trust is a difficult to use misfeature. In theory it's great. In practice it's unusable.

Re: The PGP Problem

#278

Post by lvh »

dunkelheit wrote: post #275
lvh wrote: post #266

Earlier quoted context omitted.

Anecdote about said startups: in 2y of the one big bounty that did have a PGP key, we got one PGPd report, and it was “session takeover”: if I copy the cookie out of Burp and into a new Incognito session, I will be logged in. Bounty plz? We also got super clever reports on that same bounty program. They just sent email.

Maybe all PGP users are morons, that's beside the point. My point is that if someone recommends something but doesn't follow their own recommendation, it is most likely that the recommendation is not well thought-out and can be ignored. In this case the recommendation to use Signal looks more like a refutation of the point brought up by PGP advocates and not something that anyone would actually do.

That’s a fair criticism and I will happily admit that’s what it should say: that all PGP users are morons. (Just kidding. You’re right re: bug bounty advice.)

Re: The PGP Problem

#279

Post by jcranmer »

book-mind wrote: post #235
tptacek wrote: post #224

Earlier quoted context omitted.

To start with, none of that encryption is authenticated.

So if I understand you correctly (Noob here), Alice would need to sign the pair (key.enc, file.enc) to authenticate that those files originated from her. Without that, Bob could potentially receive any pair of (key,file), which would just decrypt into garbage data. BTW, variations on that sequence appear all over the internet when searching for "openssl encrypt file with public key"...

This is one of the problems with cryptography: with a little knowledge, you can end up making yourself completely insecure while believing yourself to be very secure.

People generally imagine that "encrypt this block of data" is a simple primitive that does everything you want it to. But naive encryption doesn't work like that. In the worst case, where you use ECB for the block cipher [1], you end up with the ECB penguin: https://blog.filippo.io/the-ecb-penguin/. Your secure crypto becomes a pretty trivial Caesar cipher, just on a larger alphabet. Other modes (such as the CBC mode you used) aren't so bad, but if you have some hint of the structure of the underlying data, you can start perturbing the ciphertext to manipulate the encrypted data.

The modern solution to that problem is "authenticated encryption," which means that you add in an additional guarantee that the ciphertext hasn't been tampered with. Even then, there is still room for doing things incorrectly (padding is a real pain!).

[1] This is so bad it shouldn't ever be an option in any tool.

Re: The PGP Problem

#280

Post by belorn »

mike_hearn wrote: post #228
bennofs wrote: post #176

I understand that there are better tools for encryption, but is there anything that replaces the identity management of PGP? Having a standard format for sharing identities is necessary in my opinion. If I have a friend (with whom I already exchanged keys) refer me to some third friend, it would be nice if he can just send me the identity. Sending me the signal fingerprint isn't a solution for two reasons: - I don't…

The CA system is strictly better than PGP for identity management in every respect. People often think it must be the opposite but this is essentially emotional reasoning: the Web of Trust feels decentralised, social, "webby" un"corporate", free, etc. All things that appeal to hobbyist geeks with socialist or libertarian leanings, who see encryption primarily through the activist lens of fighting governments / existi…

Are we talking about extended validation or domain validation?

With domain validation it is likely better to use dane in the context of email. The sender looks up the key and mx record and act accordingly, and for postfix there are plugins that already do it. Very few current users however.

Post reply on HN