Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making PGP Key Management Invisible So Johnny Can Encrypt

blog.whiteout.io

Post reply on HN
Print view View original

51–60 of 78 posts

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#51

Post by stinkytaco »

malgorithms wrote: post #49
stinkytaco wrote: post #45

Earlier quoted context omitted.

This is fascinating concept, especially since I've always felt that my PGP key was sitting out there mostly useless since no one I know personally signs their emails or even knows someone who signs emails. However, wouldn't the weak part here be if my twitter (or other public) account was compromised somehow? Or if someone just impersonated me and sent a "unique tweet" pretending to be me? How does HN feel about that…

This is a good question: generally if all you know about someone is their twitter name, and that's it, then a compromise of their twitter account could lead to a compromise of their key announcement. Even this case is mitigated because of the timestamping: a compromise would have to be a public compromise on an ongoing basis, and everyone in the world would have to see the same compromise, including the alleged twitt…

So it becomes its own "web of trust" in a sense? Every time there is activity, it's another point for "yeah, this person is who they say they are, look at all the stuff they've verified"? That's an interesting concept, at least for casual communication (the kind I might want to keep out of the ears of Google or Twitter, probably not the kind I'd want to keep out of the ears of the government). Is there any plan to incorporate traditional keyservers into the "web" as a component in the trust model?

Additionally, doesn't the user signing the statement with his or her private key mean that you need to have his private key to really believe it? I notice on the website it states that encryption/decryption is done with client encrypted keys. If it's client encrypted presumably the signing is happening at the client and an announcement is sent to keybase stating as such. How can you trust the data your getting back from the client is trustworthy or not also compromised?

Forgive me if I'm being boneheaded here, I'm just trying to grasp this so I can say, "Yes, that makes enough sense."

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#52

Post by Thespian »

Full disclosure - this is my employer and a product I work on.

For enterprises, and folks outside the enterprise communicating with them, commercial products exist which effectively allow any sender to use any email address as-if it were a public key, even if the recipient hasn't set up any sort of encryption yet.

While compatible with PGP, this is not PGP encryption, but I figured this may be of interest to readers in this thread.

White papers can be found at the bottom of this product info page:

http://www.voltage.com/products/securemail/

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#53

Post by MichaelGG »

murbard2 wrote: post #20
jlrubin wrote: post #3

I think the 99% of the time it's not an issue argument is invalid. Encryption isn't really necessary for 99% of people at any given time anyways . It's just that you don't know when you're in the 99 and when you're in the 1 percent, and a mistake in that 1 percent of the time is crucial, that's why we try to do it 100% of the time.

As with everything in crypto: it depends on your threat model. If you are sending very sensitive secret messages, it is indeed crucial that you take the precaution to verify the keys very thoroughly. If however, you merely want to avoid being caught in the NSA dragnet, trust on first contact does the trick.

If you want to avoid being in a dragnet, just requiring TLS using policies on your SMTP server is enough. That's what many organizations do already.

If you just want "encryption" as a checkbox, then just use Gmail with everyone and your data isn't going anywhere outside Google anyways.

I'm wondering who the users are that have threat models that make them concerned about attackers able to compromise, say, Google, but not capable enough of getting fake keys out.

This article in particular says fake keys aren't important because the attacker needs access to the mailbox. Well if they don't have access, you don't need encryption in the first place!

Sure, there's a marginal improvement (ignoring all the downsides of encryption, like forgetting your passphrase means losing all data) but it doesn't seem to be useful for actual targeted users.

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#54

Post by MichaelGG »

rakoo wrote: post #37
Kalium wrote: post #9

So... the answer is to decrease security by just dismissing whole attack classes?

The real goal here is not to provide state-level security; it is to increase the cost of massive surveillance by deploying the easy parts of PGP everywhere. The people who are highly dependent on security will run through the whole procedure anyway, they won't just rely on whiteout. "Johnny", on the other end of the spectrum, will see the privacy of his communication greatly improved againts passive attacks. Much lik…

Then just require TLS on SMTP. Bam, no more dragnet, zero inconvenience to users. And, no problems with spam filtering or data recovery either.

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#55

Post by schoen »

dublinben wrote: post #48
schoen wrote: post #42

Earlier quoted context omitted.

I'm sorry my homepage is out of date; thanks for the reminder. It seems like it's been a decade or so since I updated it. I normally check signatures when downloading a new key, particularly as a way of distinguishing between multiple keys available on a keyserver. But I don't have a way to force other people who are writing to me to do that, and apparently at least the Enigmail users often don't. Edit: Erinn is a mo…

