6 ms·

Making PGP Key Management Invisible So Johnny Can Encrypt

130 points by tanx 12y ago

drzaiusapelord 12y ago
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 dimmest of office workers deal with it everyday.
- dublinben 12y ago
  >why not just attach one's key to one's public profile? This is equally valid for PGP keys, and a common practice among the security conscious.
- darklajid 12y ago
  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..
jlrubin 12y ago
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.
- kevinr 12y ago
  Well, and there's the availability concern -- if it's a critical or time-sensitive message, sending it to the right address with the wrong encryption key is the same as the message getting dropped in transit, which is hazardous. Heck, even with a verified key, I've seen it at least once where a critical e-mail came in to a shared key but nobody was around who could decrypt it. When PGP is used only in special circumstances, the e-mail verification almost needs to be refreshed periodically to make sure the owner continues to have control of the account and the key.
- murbard2 12y ago
  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.
  - MichaelGG 12y ago
    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.
    - aw3c2 12y ago
      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-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html 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.
      - MichaelGG 12y ago
        No, I'm suggesting that the tradeoffs if PGP are unacceptable for most users, and that using TLS between mail servers (even on private fiber) would be a good way to stop full on collection. The NSA story is a nice addition, but tales of the FBI carnivore system reading all email by connecting at big interexchanges is decades old, yet no one is taking even that part seriously.
mfrager 12y ago
This is no longer necessary with MiniLock. See http://minilock.io/ http://minilock.io/ and this article: http://www.wired.com/2014/07/minilock-simple-encryption/ http://www.wired.com/2014/07/minilock-simple-encryption/
- dchest 12y ago
  miniLock doesn't solve public key distribution problem.
x1798DE 12y ago
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 https://keyserver.pgp.com/vkd/GetWelcomeScreen.event) already seems to have all the features that are missing from the whiteout server (SSL, scalability, e-mail validation, etc). The biggest adoption problem around key management that I see is getting people to generate them securely, then integrating the keys across multiple devices and multiple clients. Maybe this whiteout mail app thing is supposed to be the part of this that makes key management "invisible", but I don't see why they can't use the existing key distribution infrastructure.
- michaelt 12y ago
  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.
  - schoen 12y ago
    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.
bokonist 12y ago
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
- mdaniel 12y ago
  1. What's wrong with the existing key server protocol? 2. Why TXT and not SRV?
  - bokonist 12y ago
    1. From reading their post, it seems like they made their own REST API for the key server. So it would be nice if they open sourced the service behind it, to alleviate fears of lock in. 2. You're right, it probably should be SRV.
  - rakoo 12y ago
    TXT is much more available in DNS management interfaces than SRV, so there's a higher chance that you can install such a server on those shared hosting instances.
jrochkind1 12y ago
I think this makes a lot of sense, but: > Even with automatic key lookup, users can later always navigate to the contacts menu and verify a recipient’s key fingerprint if they need to. Okay, how about making this (optional step) way easier too. Show the fingerprint somewhere on-screen everytime you send a message. (Maybe flagged for extra notice the first time the key is imported?) Maybe with a little (i) icon next to the fingerprint, clicking on it explains what it is, and how for top confidence the fingerprint should be checked with the owner directly. A good UI makes it easy for the unsophisticated, but provides cues to give the user an easy and gradual path to being more sophisticated too (and makes being more sophisticated as easy as possible too).
- falcolas 12y ago
  Rendering the fingerprint as an image (a'la github's default portraits) would help; we can more easily see differences in images than we can strings of numbers.
Kalium 12y ago
So... the answer is to decrease security by just dismissing whole attack classes?
- sixpenrose16 12y ago
  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.
  - Kalium 12y ago
    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.
- rakoo 12y ago
  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 like HTTPS Everywhere, it is not enough to guarantee that your messages will be secure against a sufficiently-funded and determined attacker. It puts some power back to the people to enjoy better privacy of communication.
  - Kalium 12y ago
    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?
higherpurpose 12y ago
I like Google's End-to-End design better. It seems to add a few extra security checks.
mey 12y ago
https://keybase.io/ 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
- pasbesoin 12y ago
  Tim Bray's been interested in it, which is where I first heard about it. https://www.google.com/#q=site:tbray.org+keybase https://www.google.com/#q=site:tbray.org+keybase
