The PGP Problem • Hacker News Board

Re: The PGP Problem

#201

Post by __david__ » Wed, Jul 17, 2019, 11:01 AM UTC

loup-vaillant wrote: post #177

umvi wrote: post #43

Earlier quoted context omitted.

I don't get what's insecure about normal unencrypted email. It's sent over https, isn't it? It's not like I can read your emails unless I break into Google's servers, no? And even if I do, they probably aren't even stored in plaintext. I just don't get the encrypted email obsession. It's impossible for an individual to withstand a targetted cyber attack so it seems pointless to go above and beyond to ultra encrypt ev…

> It's sent over https, isn't it? That's actually more complicated than that. If you're using a web mail, your connection to the mail provider most likely uses HTTPS. That is, HTTP over TLS. When the mail is sent , it depends whether the recipient uses the same provider or not. If it's the same provider, well, protocols are irrelevant. If not, it will usually be SMTP over TLS (minus any potential problems with STARTT…

Also, it might surprise some people just how many servers an email travels through to get to its destination. I just grabbed a random mail from a mailing list I'm on (generally a worst case scenario) and it had 7 Received headers. Every mail server is supposed to add a Received header when the mail passes through but there's no way to enforce that, so all I can really say is that mail probably passed through at least 7 servers on it's way to my inbox.

Each one of those hops may or may not have talked TLS to the next hop. Each one probably wrote the mail out to a disk based mail queue in plaintext. There is nothing preventing any of those 7 servers from keeping around that mail even though they forwarded it on. There is nothing preventing them from indexing the mail for spam or marketing purposes.

Re: The PGP Problem

#202

Post by goffi » Wed, Jul 17, 2019, 11:05 AM UTC

progx wrote: post #154

Messenger are not easier than email, only when 2 ore more communicate on one topic. But with email you communicate with one or more people about many topcis. To archieve the same structure in a messenger, you must create several discussions. So messenger are not the holy grail of communication, that is why people still use email. We need an email user interface with open messenger protocols under the hood for secure…

For a proof of concept, I've made a couple of years ago a "gateway" which was launching a local IMAP server in my XMPP client. This way you could use any MUA you like while taking profit of XMPP infrastructure (JID — XMPP identifier — are similar to email addresses) and its encryption (OMEMO can be used with that for instance). In other words, you could send messages from Thunderbird (or Gajim) to KMail by using only XMPP protocol (and thanks to IMAP Push, you got notifications immediately).

Re: The PGP Problem

#203

Post by tinus_hn » Wed, Jul 17, 2019, 11:05 AM UTC

umvi wrote: post #43

Sniffnoy wrote: post #38

So what do I use for encrypted messaging that can, like, replace email, then? Nobody seems to have provided any sort of satisfactory answer to this question. To be clear, an answer this has to not just be a secure way of sending messages, it also has to replicate the social affordances of email. E.g., things distinguishing how email is used from how text-messaging is used: 1. Email is potentially long-form. I sit dow…

I don't get what's insecure about normal unencrypted email. It's sent over https, isn't it? It's not like I can read your emails unless I break into Google's servers, no? And even if I do, they probably aren't even stored in plaintext. I just don't get the encrypted email obsession. It's impossible for an individual to withstand a targetted cyber attack so it seems pointless to go above and beyond to ultra encrypt ev…

The old ‘security is hard so let’s not do it’ argument. Emails are not properly encrypted in transit and are available for access at the provider if a court decides to grant a warrant. That might not be enough protection for everyone.

It is possible for a determined individual to withstand targeted attacks if he’s careful and willing to make the sacrifices that come with the territory.

Re: The PGP Problem

#204

Post by newscracker » Wed, Jul 17, 2019, 11:09 AM UTC

vetrom wrote: post #47

srl wrote: 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…

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…

> Signal does a great job of supporting activists.

I don’t think it practically achieves this. Even now, Signal is an unreliable platform to communicate with. One can’t be sure if the message will reach in a timely manner (like a few seconds or several seconds) or even reach at all. The UX and feature set are also far behind something like Wire.

I’ll accept that Signal has a strong and reputed protocol, and has take some strong measures on security and privacy. But everything else about is truly meh, to put it mildly.

Please don’t dismiss these points about reliability saying it has never failed for you or someone you know. It routinely fails for people I know, and that’s all that matters when recommending a messenger platform to others.

