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

331–340 of 369 posts

Re: The PGP Problem

#331

Post by pvg »

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)

This is great, thanks for writing it!

Brings to mind the words of renowned Victorian lifehacker Jerome K. Jerome:

“I can't sit still and see another man slaving and working. I want to get up and superintend, and walk round with my hands in my pockets, and tell him what to do. It is my energetic nature. I can't help it.”

Re: The PGP Problem

#332

Post by throw0101a »

jcranmer wrote: post #49
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…

In modern practice, email is sent over TLS sockets already. Any good email client should prohibit you from using SMTP, POP, or IMAP with TLS, and for the past few years, even the MX-MX transfers in the backend have started to become protected (albeit mostly opportunistically at this point, I believe) with TLS. So the only people who can read email are you, your counterparty, your ESP, and your counterparty's ESP, ass…

> Any good email client should prohibit you from

Most e-mail servers required a login (regardless of fetching or sending), and it would take a real incompetent sysadmin to allow that to happen in the clear.

Re: The PGP Problem

#333

Post by throw0101a »

Godel_unicode wrote: post #67
jcranmer wrote: post #49

Earlier quoted context omitted.

In modern practice, email is sent over TLS sockets already. Any good email client should prohibit you from using SMTP, POP, or IMAP with TLS, and for the past few years, even the MX-MX transfers in the backend have started to become protected (albeit mostly opportunistically at this point, I believe) with TLS. So the only people who can read email are you, your counterparty, your ESP, and your counterparty's ESP, ass…

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…

> I do however think that it's important to note that opportunistic STARTTLS is vulnerable to downgrade attacks by mitm

See SMTP MTA Strict Transport Security (MTA-STS):

* https://tools.ietf.org/html/rfc8461

And STARTTLS Everywhere:

* https://starttls-everywhere.org/

Re: The PGP Problem

#334

Post by meruru »

jobigoud wrote: post #157
meruru wrote: post #94

Earlier quoted context omitted.

You can put it on your website or anywhere really. Some people use keybase.io for this.

You can't put it anywhere really , otherwise anyone could tie their key to your identity. Keybase.io is a good solution.

You're technically correct of course.

Re: The PGP Problem

#335

Post by ihattendorf »

bigiain wrote: post #200
darawk wrote: post #145

Earlier quoted context omitted.

So, your threat model includes MITM servers, but not cameras? It seems a little silly to worry about the MITM problem when you can simply snap a photo already.

They are both valid threat models, but ones which for me have different meanings. Screenshotting or photographing the screen of a device owned my my intended message recipient is a reasonably small problem to me. If my recipient wants to expose a message I've sent them, they're going to be able to do that. I never expected any more privacy for that message than I'd have accepted based on my trust in that person. MITM…

I might be missing something, but how would large scale surveillance with searchable databases be possible with e2e encryption? They could save the messages, but they would still be encrypted.

Re: The PGP Problem

#336

Post by paulddraper »

gocartStatue wrote: post #192
paulddraper wrote: post #14

Earlier quoted context omitted.

Signing tags (or somewhat less usefully, commits) can be done the same way packages are signed. It might not be directly integrated with git, but it wouldn't be hard to make a good workflow. The article mentions Signify/Minisign. [1] [1] https://jedisct1.github.io/minisign/ as an PGP alternatie.

> It might not be directly integrated with git That's the problem I see. I have signingkey in .gitconfig, together with [commit] gpgsign = true. This way, set & forget, all my commits are signed (it's my employer requirement, probably some "compliance" stuff). You can see it right away nicely displayed as "Verified" on github. I didn't know about GPG-s supposedly weak security until now, but always considered it not…

Ah, well if your employer mandates PGP signatures on every commit, that's that.

FWIW, the creator of git argues that signing of every commit is essentially pointless. [1] I agree.

[1] http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...

Re: The PGP Problem

#337

Post by tptacek »

belorn wrote: post #330
tptacek wrote: post #307

Earlier quoted context omitted.

How do you write this after writing that previous comment, which says that what I just wrote is "terrible bad advice"?

Telling people to stop using the Internet because it is insecure is bad advice. It is extremely unrealistic, like telling people to stop using cars and trucks because driving kills people every year. However suggesting that we should change things to eliminate the risk is good. We could eliminate car accidents completely if everyone went over the automatic driven cars that communicated as a mesh network. The Swedish…

The PGP team openly and enthusiastically discusses how they've advised dissidents in places like Venezuela, about which just recently the NYT ran an expose of death squads sponsored by the Maduro administration. What they're telling dissidents to do has to work. It demonstrably doesn't. Pretending otherwise, because everyone else does it, is malpractice. I don't understand where the wiggle room people are finding on this issue is.

Re: The PGP Problem

#338

Post by tptacek »

dewyatt wrote: post #290
tptacek wrote: post #51

Earlier quoted context omitted.

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.

You can probably agree about the PGP packet design?

Re: The PGP Problem

#339

Post by dewyatt »

tptacek wrote: post #338
dewyatt wrote: post #290

Earlier quoted context omitted.

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

You can probably agree about the PGP packet design?

Yes, it depends on what you mean. The packets themselves aren't a big deal to me, it's more the ability to construct them in arbitrary ways that concerns me.

Re: The PGP Problem

#340

Post by trabant00 »

Natanael_L wrote: post #263
trabant00 wrote: post #87

The problem with the alternatives is they are product specific and baked into that product. I need a tool that is a separate layer that I can pipe into whatever product I want, be it files, email, chat, etc. Managing one set of identities is hard enough thank you very much and I also want to be able to switch the communication medium as needed. I use gnupg a lot and I'm certainly not very happy with it but I guess it…

The problem with this is that a tool that is too generic is itself dangerous, because it creates cross protocol attacks and confusion attacks like in https://efail.de for PGP email. I think that a better approach is to bind identities from multiple purpose built cryptographic protocols.

If you blame gpg for efail you can blame anything really for a virus on one of the endpoints of any form of encryption.

Next you will hold rensponsible tech for social engineering and mandate users should not know their own secrets because that causes vulnerabilities in protocols :p

Post reply on HN