The PGP Problem • Hacker News Board

Re: The PGP Problem

#191

Post by [deleted] » Wed, Jul 17, 2019, 10:26 AM UTC

Leace wrote: post #174

cyphar wrote: post #29

Earlier quoted context omitted.

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

[deleted]

Re: The PGP Problem

#192

Post by gocartStatue » Wed, Jul 17, 2019, 10:28 AM UTC

paulddraper wrote: post #14

luizfelberti wrote: post #6

The missing answer in there is how to avoid PGP/GnuPG for commit signing. I've asked about this in another similar thread[0] but didn't get a hopeful answer. Everytime I look at git's documentation GPG seems very entrenched in there, to a point that for things that matter I'd use signify on the side. Is there a better way? [0] https://news.ycombinator.com/item?id=20379501

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 very convenient to use.

Re: The PGP Problem

#193

Post by loup-vaillant » Wed, Jul 17, 2019, 10:29 AM UTC

lvh wrote: post #18

eadmund wrote: post #13

Magic Wormhole is neat, but the happy path is to use a third-party rendezvous server, which is susceptible to traffic analysis (I also wish that the codes had more than 16 bits of entropy, but that is part cargo-culting on my part). Signal is also vulnerable to server-side traffic analysis, and is strangely keen on both demanding a selector (a phone number) for identity and on trusting Intel's 'secure' enclave (I str…

Re: common core: isn't that already happening? age and signify are both based on those 2, and magic-wormhole arguably is too (though point addition is not always exposed, so SPAKE2 is a little harder to implement than signify).

Couldn't we instead just cut the shared password in 2 (or use 2 passwords, it's the same), so we don't require point addition? I really don't feel like implementing key exchange in Edwards space just so I can have the complete addition law… unless maybe I don't need the law to be complete?

Here's how it could work (unless you tear it apart):

  Alice and Bob share two passwords out of band: Pa and Pb
  Alice and Bob generate two key pairs ka/KA, and kb/KB
  Alice sends KA, Bob sends KB
  Alice and Bob compute ss = HASH(DH(kb, KA) = DH(ka, KB))
  Alice responds to KB with Ha = HMAC(Pb, KB || ss)
  Bob   responds to KA with Hb = HMAC(Pa, KA || ss)
  Alice verifies Hb
  Bob   verifies Ha
  The session key is HASH(ss) or something

The main disadvantage is that to achieve the security of a true PAKE, passwords here must be twice as long. A 4 digit Pin number here would only have the security of two digits (1/100). You'd need 8 digits to get to 1/10,000 security. On the other hand, it's extremely simple, doesn't require point addition, and if there's any flaw you probably already have spotted it.

Re: The PGP Problem

#194

Post by newscracker » Wed, Jul 17, 2019, 10:37 AM UTC

alxlaz wrote: post #175

riquito wrote: post #110

Earlier quoted context omitted.

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…

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

I completely disagree with the first part of your assertion. Email is still the main medium for all organizations, especially private companies taking your money for something, to communicate with you with plenty of details. Be it ordering some product online or booking a flight or other travel ticket or ordering a service or anything else.

The richness and amount of information conveyed over email pales in comparison to SMS notifications. So email is still a treasure trove of what people are doing and have done.

Re: The PGP Problem

#195

Post by teythoon » Wed, Jul 17, 2019, 10:42 AM UTC

We over at Sequoia-PGP, which gets a honorable mention by the OP, are not merely trying to create a new OpenPGP implementation, but to rethink the whole ecosystem.

For some of our thoughts on the recent certificate flooding problems, see https://sequoia-pgp.org/blog/2019/07/08/certificate-flooding...

Re: The PGP Problem

#196

Post by loup-vaillant » Wed, Jul 17, 2019, 10:43 AM UTC

frutiger wrote: post #68

lvh wrote: post #58

Earlier quoted context omitted.

Secure messaging is much more complex, but here’s a simple example of how that’s not true: TCP is bidirectional and email is one message, fire and forget. That immediately affects your ability to have forward and backward secrecy.

I do not think the OSI model is very useful but you seem to, so let me put it this way: E-mail is bidirectional too just at layer 4 instead of layer 3 (I hope I remembered my layers right!) E-mail is store-and-forward just like TCP is; how do you think an IP router works? TCP is fully duplex; a tx doesn’t wait behind an rx, exactly like an e-mail reply not waiting behind an e-mail receive. The only difference is that…

No, email is not bidirectional. You send an email, the recipient later opens it. Sure, the recipient's SMTP server might respond right away with an ephemeral key you can use to enjoy forward secrecy, but that server has to store the message for the recipient to retrieve later.

You can't have full forward secrecy with email as it is used today. If you want forward secrecy with email, you need three emails sent in rapid succession: Alice sends a request to Bob, Bob sends a response to accept the request, and Alice sends the actual encrypted email. That would work. But you basically need Bob to be online.

Re: The PGP Problem

#197

Post by dunkelheit » Wed, Jul 17, 2019, 10:47 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…

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

Re: The PGP Problem

#198

Post by newscracker » Wed, Jul 17, 2019, 10:47 AM UTC

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…

WhatsApp always requires your phone to be around, whereas Signal needs it only when you link it. After linking, the desktop client is independent of the phone (being online or in your vicinity or the number being in your possession).

Re: The PGP Problem

#199

Post by tinus_hn » Wed, Jul 17, 2019, 10:49 AM UTC

floatingatoll wrote: post #84

mstump wrote: post #79

I was an engineer at PGP from 2004-2011 and ended up running the server team as lead engineer. I wouldn't disagree with most of the points brought up by the author, both the code base and standard has accreted over time and it's incredibly complex. There were only a couple of people on the team that really understood all the facets of either the OpenPGP or SMIME/x509 standards. It's made worse in that it was a hack o…

Forcing iMessage to open will immediately result in MITM iMessage proxies that users can use to store iMessages that are meant to auto-delete, so that they can violate the wishes of the other party. These do not exist today because Apple binds iMessage to your hardware and bans your entire device when anyone is found to be operating such a service, either for themselves or others. Do you want open source clients that…

Just like with Snapchat, Auto-delete is a fantasy and is not worth sacrificing security or privacy for.

Re: The PGP Problem

#200

Post by bigiain » Wed, Jul 17, 2019, 10:55 AM UTC

darawk wrote: post #145

floatingatoll wrote: post #101

Earlier quoted context omitted.

Correct, screenshots are a viable attack against both closed and open source platforms. Preventing casual retention is the best you can hope for, and is a worthy goal regardless that it does not result in the perfection of a Faraday cage’d clean room

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 servers are a whole other thing. Large scale surveillance of all users of a specific server, "full take" collection and searchable databases of messages available effectively forever to unknown current and future opponents?

Different threats. Yeah, I'm happy enough to accept the risk of cameras in the hands of my correspondents. Way happier than I'd be with MITMable servers (or services that can add "ghost users" as the UK seems to be proposing).