- malgorithms 12y ago
  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_bitcoin_blockchain 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 https://keybase.io/chris) for HN users wishing to jump our invitation queue, which is large.
  - diafygi 12y ago
    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/ https://diafygi.github.io/publickeyjs/
    - malgorithms 12y ago
      Cool site! Max Krohn (https://keybase.io/max 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 and trusting 3rd party verifications is philosophically pretty different from what Keybase is doing. So we have to figure out how to resolve this. For example, we don't even have an email based lookup at all (!), because we have no way of letting a client verify it's true. I don't know if we can be convinced to change this. We're looking forward to Yahoo's and GMail's work on their E2E projects because it may help verifying email addresses publicly. And to be clear: we're not in the email business, so we want Keybase-style key proofs to be useful to mail clients like Whiteout. We'd like to work well with everyone.
spiralpolitik 12y ago
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.
- dublinben 12y ago
  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 https://en.wikipedia.org/wiki/VCard#Properties
  - spiralpolitik 12y ago
    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.
    - dublinben 12y ago
      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.
kevinr 12y ago
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-proposal/ 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.)
- tanx 12y ago
  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.
  - kevinr 12y ago
    Nice!
kybernetikos 12y ago
I encode a public key and bitcoin address into my gravatar image.
diafygi 12y ago
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.
- tanx 12y ago
  Yes. It gossips with the following list of servers. Keys are uploaded and also fetched form these servers: 'https://pgp.mit.edu' https://pgp.mit.edu', 'http://pool.sks-keyservers.net' http://pool.sks-keyservers.net', 'http://keys.gnupg.net' http://keys.gnupg.net', 'http://keyserver.ubuntu.com' http://keyserver.ubuntu.com', 'http://pks.gpg.cz' http://pks.gpg.cz'
  - diafygi 12y ago
    Great to hear! Thanks! Do you know if you are using the SKS keyserver gossip implementation or did you roll your own?
krzyzanowskim 12y ago
Nice writeup. I fully agree on that approach. Some time ago I implemented "invisible" keys for http://privacyapp.io http://privacyapp.io on iOS, with support for HKP and keybase.io API. It works quite well. The only problem is that keyservers from SKS pool have different versions of software and response can be randomly broken for the very same request.
dredmorbius 12y ago
Interesting, but misplaced effort. The biggest problem in widespread adoption of PGP/GPG is client support. Case in point. I've been looking into sizes of various online communities, and decided to look for any hard statistics on the actual traffic levels of Usenet back in the day. So I looked up the old admins. One of those is Eugene "Spaff" Spafford. Also known as something of a security expert -- he wrote the book on it: Practical Unix and Internet Security (PUIS). I've a copy on my shelf. He's at Purdue these days, and his homepage there (http://spaf.cerias.purdue.edu/ http://spaf.cerias.purdue.edu/) lists a PGP key (http://spaf.cerias.purdue.edu/pers/pgp.html http://spaf.cerias.purdue.edu/pers/pgp.html). So I grabbed that, and ran a fetch of the signatures for the key. If you want, you can speed that with a bit of shell magick: gpg --list-sigs 'A40F862E' | grep ^sig | cut -c'13-21' | sort -u | xargs --max-args 10 gpg --recv-keys There's a limit to how many keys keyservers will return, but 10-20 seems a generally safe bet. Wrote my brief email using mutt (which was designed as a reference case for MIME-encoded PGP email), and awaited a response. I no longer use PGP. Please send me readable text. Yes, from Spaff. So I sent him the unencrypted text, he found my Usenet questions interesting. But I was curious about his lack of use of encryption. He responded (and gave me permission to quote him): I don’t have a convenient PGP implementation for my Mac. I used to use the commercial version, but it requires Java and that’s a huge risk. GPG implementations require lots of software I don’t entirely trust, plus there is no nice interface to my email. So yeah. The guy who wrote the book on Unix and Internet security, stymied by lack of a decent client. Until mainstream vendors are integrating this, we're going to be stuck. There are other issues. If I've got multiple devices, I may well wish to use different keys on them. Which means I've got a key-management issue of having people use the right key(s) on messages. There's the problem of key loss (you lose access to everything encrypted with it). There's the challenge of inputting long passphrases on Mobile devices (I'd far prefer a OTP / keyfob type solution or other form of semi-physical security, plus a shorter passphrase). There's device-based backdoors and other exploits. Etc., etc. I've used PGP/GPG for nearly two decades. It remains something of a pain to deal with....
Thespian 12y ago
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/ http://www.voltage.com/products/securemail/
- diafygi 12y ago
  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 https://diafygi.github.io/emailpk