Including your key signature everywhere you post your email address (homepage, business card, email signature, etc.) is a good practice. It's not perfect, but it's better than teaching users to go straight to a keyserver.

I do have my key and/or fingerprint on my

* personal e-mail .signature

* personal home page

* work employee page

* business card

I don't have my key or fingerprint on my

* work e-mail .signature

Despite this, 12 people accepted the fake key as genuine.

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#56

Post by tokenizerrr »

williamcotton wrote: post #50
malgorithms wrote: post #27

Earlier quoted context omitted.

Two things we're particularly proud of at Keybase are (1) that there's no server trust of these proofs, and (2) we pin the entire state of the directory to the bitcoin blockchain, to prevent forking. [1] In other words, if you ask for Twitter user X's public key, your client can check that proof on twitter itself (rather than trusting that a key server did it for you, like it would with email proofs), and it can trus…

Can you give us the txId of a bitcoin transaction used to represent the entire state?

https://keybase.io/docs/server_security/merkle_root_in_bitco...

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#57

Post by dredmorbius »

TheLoneWolfling wrote: post #46
dredmorbius wrote: post #41

Earlier quoted context omitted.

I'd be really, really cautious about throwing "No True Scotsman" at Seth David Schoen and Erinn Clark. https://en.wikipedia.org/wiki/Seth_Schoen His hopelessly out-of-date homepage: http://www.loyalty.org/~schoen/ That said, yes, PGP has a notable failing in that there's no reliable method for repudiating a key, particularly one generated by a hostile party. If you've hung on to your key revocation certificate you ca…

No, I mean that my argument there was perilously close to said fallacy.

Hrm. Not sure I see that, but that's more acceptable ;-)

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#58

Post by pdkl95 »

Kalium wrote: post #9

So... the answer is to decrease security by just dismissing whole attack classes?

Yes, that is probably the most important part of making a crypto solution actually work in practice. You can't solve all of the problems at once. Trying to solve everything has been shown to have a predictable outcome: nobody uses it and we're stuck in plaintext.

By deploying a partial solution that doesn't attempt to fix all of the problems, we can at least defend against some attacks. More importantly, a partial solution is educational. It introduces the idea of managing keys and wrapping your communications in crypto, which is a new concept to a lot of people. You might consider it "training wheels" for crypto.

Later on - when more people are used to these ideas - it will be a lot easier to upgrade to other methods that defend against the rest of the attack classes. Also, there is a bonus benefit: it is probably a lot easier to deploy a proper PGP/GPG web of trust when you have an existing infrastructure of keys that could be used as another layer of verification.

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#59

Post by mey »

malgorithms wrote: post #27
mey wrote: post #12

https://keybase.io/ with it's social media identity proofs have been interesting way to allow finding contacts in my social network's pgp keys. Edit: I also have invites available if you are interested in checking it out. Contact me via my HN profile

Two things we're particularly proud of at Keybase are (1) that there's no server trust of these proofs, and (2) we pin the entire state of the directory to the bitcoin blockchain, to prevent forking. [1] In other words, if you ask for Twitter user X's public key, your client can check that proof on twitter itself (rather than trusting that a key server did it for you, like it would with email proofs), and it can trus…

He wasn't kidding about a bunch, I've only burned through about a tenth of them. :) Still have more available.

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#60

Post by fubarred »

dredmorbius wrote: post #41
TheLoneWolfling wrote: post #34

Earlier quoted context omitted.

This sounds like an implementation as opposed to design flaw. Enigmail should be throwing up red flags all over the place when duplicates exist. That being said, this is perilously close to the "No True Scotsman" fallacy.

I'd be really, really cautious about throwing "No True Scotsman" at Seth David Schoen and Erinn Clark. https://en.wikipedia.org/wiki/Seth_Schoen His hopelessly out-of-date homepage: http://www.loyalty.org/~schoen/ That said, yes, PGP has a notable failing in that there's no reliable method for repudiating a key, particularly one generated by a hostile party. If you've hung on to your key revocation certificate you ca…

PGP is fine. People aren't using it correctly.

The point of Web of Trust is to only trust keys that other people you know have also signed. Everything else is garbage until proven otherwise.

Key servers are untrustworthy because anyone can upload random shit to them.

Trying to shift WoT to a third party is trying to get something for free that doesn't emphasize solving the problem: getting everyone you know signing keys of only other people they know.

https://www.kernel.org/signature.html#kernel-org-web-of-trus...

Post reply on HN