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

21–30 of 78 posts

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#21

Post by Kalium »

sixpenrose16 wrote: post #16
Kalium wrote: post #9

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

I think the idea is to create an abstraction layer and make it easy for the whole pgp on "end-user". Btw, very interesting idea on solving the greater problem around UX and PGP.

They're looking at key security features that mitigate attacks and saying "That's a corner case, ignore it".

From a UX perspective, that's great. It lets you simplify and remove a lot of complexity. The catch is that every attack scenario is a corner case. As a result, users get exposed to many of the same vulnerabilities that the technology is supposed to be enabling them to guard against.

There's nothing novel - or, I submit, interesting - about the idea of trading off security to make things slicker for the user.

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#22

Post by kevinr »

The key discovery part seems unobjectionable, and vastly cleaner than what keybase.io does.

Looking at their design for key sync[0], though, maybe I'm just dense, but I swear I read the article, and I still can't tell -- what's the advantage of this complicated thing with a symmetric key over just protecting the private key with a strong passphrase and sticking it in Dropbox?

[0]: https://blog.whiteout.io/2014/07/07/secure-pgp-key-sync-a-pr...

(Okay, maybe the advantage is that you don't have to rely on the user to choose a strong passphrase.)

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#23

Post by mdaniel »

bokonist wrote: post #6

Two things that would make this have more hope of becoming a standard: 1) open source the key server with the REST-API 2) allow domain owners to define their own key server via a DNS TXT entry

1. What's wrong with the existing key server protocol?

2. Why TXT and not SRV?

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#24

Post by kevinr »

x1798DE wrote: post #5

In my experience, key distribution is the easiest thing about PGP / GPG. EnigMail and most other clients can already query key servers easily. Enigmail routinely asks me to "download missing keys", and if my recipient's key is on a keyserver, it downloads them. In fact, the PGP global directory ( https://keyserver.pgp.com/vkd/GetWelcomeScreen.event ) already seems to have all the features that are missing from the wh…

They are using the existing key distribution infrastructure -- the whole point is that they'll go fetch keys for you from a selection of HKP servers if they don't have one on theirs with a verified e-mail address.

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#25

Post by schoen »

michaelt wrote: post #13
x1798DE wrote: post #5

In my experience, key distribution is the easiest thing about PGP / GPG. EnigMail and most other clients can already query key servers easily. Enigmail routinely asks me to "download missing keys", and if my recipient's key is on a keyserver, it downloads them. In fact, the PGP global directory ( https://keyserver.pgp.com/vkd/GetWelcomeScreen.event ) already seems to have all the features that are missing from the wh…

key distribution is the easiest thing about PGP The problem is if you look at the key server and find there are two keys - one legitimate, one posted by an adversary (who has read access to the recipient's e-mail) - both have a few signatures, but the signatories are several degrees away from you in the web of trust.

Someone made a fake key for each of the participants in a particular keysigning party in October 2013 (including me) and uploaded the fake keys to keyservers. Because the creation date of the fake key for me is newer than the creation date of my real key, apparently Enigmail is suggesting it to people and they're choosing to use it, despite the lack of signatures.

More than a dozen different people have now sent me encrypted mail that I couldn't read because they selected the fake key on the keyservers instead of my real key.

That makes me think that the web of trust model isn't working out very well under active attack -- at least, over a dozen people failed to actually use the web of trust to avoid falling victim to this attack.

There are also seven keys for Erinn Clark (who signs Tor Browser Bundle releases for the Tor Project) on the keyservers; if I remember correctly, three are real and four are fake.

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#26

Post by spiralpolitik »

dublinben wrote: post #19
spiralpolitik wrote: post #15

It also needs to be baked into contact management apps so that exchanging your credentials becomes no different than sending your contact card via Bluetooth, NFC etc. I suspect that this would require something a bit more robust than vCard to package everything up in a nice bundle.

vCard already supports this with a field specifically for public keys. It can have either a link to the key, or the key itself. https://en.wikipedia.org/wiki/VCard#Properties

vCard (to my knowledge) doesn't have anyway of validating the integrity of the card data so can be altered without knowledge. You would at least need to add some kind of wrapper so that you could add a signed checksum.

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#27

Post by malgorithms »

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 trust a hacked/coerced server isn't hiding something specifically from you, such as a revocation. The latter is particularly hard to protect against. It also gets timestamping: you know the world has been seeing the same public key for Twitter user X for many months or years.

[1] https://keybase.io/docs/server_security/merkle_root_in_bitco...

[update] I gave mey a bunch more invitations, but I can be hit up on twitter (https://keybase.io/chris) for HN users wishing to jump our invitation queue, which is large.

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#28

Post by dublinben »

spiralpolitik wrote: post #26
dublinben wrote: post #19

Earlier quoted context omitted.

vCard already supports this with a field specifically for public keys. It can have either a link to the key, or the key itself. https://en.wikipedia.org/wiki/VCard#Properties

vCard (to my knowledge) doesn't have anyway of validating the integrity of the card data so can be altered without knowledge. You would at least need to add some kind of wrapper so that you could add a signed checksum.

In order to verify the signature, you'd have to get their public key. Since that's where this all started, we're just in a loop of untrustworthy ways to get someone's public key.

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#30

Post by volker48 »

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

This is the first thing I thought of as well as I've been using keybase myself for a little while now and am very happy.
Post reply on HN