tanx 12y ago
I updated the post with more detailed threat modeling and SSH as a TOFU case study for UX. Thx for the feedback everyone!

130 points by tanx 12y ago

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 dimmest of office workers deal with it everyday.

dublinben 12y ago
>why not just attach one's key to one's public profile? This is equally valid for PGP keys, and a common practice among the security conscious.
darklajid 12y ago
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..

jlrubin 12y ago

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.

kevinr 12y ago
Well, and there's the availability concern -- if it's a critical or time-sensitive message, sending it to the right address with the wrong encryption key is the same as the message getting dropped in transit, which is hazardous. Heck, even with a verified key, I've seen it at least once where a critical e-mail came in to a shared key but nobody was around who could decrypt it. When PGP is used only in special circumstances, the e-mail verification almost needs to be refreshed periodically to make sure the owner continues to have control of the account and the key.
murbard2 12y ago
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.
- MichaelGG 12y ago
  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.
  - aw3c2 12y ago
    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-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html 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.
    - MichaelGG 12y ago
      No, I'm suggesting that the tradeoffs if PGP are unacceptable for most users, and that using TLS between mail servers (even on private fiber) would be a good way to stop full on collection. The NSA story is a nice addition, but tales of the FBI carnivore system reading all email by connecting at big interexchanges is decades old, yet no one is taking even that part seriously.

mfrager 12y ago

This is no longer necessary with MiniLock. See http://minilock.io/ http://minilock.io/ and this article: http://www.wired.com/2014/07/minilock-simple-encryption/ http://www.wired.com/2014/07/minilock-simple-encryption/

dchest 12y ago
miniLock doesn't solve public key distribution problem.

x1798DE 12y ago

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 https://keyserver.pgp.com/vkd/GetWelcomeScreen.event) already seems to have all the features that are missing from the whiteout server (SSL, scalability, e-mail validation, etc). The biggest adoption problem around key management that I see is getting people to generate them securely, then integrating the keys across multiple devices and multiple clients. Maybe this whiteout mail app thing is supposed to be the part of this that makes key management "invisible", but I don't see why they can't use the existing key distribution infrastructure.

michaelt 12y ago
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.
- schoen 12y ago
  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.

bokonist 12y ago

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

mdaniel 12y ago
1. What's wrong with the existing key server protocol? 2. Why TXT and not SRV?
- bokonist 12y ago
  1. From reading their post, it seems like they made their own REST API for the key server. So it would be nice if they open sourced the service behind it, to alleviate fears of lock in. 2. You're right, it probably should be SRV.
- rakoo 12y ago
  TXT is much more available in DNS management interfaces than SRV, so there's a higher chance that you can install such a server on those shared hosting instances.

jrochkind1 12y ago

I think this makes a lot of sense, but: > Even with automatic key lookup, users can later always navigate to the contacts menu and verify a recipient’s key fingerprint if they need to. Okay, how about making this (optional step) way easier too. Show the fingerprint somewhere on-screen everytime you send a message. (Maybe flagged for extra notice the first time the key is imported?) Maybe with a little (i) icon next to the fingerprint, clicking on it explains what it is, and how for top confidence the fingerprint should be checked with the owner directly. A good UI makes it easy for the unsophisticated, but provides cues to give the user an easy and gradual path to being more sophisticated too (and makes being more sophisticated as easy as possible too).

falcolas 12y ago
Rendering the fingerprint as an image (a'la github's default portraits) would help; we can more easily see differences in images than we can strings of numbers.

Kalium 12y ago

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

sixpenrose16 12y ago
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.
- Kalium 12y ago
  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.
rakoo 12y ago
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 like HTTPS Everywhere, it is not enough to guarantee that your messages will be secure against a sufficiently-funded and determined attacker. It puts some power back to the people to enjoy better privacy of communication.
- Kalium 12y ago
  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?

higherpurpose 12y ago

I like Google's End-to-End design better. It seems to add a few extra security checks.

mey 12y ago

https://keybase.io/ 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

