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

31–40 of 369 posts

Re: The PGP Problem

#31

Post by eadmund »

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

Yeah-ish, but what I mean is an actual set of different tools (so, not one-size-fits-all) but all part of the same suite, rather than a bunch of different implementations of mostly the same idea — i.e., *BSD rather than Linux.

One of my numerous hobby projects is exactly that, but … I simply don't have enough Round Tuits.

Re: The PGP Problem

#32

Post by stubish »

The PGP problem isn't going away until there is a stable alternative. Under 'The Answer' there are several different, domain specific tools, with their different features and UIs and limitations. And the general case (encrypting files, or really that should be 'encrypting data'), "this really is a problem". If I want to replace my use of GnuPG on production with the things on that list, I need to write my own encrypt/decrypt wrappers using libsodium and hope that future travellers can locate the tool or documentation so they can decrypt the data. So I stick with the only standard, GnuPG, despite acknowledging its problems.

Re: The PGP Problem

#33

Post by viraptor »

lvh wrote: post #27
viraptor wrote: post #25

Another use case I don't know a replacement for is offline team+deployment secrets. Requirements: - you need team members to read/write the secrets - you need the deployment service to read the secrets Without using an online system managing the secrets via ACLs + auth, I don't know how to replace PGP here.

what's wrong with an online system managing the secrets? KMS is great, and makes it easy to separate decrypt from encrypt permissions. (KMS is not the only option! I'm just trying to eke out why you think that's valuable. For example, I think age, mentioned in the blog post, is a direct replacement?)

It has to be online. And reliable. And you can run into rate-limiting. And you have to be online. And services using it need extra network configuration to allow access. And if you can't narrow it down to a single ip/block you have a service with full network access just to reach out to a KMS.

Re: The PGP Problem

#34

Post by tptacek »

stubish wrote: post #32

The PGP problem isn't going away until there is a stable alternative. Under 'The Answer' there are several different, domain specific tools, with their different features and UIs and limitations. And the general case (encrypting files, or really that should be 'encrypting data'), "this really is a problem". If I want to replace my use of GnuPG on production with the things on that list, I need to write my own encrypt…

What specific problem are you trying to solve with PGP? If it's "encrypting files", why are you encrypting those files? What's the end goal? I acknowledge that there are cases that boil down to "encrypt a file", but believe they are a lot narrower than people assume they are.

Re: The PGP Problem

#35

Post by eadmund »

lvh wrote: post #17
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: magic-wormhole's 16 bits: I don't think you should be worried about that, because SPAKE2 will give you proof positive if the attacker attempts to guess. Are you saying 2*-16 success isn't good enough?

> 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, mostly (hence my 'cargo-culting' comment), but with a large enough N …

The nice thing about 1:2^128 is that you just don't have to care.

Re: The PGP Problem

#36

Post by lvh »

ekianjo wrote: post #30

So the recommendation here is just to use Chat clients to communicate and forget about Email? Well that is hardly a good solution.

Yes! E-mail is fundamentally terribly positioned to do secure messaging. You can use e-mail, or you can have cryptography that works and have people use it, but you can't do both.

Re: The PGP Problem

#37

Post by interfixus »

> If you’d like empirical data of your own to back this up, here’s an experiment you can run: find an immigration lawyer and talk them through the process of getting Signal working on their phone. You probably don’t suddenly smell burning toast

Well, currently extricating myself from the Signal mess, I really am expecting my smoke alarm to go off any minute.

On intallation a couple of years back, the Signal app desparately wanted to curate my sms traffic, but forgot to inform me it would be holding my message history hostage. Forgot to inform me it would kill my instance, should I ever have the audacity to try setting up on a second phone unit. Forgot to inform me that yes, there is a desktop client, but it is useless Electron crap. Forgot to inform me it would be livestreaming my usage to everyone on my contact list - when I installed, when I reinstalled or changed devices, or when I mistook an ambigous list-feature for a personal book-keeping thing. The last item didn't happen to me, but to an acquaintance who thus had a somewhat embarrassing list of contact spilled out into the open. Not to mention the whole phone number based ID disaster, and the lack of any web interface. Sorry, but I'm out.

Fully aware of serious concerns about the crypto and the privacy, but for UI, consistently well designed client apps, data export, and lack of nasty surprises, I have seen nothing to rival Telegram. Which may help explain why that seems to be where everyone is heading.

Re: The PGP Problem

#38

Post by Sniffnoy »

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 down and type it from my computer. Text-messaging is always short, although possibly it's a series of short messages. A series of short emails, by contrast, is an annoyance; it's something you try to avoid sending (even though you inevitably do when it turns out you got something wrong). Similarly, you don't typically hold rapid-fire conversations over email.

2. On that point, email says, you don't need to read this immediately. I expect a text message will be probably be read in a few minutes, and probably replied to later that day (if there's no particular urgency). I expect an email will be probably read in a few hours, and probably replied to in a few days (if there's no particular urgency).

3. It's OK to cold-email people. To text someone you need their phone number; it's for people you know. By contrast, email addresses are things that people frequently make public specifically so that strangers can contact them.

So what am I supposed to do for secure messaging that replicates that? The best answer I've gotten for this so far -- other than PGP which is apparently bad -- is "install Signal on your computer in addition to your phone and just use it as if it's email". That's... not really a satisfactory answer. Like, I expect a multi-page Signal message talking about everything I've been up to for the past month to annoy its recipient, who is likely reading it on their phone, not their computer. And I can't send someone a Signal message about a paper they wrote that I have some comments on, not unless they're going to put their fricking phone number on their website.

So what do I do here? The secure email replacement just doesn't seem to be here yet.

Re: The PGP Problem

#39

Post by lvh »

eadmund wrote: post #31
lvh wrote: post #18

Earlier quoted context omitted.

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

Yeah-ish, but what I mean is an actual set of different tools (so, not one-size-fits-all) but all part of the same suite, rather than a bunch of different implementations of mostly the same idea — i.e., *BSD rather than Linux. One of my numerous hobby projects is exactly that, but … I simply don't have enough Round Tuits.

OK, so you're saying something like:

  magic send 
  magic receive 
  magic encrypt 
  magic sign
... that ideally all have NaCl at the base but are otherwise one binary that you have to remember?

The tricky one there is probably chat.

Re: The PGP Problem

#40

Post by roamingnomadic »

lvh wrote: post #26
roamingnomadic wrote: post #24

Is this blog post satire? or an ad of sorts for some vaporware? The talking alts either use PGP or a botnet. (signal uses PGP with a CA type of thing, so much for "stop using pgp") and whatsapp is owned by facebook. tarsnap as I understand requires that I lock in to a service to secure my backups. F- that. Someone already talked about wormhole. And how is essentially forking pgp with 'age' really going to solve thing…

> (signal uses PGP with a CA type of thing, so much for "stop using pgp") I legitimately have no idea what this means. > And how is essentially forking pgp with 'age' really going to solve things? Wow thanks another forked app! :^) A big part of the criticism we've gotten when we tell people "PGP bad" is that we're not providing alternatives. age is one of those alternatives, for one of those use cases. > It would be…

Signal uses the same public key/private key cryptography. Hopefully that makes more sense?

In any case, after reading the google doc more carefully, I see the idea isn't to be against the whole pub/private key authentication its just a proposal of how pgp works.

>age is not unauthenticated encryption, so the criticism does not apply.

yeah, I see. its pretty good actually.

Post reply on HN