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

61–70 of 78 posts

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#61

Post by darklajid »

drzaiusapelord wrote: post #2

Or just use S/MIME which is baked into most email clients? Of course, handing out keys is an issue, but in the world of social media why not just attach one's key to one's public profile? Facebook, linkedin, etc. Not sure why S/MIME doesn't get any love. It works, its the most common email encryption scheme, and typically you don't need a third party application or command-line-fu to get it to work. I've seen the dim…

A couple of the dimmest of office workers decided to use S/MIME - just because.

We're using Office 365. I prefer OWA to any fat client. OWA cannot (with various failure modes, but let's just stick with "cannot") show S/MIME mails.

A coworker sends mails that I cannot read in a web interface to the same mail store that he accessed to submit that amazing piece of art in the first place.

S/MIME has no good reputation here..

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#62

Post by im2w1l »

Kalium wrote: post #39
rakoo wrote: post #37

Earlier quoted context omitted.

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…

When the attitude is to dismiss every "corner case" that arises, suddenly you find yourself not doing any security work. After all, every attack is a corner case. 99% of users will never be attacked. Why spend all this energy on things most users will never need?

99% of users will be dragnetted though. And more than 10% (pulling this out my ass) will use insecure wifi.

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#63

Post by IgorPartola »

diafygi wrote: post #43
malgorithms wrote: post #35

Earlier quoted context omitted.

Cool site! Max Krohn ( https://keybase.io/max ) and I are meeting with some people working on various PGP projects in Germany in April, and one of the things on our personal agenda is the ideal future of key distribution. We don't really want to be a sole place to look up these keybase-style social media proofs. We also don't think they belong inside the keys themselves. One complication: looking up a key by email an…

Makes sense. If possible, I'd like to request at least gossiping with servers in the SKS pool. Right now, when someone signs my key and sends it to the pool via gpg --send-key, it doesn't get updated in keybase :( Second, for public keys that are signed by other fingerprints in keybase, it would be nice to have those listed in my trackers list. Finally, for people who upload a public key to keybase, it would be great…

I second all these requests. Exactly what I was thinking when I finally got my invite.

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#64

Post by diafygi »

Thespian wrote: post #52

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…

With curve25519 public key sizes as small as 40-ish characters, you can do this for gmail/outlook aliases, too. Here's a demo I made a while back:

https://diafygi.github.io/emailpk

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#65

Post by e12e »

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.

Agree with both you and GP. According to this blog post, they're not solving the trust issue, they're just working around the issue of a webmail app not being able to query keyservers:

  > We couldn’t make cross origin requests to HKP
  > servers from the web version of our app.
It's not entirely clear if the REST proxy for hkp they've created is open source -- if not it's almost useless as far as I can see. If I were to trust my secret key to the browser/a browser "app", I'd have to download the app from a web-server I trust and control (ie: my own server). And I'd certainly not want to load anything from any other server. I might trust a sanitizing REST proxy under my control to go and get gpg-keys.

Either way, while Trust-on-first-use is certainly pragmatic -- if that's all you're going to do, then there's nothing wrong with most email clients that have gpg-support -- most will do that gladly! One might argue that in addition to downloading keys, they should be signed as "marginally trusted" on first use (or maybe there should be another trust-level in gpg/pgp: "TOFU" -- to avoid anyone else mistakenly trusting the key).

I think semi-structured "CAs" for gpg would be a much better solution: allow banks/post offices/DMV to sign and upload a gpg-key -- demanding that such keys had an attached photo, and that the institution verified the ID/name at the time of signing (with the same level of trust that is usually demanded by institution that make valid IDs: a valid passport etc).

If I could go to the bank, and get a copy of their key, and sign that (and have them sign mine) -- and so have a good pathway to "everyone's" key -- that'd be great. And unlike with browser CAs - I could chose who to trust to delegate IDs. As I've mentioned elsewhere I think cacert.org should also sign GPG-keys (just as a convenience -- you could of course sign your gpg-key with your CA-cert -- but that would require manual intervention to verify the chain of trust, unlike a signature by a trusted gpg-key).

As for the "Snowden" use-case -- TOFU is fine. Someone sends you signed and encrypted data, you can assume you're talking to whoever has the key. Maybe you can't be sure it's not the FBI/CIA/NSA/GCHQ setting you up -- but does it really matter? You've already started a dialogue, and that's probably enough to put you away for life...

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#66

Post by tanx »

malgorithms wrote: post #35
diafygi wrote: post #33

Earlier quoted context omitted.

Question. Do you plan on gossiping with or mirroring the SKS pools? I would love to be able to just search keybase for a public key rather than both: https://diafygi.github.io/publickeyjs/

Cool site! Max Krohn ( https://keybase.io/max ) and I are meeting with some people working on various PGP projects in Germany in April, and one of the things on our personal agenda is the ideal future of key distribution. We don't really want to be a sole place to look up these keybase-style social media proofs. We also don't think they belong inside the keys themselves. One complication: looking up a key by email an…

Hey Tankred from Whiteout here,

Felix and me will be at the event in April as well. So we can chat there.

We think keybase's concept is great and also look forward to what the E-2-E developers are coming up with for certificate transparency. Our only concern is, that these concepts are not open and backwards compatible to current key server solutions. This would create an island... and we've been sitting on our own small island up until now with our closed key server solution.

Sure if Google and Yahoo launch their concept it might exceed any marketshare that HKP might have had. But unless there is an open standard where small guys like us can latch onto, it's going to be hard to get vendors on board.

- Tankred

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#67

Post by aw3c2 »

MichaelGG wrote: post #53
murbard2 wrote: post #20

Earlier quoted context omitted.

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…

You are not seriously suggesting that Gmail is perfectly private, are you? You must have missed how the NSA was tapping between Google's servers. http://www.washingtonpost.com/world/national-security/nsa-in...

End to end encryption is safe, mail server to mail server leaves your mail unencrypted on an unknown number of servers. If those are in the US or a similarly crazy country, they are just one letter away from being read.

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#68

Post by rakoo »

MichaelGG wrote: post #54
rakoo wrote: post #37

Earlier quoted context omitted.

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.

PGP is end-to-end, TLS is not. PGP does improve privacy by reducing the number of people able to understand the content.

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#69

Post by tanx »

kevinr wrote: post #22

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

We're currently in the process of simplifying the key sync spec. The new version will store your private key encrypted with a strong random passphrase in IMAP. So it's similar to your dropbox proposal, but with a UX that leads users along the way.

Re: Making PGP Key Management Invisible So Johnny Can Encrypt

#70

Post by tanx »

diafygi wrote: post #31

Does keys.whiteout.io gossip with other HKP keyservers? If so, is there any documentation on the gossip protocol? I can't seem to find any, and the SKS keyserver is the only implementation of the gossip protocol that I can find.

Yes. It gossips with the following list of servers. Keys are uploaded and also fetched form these servers:

'https://pgp.mit.edu', 'http://pool.sks-keyservers.net', 'http://keys.gnupg.net', 'http://keyserver.ubuntu.com', 'http://pks.gpg.cz'

Post reply on HN