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

161–170 of 369 posts

Re: The PGP Problem

#161

Post by geocar »

tialaramex wrote: post #149
Godel_unicode wrote: post #67

Earlier quoted context omitted.

This is an excellent explanation overall, I do however think that it's important to note that opportunistic STARTTLS is vulnerable to downgrade attacks by mitm. Since this would have to be a mitm of e.g. Gmail it's not trivial by any means, but neither is it completely out of reach (see for example the periodic rerouting of the internet caused by odd BGP advertisements). One further note is that you can know post-hoc…

This is often explained in a needlessly confusing way. STARTTLS isn't a problem, the problem is if a user checks a box (or moral equivalent) saying it's optional obviously bad guys will opt for "No". If your client is set to _require_ STARTTLS, then an adversary blocking STARTTLS has the same effect as if they just blocked the IP address of the mail server, you get an error and it doesn't work. There's no reason to u…

It may be better than nothing, but it's far from a sure thing: If you can BGP announce an IP, you can get a certificate from letsencrypt.

This is a trivial attack vector not just for state-actors, but also stupid kids: in the early 2000s, I announced Microsoft's AS from my own network (AS21863) to see what would happen and got a significant amount of microsoft.com's traffic. There was no security, and there still isn't: Most multihomed sites that change links frequently inevitably find themselves unfiltered either through accident or misplaced trust.

For this reason, TLS without key-pinning (even with IP filtering, as is popular with a lot of banks/enterprise) is far less secure than people realise, and on unattended links (server-to-server relaying) it offers only some casual confidentiality (since detection is unlikely) at best.

If you use MTA-STS, you have a good chance of detecting this kind of attack though. I've not seen anyone use a long policy on a distant but popular network to require someone BGP hijack two big networks to beat it, but I suspect such a disruption would be felt across the Internet.

Re: The PGP Problem

#162

Post by Leace »

> there’s a simple meta-problem with it: it was designed in the 1990s, before serious modern cryptography

SSL was designed in 1994 but it has been properly maintained and today no-one argues that TLS should be replaced by noise/strobe etc. OpenPGP's problem no 1. is that there are no parties using it on a wider scale and interested in improving it.

Re: The PGP Problem

#163

Post by cyphar »

PeterisP wrote: post #158
cyphar wrote: post #144

Earlier quoted context omitted.

Signal -- and all other OTR-like protocols -- have deniability (or if you prefer it has repudiation rather than non-repudiation). Neither conversation participant can prove to a third party that the other party said something in a conversation. Moxie wrote a blog post about this in 2013[1]. The only circumstance in which you want non-repudiation is if you are really sure that you are okay with the recipient of your m…

Sure, you usually don't want that feature in private setting, but you almost always want that feature in a commercial setting, and lots of communication happens in that context. E.g. vendor-customer helpdesk chat, internal workplace communication including "less internal" things like different subsidiaries of international companies, etc, etc. Half of financial world runs on Thompson Reuters messenger which is essent…

I think our main disagreement is the usage of the word "usually". There are chat systems that have non-repudiation that aren't PGP -- I don't think there's much more to elaborate.

For personal communications, usually people want deniability. For business-related communication, you might want non-repudiation.

Re: The PGP Problem

#164

Post by Leace »

> Long term keys are almost never what you want. If you keep using a key, it eventually gets exposed. You want the blast radius of a compromise to be as small as possible, and, just as importantly, you don’t want users to hesitate even for a moment at the thought of rolling a new key if there’s any concern at all about the safety of their current key.

Interestingly some protocols such as roughtime use the same tactic as OpenPGP: one long-term identity key that can be kept offline and rotation of online (short-term) keys signed by the long-term key. Details here: https://roughtime.googlesource.com/roughtime/+/HEAD/PROTOCOL...

Re: The PGP Problem

#165

Post by dchest »

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

Re: The PGP Problem

#166

Post by Leace »

simonh wrote: post #78
Sniffnoy wrote: post #48

Earlier quoted context omitted.

Good question. Not sure. Although I don't see why I wouldn't, if they have a PGP key listed? (I guess there is some question over whether the listed key is actually them?) But my point is that, well, email is a good way to do that, and Signal isn't, so I'm going to use email rather than Signal. Honestly, I wouldn't focus on (3), because as I see it, if you can replicate the feel of email, things like (1)-(2), so that…

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

