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

211–220 of 369 posts

Re: The PGP Problem

#211

Post by Perceptes »

cyphar wrote: post #22
tptacek wrote: post #16

Earlier quoted context omitted.

Use Matrix if you want to contribute to Matrix or are an enthusiast about what Matrix is trying to do. But don't use it as a secure messenger, or tell at-risk people to use it. It may someday be a serious option for secure messaging, but it is not that today. I'm not a Matrix hater, but I think Matrix's cheering section gets the project in trouble, since their answers about privacy and security are demonstrably worse…

Is there a specific issue other than "it's not the default" that precludes it from secure messaging? This is the thing I don't understand about your position -- you have been saying for a very long time that "it's not ready yet" but as far as I can see the default-to-unencrypted setup is the main issue you have with it? I get that asking a journalist to use it right now is a bad idea, but if E2EE was the default toda…

I'd also be interested to hear Thomas clarify this. I saw a recent thread on Twitter where he and bascule were talking about it and it still wasn't super clear, but one specific point I recall is that Matrix has a significant amount of metadata stored on the server side which constructs a social graph. As opposed to something like Signal which has close to nothing stored on the server.

To me this seems like an issue of use case. If my goal is to be able to talk to my family and friends, and I don't care that it's known that I'm talking to them as long as the contents of the messages are private, that is fine for me. For a case with more stringent requirements, I can see Matrix not being a good recommendation in its current design.

Re: The PGP Problem

#212

Post by dunkelheit »

aljungberg wrote: post #206
dunkelheit wrote: post #197

Earlier quoted context omitted.

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

Right, that's insecure. Maybe they should, you know, put a PGP key on their website? :)

Re: The PGP Problem

#213

Post by frutiger »

loup-vaillant wrote: post #196
frutiger wrote: post #68

Earlier quoted context omitted.

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

> you need three emails sent in rapid succession

This is partially correct, but they do not need to be in rapid succession, and therefore Bob does not need to be online.

Re: The PGP Problem

#217

Post by louis-paul »

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

Keybase builds a lot on top of saltpack, which works like a saner PGP: https://saltpack.org

The underlying cryptography is NaCl, which is referenced in the original post.

Re: The PGP Problem

#218

Post by rakoo »

lvh wrote: post #39
eadmund wrote: post #31

Earlier quoted context omitted.

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.

I think they meant something like the OpenSSL binary that obviously builds on the library and provides everything through the command line.

The problem is that the same thing for NaCl/libsodium would be lower level, and probably still not enough as exhibited in the article: a typical use case is not "I want to encrypt this file", it's "I want to send this file to that person such that no one else can read it" or "I want to send a message to that person such that no one else can read it, and if they can they shouldn't be able to read other messages from the same conversation". No cli tool can properly solve this, it has to be incorporated in the application or even protocol.

Re: The PGP Problem

#219

Post by tptacek »

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.

We manage bug bounties for a bunch of different startups, and I can count on zero fingers the number of times I've had to use PGP in the past year for that. In practice, people just send bugs with plain 'ol email.

Re: The PGP Problem

#220

Post by cpach »

louis-paul wrote: post #217
bennofs wrote: post #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…

Keybase builds a lot on top of saltpack, which works like a saner PGP: https://saltpack.org The underlying cryptography is NaCl, which is referenced in the original post.

I don’t get it. How does Saltpack solve the issue of identity management?
Post reply on HN