Signal has made it seem like security is easy to focus on (though a lot of thought and work has gone into it), but has shown that UX or pretty hard and that running a platform is even harder (even at Signal’s scale, which I presume is a fraction of other platforms).

Re: The PGP Problem

#205

Post by connorlanigan » Wed, Jul 17, 2019, 11:10 AM UTC

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." [1]

The way I understand it, you could simply share your part of the number on your website, but Moxie recommends against it, since this fingerprint changes between reinstalls.

[1] https://signal.org/blog/safety-number-updates/

Re: The PGP Problem

#206

Post by aljungberg » Wed, Jul 17, 2019, 11:11 AM UTC

dunkelheit wrote: post #197

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…

> > Put a Signal number on your security page to receive bug bounty reports, not a PGP key. Does anyone actually do this? Even Signal developers themselves don't! (see https://support.signal.org/hc/en-us/articles/360007320791-Ho... ). Instead there is a plain old email address where you are supposed to send your Signal number so that you can chat.

If the people from Signal start a conversation with you on the number you emailed, how do you know it’s actually them? Couldn’t it be a third party who intercepted your email?

You need to check their “safety number”, and now we’re back to the same idea as with PGP with web of trust and key sharing parties.

At some point you still need some kind of pub-key identity check if you don’t want to accidentally report your vulnerability to PRC instead.

Re: The PGP Problem

#207

Post by tinus_hn » Wed, Jul 17, 2019, 11:14 AM UTC

geocar wrote: post #161

tialaramex wrote: post #149

Earlier quoted context omitted.

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…

Letsencrypt supposedly has deployed a system that makes the connections from different locations around the world to make this attack more difficult and also you can’t get a letsencrypt certificate for gmail.com or microsoft.com (or Gmail.* or microsoft.* for that matter), there’s a block list for high value targets.

Re: The PGP Problem

#208

Post by book-mind » Wed, Jul 17, 2019, 11:15 AM UTC

tptacek wrote: post #2

Really, all I did here was combine posts from Matthew Green, Filippo Valsorda, and George Tankersley into one post, and then talk to my partner LVH about it. So blame them. (also 'pvg, who said i should write this, and it's been nagging at me ever since)

Is it wrong to use openssl to encrypt files?

0. (Only once) generate key pair id_rsa.pub.pem, id_rsa.pem

1. Generate random key

  openssl rand -base64 32 > key.bin

2. Encrypt key

  openssl rsautl -encrypt -inkey id_rsa.pub.pem -pubin -in key.bin -out key.bin.enc

3. Encrypt file using key

  openssl enc -aes-256-cbc -salt -in SECRET_FILE -out SECRET_FILE.enc -pass file:./key.bin

-- other side --

4. Decrypt key

  openssl rsautl -decrypt -inkey id_rsa.pem -in key.bin.enc -out key.bin

5. Decrypt file

  openssl enc -d -aes-256-cbc -in SECRET_FILE.enc -out SECRET_FILE -pass file:./key.bin

Re: The PGP Problem

#209

Post by Avamander » Wed, Jul 17, 2019, 11:22 AM UTC

tialaramex wrote: post #134

Avamander wrote: post #121

Earlier quoted context omitted.

Telegram invented it's own crypto, without an audit it's untrustworthy. There's only Signal and Keybase that has been audited, so Whatsapp should be excluded from the list of trustworthy IM apps as well.

Whatsapp uses the exact same technology as Signal. If you consider that Signal is fine based on an audit of what is clearly an older version (do audits come out every day with new Signal releases? No, so the code you're running wasn't covered by the audit) then Whatsapp is fine based on being the same protocols with different branding.

An audited piece of software with relatively minor changes is definitely far more trustworthy than a piece of software that is much much more different. Whatsapp is garbage compared to Signal.

Re: The PGP Problem

#210

Post by Perceptes » Wed, Jul 17, 2019, 11:23 AM UTC

akerl_ wrote: post #189

Leace wrote: post #162

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

I’d argue for replacing TLS if it were plausible to replace TLS for mainstream users. HTTPS is a dumpster-fire for a lot of the same reasons PGP is. For example, the fact that there’s a grab bag of different ciphers, compression options, and other toggles makes properly picking settings an exercise in copy-pasting from a site you trust or guessing and then running an SSL Labs test until it comes back green. If you mi…

I guess one difference here is that often major implementations of HTTPS make the best choices (like operating systems, major browsers, major web server software, etc.), whereas with something like PGP, everyone is using GPG which has only one implementation which is known to be terrible.