I guess they mean putting the key on a webpage or using Web Key Directory or a centralized service such as https://keys.openpgp.org

Re: The PGP Problem

#167

Post by tialaramex »

lotharrr wrote: post #147
eadmund wrote: post #35

Earlier quoted context omitted.

> Are you saying 2 -16 success isn't good enough? I really don't think it is, because it might be worthwhile for a particular sort of attacker, say one who runs the default rendezvous server: observe global activity, attempt to MitM every connexion for 30 seconds, then write up a spurious blog post about a 'network issue' or 'bug' or whatever which caused a brief outage. N:2^16 is okay* against targeted attacks, most…

(magic-wormhole author here) It's probably worth pointing out that the 2^-16 chance is per invocation of the protocol.. it's not an offline attack. So you'd have to be reeeealy patient to run it enough times to give the attacker a decent chance of success. The best attack I can think of would be for me (or someone who's camped out on my rendezvous server) to make an MitM attempt on like one out of every 100 connectio…

Yeah, I think that current default sails too close to the wind. 2^-16 chance on a stochastic MitM attack feels fine statistically - and then you think about that one person who it worked on. For them it wasn't 2^-16 it was binary, it didn't work.

They just used your "secure" file transfer mechanism and their data got stolen.

You're on the same side of this as the airline industry. The person driving a car understands intellectually that their drowsy half-attention to the road is statistically going to kill them, whereas travelling in coach on a mid-range two engine jet liner is not - but emotionally they consider driving to be fine because they're doing it, and air travel is trusting some random stranger. As a result, the industry need to make air travel so ludicrously safe that even though emotionally it still feels dangerous the passengers will put that aside.

2^-16 is intellectually defensible, but my argument above is that shouldn't be what you're going for. So that's why I'd suggest a longer code by default.

Re: The PGP Problem

#168

Post by jlgaddis »

simonh wrote: post #78
Sniffnoy wrote: post #48

Earlier quoted context omitted.

Good question. Not sure. Although I don't see why I wouldn't, if they have a PGP key listed? (I guess there is some question over whether the listed key is actually them?) But my point is that, well, email is a good way to do that, and Signal isn't, so I'm going to use email rather than Signal. Honestly, I wouldn't focus on (3), because as I see it, if you can replicate the feel of email, things like (1)-(2), so that…

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 certifying signatures from other people, with the expectation that anyone receiving it will trust at least one or two of the signatures. This will cause the emergence of a decentralized fault-tolerant web of confidence for all public keys.

[0]: https://en.wikipedia.org/wiki/Web_of_trust

Re: The PGP Problem

#169

Post by namibj »

cyphar wrote: post #160
always4getpass wrote: post #152

Earlier quoted context omitted.

What about its 'crypt' encryption backend? Afaik it uses scrypt which was designed for tarsnap

Ah, I wasn't aware it had an encryption backend. Just looking at the documentation I'm quite worried -- why on earth is there an "obfuscate" mode? I would suggest using restic. It doesn't have any weird modes, it simply encrypts everything and there isn't any weird need to specify (for instance) that you want things like metadata or filenames encrypted. Also backups are deduplicated using content-defined-chunking --…

It's a choice between plaintext filenames or no plaintext filenames.

You might want to crypt your nudes, but still access normal pictures unencrypted through the provider's web interface.

Re: The PGP Problem

#170

Post by pca »

txcwpalpha wrote: post #132
jeroenhd wrote: post #82

Whent talking about alternatives, Signal and WhatsApp get mentioned because they're easy to use. They are. Signal is pretty secure. WhatsApp probably is as well but we can't be sure. That is, until it isn't anymore. WhatsApp already has a key extraction protocol built right in for its Web interface. Signal has a web (Electron) interface as well, and a shitty one at that, where the messages also get decrypted. For Wha…

>WhatsApp already has a key extraction protocol built right in for its Web interface. I don't believe this is correct. WhatsApp (and Signal AFAIK) web works by decrypting the original message on your phone, re-encrypting it with a different key that is shared with your web interface (this is what is being shared via the QR code when connecting to WhatsApp Web), sending it to the web client, and having your web client…

Signal-Desktop works even when your phone is turned off.
Post reply on HN