pasbesoin 12y ago
Tim Bray's been interested in it, which is where I first heard about it. https://www.google.com/#q=site:tbray.org+keybase https://www.google.com/#q=site:tbray.org+keybase
malgorithms 12y ago
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_bitcoin_blockchain 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 https://keybase.io/chris) for HN users wishing to jump our invitation queue, which is large.
- diafygi 12y ago
  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/ https://diafygi.github.io/publickeyjs/
  - malgorithms 12y ago
    Cool site! Max Krohn (https://keybase.io/max 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 and trusting 3rd party verifications is philosophically pretty different from what Keybase is doing. So we have to figure out how to resolve this. For example, we don't even have an email based lookup at all (!), because we have no way of letting a client verify it's true. I don't know if we can be convinced to change this. We're looking forward to Yahoo's and GMail's work on their E2E projects because it may help verifying email addresses publicly. And to be clear: we're not in the email business, so we want Keybase-style key proofs to be useful to mail clients like Whiteout. We'd like to work well with everyone.

spiralpolitik 12y ago

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.

dublinben 12y ago
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 https://en.wikipedia.org/wiki/VCard#Properties
- spiralpolitik 12y ago
  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.
  - dublinben 12y ago
    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.

kevinr 12y ago

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

tanx 12y ago
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.
- kevinr 12y ago
  Nice!

kybernetikos 12y ago

I encode a public key and bitcoin address into my gravatar image.

diafygi 12y ago

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.

tanx 12y ago
Yes. It gossips with the following list of servers. Keys are uploaded and also fetched form these servers: 'https://pgp.mit.edu' https://pgp.mit.edu', 'http://pool.sks-keyservers.net' http://pool.sks-keyservers.net', 'http://keys.gnupg.net' http://keys.gnupg.net', 'http://keyserver.ubuntu.com' http://keyserver.ubuntu.com', 'http://pks.gpg.cz' http://pks.gpg.cz'
- diafygi 12y ago
  Great to hear! Thanks! Do you know if you are using the SKS keyserver gossip implementation or did you roll your own?

krzyzanowskim 12y ago

Nice writeup. I fully agree on that approach. Some time ago I implemented "invisible" keys for http://privacyapp.io http://privacyapp.io on iOS, with support for HKP and keybase.io API. It works quite well. The only problem is that keyservers from SKS pool have different versions of software and response can be randomly broken for the very same request.

dredmorbius 12y ago

Interesting, but misplaced effort. The biggest problem in widespread adoption of PGP/GPG is client support. Case in point. I've been looking into sizes of various online communities, and decided to look for any hard statistics on the actual traffic levels of Usenet back in the day. So I looked up the old admins. One of those is Eugene "Spaff" Spafford. Also known as something of a security expert -- he wrote the book on it: Practical Unix and Internet Security (PUIS). I've a copy on my shelf. He's at Purdue these days, and his homepage there (http://spaf.cerias.purdue.edu/ http://spaf.cerias.purdue.edu/) lists a PGP key (http://spaf.cerias.purdue.edu/pers/pgp.html http://spaf.cerias.purdue.edu/pers/pgp.html). So I grabbed that, and ran a fetch of the signatures for the key. If you want, you can speed that with a bit of shell magick: gpg --list-sigs 'A40F862E' | grep ^sig | cut -c'13-21' | sort -u | xargs --max-args 10 gpg --recv-keys There's a limit to how many keys keyservers will return, but 10-20 seems a generally safe bet. Wrote my brief email using mutt (which was designed as a reference case for MIME-encoded PGP email), and awaited a response. I no longer use PGP. Please send me readable text. Yes, from Spaff. So I sent him the unencrypted text, he found my Usenet questions interesting. But I was curious about his lack of use of encryption. He responded (and gave me permission to quote him): I don’t have a convenient PGP implementation for my Mac. I used to use the commercial version, but it requires Java and that’s a huge risk. GPG implementations require lots of software I don’t entirely trust, plus there is no nice interface to my email. So yeah. The guy who wrote the book on Unix and Internet security, stymied by lack of a decent client. Until mainstream vendors are integrating this, we're going to be stuck. There are other issues. If I've got multiple devices, I may well wish to use different keys on them. Which means I've got a key-management issue of having people use the right key(s) on messages. There's the problem of key loss (you lose access to everything encrypted with it). There's the challenge of inputting long passphrases on Mobile devices (I'd far prefer a OTP / keyfob type solution or other form of semi-physical security, plus a shorter passphrase). There's device-based backdoors and other exploits. Etc., etc. I've used PGP/GPG for nearly two decades. It remains something of a pain to deal with....

Thespian 12y ago

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/ http://www.voltage.com/products/securemail/

diafygi 12y ago
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 https://diafygi.github.io/emailpk

tanx 12y ago

I updated the post with more detailed threat modeling and SSH as a TOFU case study for UX. Thx for the feedback everyone!