Live data from Hacker News

The PGP Problem

latacora.micro.blog

171–180 of 369 posts

Re: The PGP Problem

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

Good point, private channels are the new discussions. But they tend to never die so over the years we end up with a cluttered channel list.

Re: The PGP Problem

#172
post #163

Earlier quoted context omitted.

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.

Probably the point I'm trying to make is that for me the communication scenarios seem similar enough, and the line between business and consumer comunication is so blurry with people using private mobile devices in business and expecting the same set of tools to cover all their communication, that saying "oh, there's another tool that does it the opposite way" isn't really a sufficient answer - perhaps we need to treat it as essentially a "flag" in the same tool; this useraccount/chatgroup/etc is authenticated and doesn't have any deniability whatsoever, but in the same app over there I have a pseudonymous contact with a marker over it that's effectively anonymous with full deniability and OTR communications.

Re: The PGP Problem

#173
post #78

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?

If you control your own domain, Web Key Directory [0] is a good option too.

[0]: https://wiki.gnupg.org/WKD

Re: The PGP Problem

#174
post #29
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…

Arch Linux's pacman is not a good example of a secure package distribution system (especially not the AUR, where you are downloading all the bits from the internet and building them yourself as your own user or even sometimes as root). They didn't do any package signing or verification at all until (shockingly) recently -- less than 10 years ago IIRC. I am a huge fan of Arch's philosophy but am definitely not a fan o…

If you have to trust the package maintainer what's the difference between having package signed by them or not?

For the record AUR packages can use GPG keys, see e.g. GPGKEY variable: https://wiki.archlinux.org/index.php/Makepkg#Configuration

Arch also uses Web of Trust to introduce Trusted Users: https://www.archlinux.org/master-keys/ so I wouldn't call "less than 10 years" as a disadvantage, but rather advantage - they have seen problems with alternative designs (e.g. Debian's curated keyring) and came up with something better.

Re: The PGP Problem

#175

Earlier quoted context omitted.

Really? When gmail came out they were explicitly up front about using the content of the email to deliver targeted ads. Has that changed?

There are a lot of misinformations around, and the Google haters crowd has plenty of pitchforks. https://safety.google/privacy/ads-and-data/ > Google does not use keywords or messages in your inbox to show you ads. Nobody reads your email in order to show you ads.

It's just the passage of time that has rendered it misinformation. Until not so long ago, Gmail messages were actually scanned for ads -- IIRC, Google was actually pretty upfront about it when they first launched Gmail, and explained that it's how they could afford to give users 1G of inbox space in a day and age where 25 MB was pretty good and 100 MB was pretty hard to get for free.

They eventually stopped, although the phrasing of the privacy policy is vague enough that, as wodenokoto mentions above, I wouldn't be surprised if email messages were still scanned for some advertising purposes. The fragment on the page you link to is only about ads shown in Gmail, doesn't exclude using keywords and messages for tracking, classifying etc. (it just doesn't use them "to show you ads") and doesn't actually exclude using programs to process messages (i.e. you can still reasonably say that "nobody reads" messages if you just feed them into a program). It's also not very obvious if "messages in your inbox" also includes messages you send.

FWIW, I think the policy is deliberately open-ended so as to be future-proof, but I doubt emails are an important source of advertising data today, so I think it's likely that Google doesn't rely on it that much anymore. Most sources of legitimate (i.e. non-spam email) that are useful for advertising -- e.g. online shops and the like -- already track you and show you ads, and Google is already deeply embedded there. Millions and millions of personal accounts are an useful strategic asset to have but I think there are better sources of data.

Re: The PGP Problem

#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 want to be manually comparing hashes in 2019

- it locks me into signal, I wont be able to verify a git commit from that person as an example

Is there a system that solves this? Keybase is trying but also builds on PGP, we can use S/MIME which relies on CAs but is not better than PGP. Anything else?

Re: The PGP Problem

#177
post #43

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…

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

The main problem with that is that the mail is not encrypted on the various servers it goes through. Only the server-to-server connections are encrypted. So your provider can access your email, and so can the recipient's. When that provider's business model is reading your emails so it can send you targeted adds, this is less than great. (Yes, Google reads your emails. They try to reassure you by telling you their employees don't read it, but the fact the process is automated actually makes it worse.)

Re: The PGP Problem

#179
post #123
post #120

Earlier quoted context omitted.

I'm a little confused as to why you mention Signal and WhatsApp but not Telegram?

Most cryptographers do not see Telegram as a secure encrypted protocol. This is for two reasons: the first one is that Telegram doesn't do end-to-end encryption by default (and if you enable it, functionality is limited). And secondly, they roll their own cryptographic protocol.

[deleted]

Re: The PGP Problem

#180
But.. it's the only thing we have. Until some "pgp alternative" for signing and encrypting emails comes along, and is adopted by "most" email clients, it's the best thing we've got, even if it's "bad".
Post reply on HN