Making PGP Key Management Invisible So Johnny Can Encrypt(blog.whiteout.io)
blog.whiteout.io
Making PGP Key Management Invisible So Johnny Can Encrypt
https://blog.whiteout.io/2015/02/06/making-pgp-key-management-invisible-so-johnny-can-encrypt/
77 comments
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.
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.
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/
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 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.
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.
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 if that would gossip to the pool so I could get it via gpg --recv-key.
Thanks for the great work so far!
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 if that would gossip to the pool so I could get it via gpg --recv-key.
Thanks for the great work so far!
I second all these requests. Exactly what I was thinking when I finally got my invite.
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
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
He wasn't kidding about a bunch, I've only burned through about a tenth of them. :) Still have more available.
Can you give us the txId of a bitcoin transaction used to represent the entire state?
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 identity aspect? Is it supposed to replaced key signing or just augment it?
I'm frankly not sure I fully get my head around the concept, even after reading this page:
https://keybase.io/docs/tracking
But it's Friday afternoon, so that could be it...
How does HN feel about that identity aspect? Is it supposed to replaced key signing or just augment it?
I'm frankly not sure I fully get my head around the concept, even after reading this page:
https://keybase.io/docs/tracking
But it's Friday afternoon, so that could be it...
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 twitter holder. Tracker statements add to the timestamping: when someone runs the Keybase client and tracks them, they sign a statement saying on date X twitter user Y had that public key and they checked it.
The second advantage is that a person is typically a sum of many identities. Consider a known developer who signs code using their Keybase announced key. (Let's say Jeremy Ashkenas does (does he?) - anyway, he's on Keybase as https://keybase.io/jashkenas). His public key is announced on his Github and Twitter accounts, both of which are known. He signs those statements with the matching private key. If you ask Keybase for his key, you get 3 things: Keybase telling you what it is, Twitter agreeing with you, Github agreeing with you, and bitcoin telling you everyone in the world has gotten the same answer for those 3 accounts for the last few months. And CLI tracker statements timestamping, too.
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 twitter holder. Tracker statements add to the timestamping: when someone runs the Keybase client and tracks them, they sign a statement saying on date X twitter user Y had that public key and they checked it.
The second advantage is that a person is typically a sum of many identities. Consider a known developer who signs code using their Keybase announced key. (Let's say Jeremy Ashkenas does (does he?) - anyway, he's on Keybase as https://keybase.io/jashkenas). His public key is announced on his Github and Twitter accounts, both of which are known. He signs those statements with the matching private key. If you ask Keybase for his key, you get 3 things: Keybase telling you what it is, Twitter agreeing with you, Github agreeing with you, and bitcoin telling you everyone in the world has gotten the same answer for those 3 accounts for the last few months. And CLI tracker statements timestamping, too.
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."
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."
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
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.
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 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.
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.
key distribution is the easiest thing about PGP
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.
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.
This is important: since PGP is also used for signing software, and in that world, this kind of compromise can be even more dangerous. The Tor example is great. Also, check out how many keys are on MIT's PGP keyserver for Gavin Andresen of the bitcoin foundation.
Back in 2013 I downloaded bitcoind and spent like an hour just trying to figure out if it was legit or not.
Back in 2013 I downloaded bitcoind and spent like an hour just trying to figure out if it was legit or not.
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.
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 can revoke a key you have generated. But that's only a small part of the battle.
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 can revoke a key you have generated. But that's only a small part of the battle.
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 more cautious PGP user than I am (with an extraordinarily important key!), but I expect she also has no way of forcing people to check that they have the right key when e-mailing her.
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 more cautious PGP user than I am (with an extraordinarily important key!), but I expect she also has no way of forcing people to check that they have the right key when e-mailing her.
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.
* 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.
I check up on you from time to time. Virtunova's been offline for ages as well.
I'm kicking around ways of making email more reliable, one option that occurs to me is key negotiation at transmit time, or as part of the delivery process. That is: a user's home mailserver would be key-aware. Though that too is subject to skulduggery.
I'm kicking around ways of making email more reliable, one option that occurs to me is key negotiation at transmit time, or as part of the delivery process. That is: a user's home mailserver would be key-aware. Though that too is subject to skulduggery.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- -----BEGIN PGP MESSAGE-----
Version: GnuPG v1
hQIMA7xDFKsys5UtARAAxMhajUMAOzPLYSruMqKC8tOX1Ky0TScotJICEcfl2MML
gUvhTShRK0UPLtuXxT+emnKaqAJfPM4RzcuMo6mSIzEnZKGjCa49E+mQIp2129hH
dktyMfNeA7bF2n+FxFpSmv9hF4IihVXwOmdu3OzXrEjYcHpYR8kh5MoANErJAMPj
mCWPfpqqxpLQ7IQGUCu3FYZ1/pbHEfmKa/nOpvAr4zGciFb9p8Jir2ujbxfRGySU
RVEplGeC4vLUlwnRjXENCONtJVKv4oL+e+Z+MKziKhoiNGX5NQTA4AEc958a7Aew
HVQDoRnqYZf9pa4hiqIR2TNyxKfkAxrUtTs8g19VDKPynmTR5oiao+fpZShzMVLF
Wza0KDi+fOqCbZT/1iBVkkyiQt1hEvQBSVyqoxK7MPNshn5dRpFY+Y8oSFHcFosM
+TYk0O9LWMfPjW9eFOpBQHi0orUgJ+X45Pxukn2aBC3Sw9r57ubXTeTTJ9d4Xk9W
QU6SZdL+MrUIFIjOPcd9fB3DCGeT4P56Y+c2L2nkOQRbbwJKRwynBNuJ1YuoMcIS
+3x1+UQzjrCv1E1K0MkGayI4SCFLznDK3zZOzVVpGesUXeI7tm8ix6q+GO2FfhbC
ClBirm6OJcSKr0E0ABVR8tsAyJn2fECA9ssuIm7x+sC8RcjRrzMGgx/eVTXASdSF
AgwDo9/BBkoA4X8BEACAlqrZ3xGRdbJILBXjbmiOe264sNQuQ+DD4OFLhgMI88Cu
WmpKOlHjLDcgmgWLUcbjKCYEgNpqysSUexPNv2sk7sjqBhyPK3UcqgZnnrONbuea
IcJZ3NBTBSkmzv3c9bGFCV7Mt1uKp3gajUXCrlZ1otWo9xRLwlDd1VolrgoWqwot
P0qHclUuVa/DFuHsplosY43zOfcVm9z1thMJE/avgSqwSej50JHvawADVAiVCm8U
pmKE73BDV5uo20xjaZ4rhUcc4iv+VKnENNPR1mYPjPo92bdtRF7zmwCwum3nj37c
53/Q6AvUXt0gCwOIfAaARwyZZGT1d9BC4NCc8cB70lvHQHTkT/qLbZbYoi2TA7bd
k+cR683BuGrBfTLlSXAwvKzppsWocpiJdTdzYlatPH5sAxb4q1MDLpr++hr5V+cd
yHj+8W0SEjsxqNUN3seHpkM/kefLN/gq0vBzb6kJUVz4eJM7nPlmMo5hmwT0P+HW
s+Pn/ZqLUrLlQyuWIEsoONq95DZ1FjMSgQB37+4Oo0wtmGG3fNF6hR5rgp5mkEu/
7zuTzRA51s5kz/pVoqC3FA70S5ZdiIRUoUggjb4W+Rwan2crOzfzVH6JZMRAqlPe
4Y2fQRGU5SDmByR07DsgSXsLgwPyTy/TFtT37B70zw6CH0p/XYTGbsG7ta3G+dJb
AQFoYZyRld4hhNL5BtvrM9WCL9XTwnuYACN0dhW/ym6E7HLY3gq5ahMQj4vLlafY
Z68YabNxRG0eF7errJDWg+itjtgge4zgaXxPUf/h/gpPE5+chSuaSfHpjw==
=zY2a
- -----END PGP MESSAGE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJU1UEGAAoJEKxvHoRCCre9JiIP/iZQoi2C501kj8bMHNMF05d4
4LwEsfmOFBPfDlK5+YP4U48j9nJyMt1eQcA5UqsHGAsZ78hnmXsZTD+LwEE0Tn7f
DD5gMWLt4vulKxblR1Md8A+lfAK0YYzH1dhJbg6KWF9znpg7zeb34t4fWz82bGZ8
FmEJuiI4HqfxCfKwmd8knDZ0rrrBJcZAsc/v5KnVN8zB+bumUX9SLcR1fF1p62nK
tfB/Ri3taEPoz9OXfC4Lmniovu0BbiqIdWBp9vBvYQHp0jIVReKJE+O+NuvGkApR
+oZp17S6nkf3LZTLzSi1bO6TOetMnG+TZhCXHP45JcPTg8Hr7MftuymD+qjbRhLR
WnV6MwYZZns1ZWBjXh5w1zx8vhKyxTbJ0rupoY82hg3nXPInTCyZZAAwFE9+Hsh4
Dbxflr6+9Xt0Mp+BQvkEsL45haCGKtnpyzDrfYqkomKq03D09MIRQFkG8ZX9KEuU
kviw7rQjvDKetwN1gmI+gdEwAmJeDH0gCUijjTOKmy8nBD4i2x4GknDxyUX24HYf
FpyIRtV/MlJwjxa2+0J5vC92QhDzT3rCsAQC/iHkm+B+HdxOpM26Qyu6WbwhXrY5
/E1kYTK6gTiaeDcaax2/V62OTie4JbXV0/ZUXfDMyVa0Yr1Qi0Y7aArB1A0xB6Pg
5tpyUQ14Uo9fGMXoLKfa
=py+D
-----END PGP SIGNATURE----- -----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.11 (GNU/Linux)
hQIMA6PfwQZKAOF/ARAAkzfxMj8XnsmBmGu3uxS6cp/0q1xE/U89sTLlVZmDbwna
IGOXkm1h6DId7Hvwnj+RjYRj/wym3kvrMCXoOPLpqr0y2kGcBxxcW0kdK+zhlz34
ik+Vy+HGp0MZKog6HnBiMotnDZuYJsxZhPE++XSZDj8N/16XNXmvDjuDZTlkvKUm
UX0y8kem2uSN8WjGuQepF2zwwzL8LDjJ7x9RemDgfudkiNkSUQVDz2WNwrrXssR4
g4cRTs0wUaRYa/xDUXvum/uHxOJ/ZF/cEKMB9oXBIw4m+1VHTzLJYz3PFwFHiib3
SWnJ90tm2vjKsp9Q1VQYa8zyINOzDDGMbLP7OgkDU5/nvGFxLflRyvYwVoHkyKuW
Ar/5vHxdf0F4vgJuJHJIieuQcSVv06pvFczmnbQmO9vLMBvRti++Vu2u2olyoyr9
5cgZ+I/AvNXjPN8u3IiyT+6/bwXAT41G6nUZWs7xfqEvX5RFQA4dh/qkjuHpDUWx
ROVzgdqvLpnsO2uZ2Y0++ETuer0aYpqSo03oOb2bNsXdlZF1SSu7dNfSzJv47J5e
yFn5Wn4hK1TswuRYKDy3HGk0au0NSdNfDi83YR17N1xQg5heK1Daf73DWZRnxOPi
EnDHc17Uha3nN+FIKm1JdwxA4T35eJl0pa2S9SPWmHUNWvMwCLC4JqR0Br8Yx8TS
aQGmENhVRPMX73uPo8SDn+M6u0PvJ7pWPKn3ulcwwrMgqSf4qgptozB8g0vTr3YJ
k40OdHO7ebcWN5wkw2dg9tIFFgxnqrpjB7vr0aHJj3Y96AYoD0uSrEiBgX6pIJdz
jGWswAp7O5UfGw==
=DT21
-----END PGP MESSAGE-----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...
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...
PGP is extremely hard to use, so no, it's not "fine". Usability is just as important as (if not more important than) cryptographical correctness!
No, I mean that my argument there was perilously close to said fallacy.
Hrm. Not sure I see that, but that's more acceptable ;-)
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:
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...
> We couldn’t make cross origin requests to HKP
> servers from the web version of our app.
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...
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.
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/
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/
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
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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).
> 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).
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.
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) 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?
2. Why TXT and not SRV?
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.
2. You're right, it probably should be SRV.
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.
Nice writeup. I fully agree on that approach.
Some time ago I implemented "invisible" keys for 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.
Some time ago I implemented "invisible" keys for 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.
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
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.
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.)
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.)
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 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.
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.
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.
The answer is to increase security by having widely adopted imperfect security rather than supposedly perfect but also imperfect[0] security with marginal adoption.
Having a secure initial message exchange is difficult and will always be difficult. Traditional GPG UIs are so obsessed with trying to solve that problem that they ignore the 99% case, in which something like trust-on-first-use is perfectly fine. The fact is, on average, users will be much safer with a TOFU scheme without any key servers or web of trust at all, as long as that scheme is sufficiently unobtrusive so that it actually manages to get adopted.
The sad truth is that I actually use a mail client with GPG support, but I basically never exchange encrypted email for two reasons: It's not automatic, and the vast majority of users don't have GPG support installed anyway - and I'm not going to push others towards using encrypted email as long as it's harder than "install this plugin and you're done". I have other causes to spend mental energy on.
[0] See other threads about problems with fake keys in the web of trust.
Having a secure initial message exchange is difficult and will always be difficult. Traditional GPG UIs are so obsessed with trying to solve that problem that they ignore the 99% case, in which something like trust-on-first-use is perfectly fine. The fact is, on average, users will be much safer with a TOFU scheme without any key servers or web of trust at all, as long as that scheme is sufficiently unobtrusive so that it actually manages to get adopted.
The sad truth is that I actually use a mail client with GPG support, but I basically never exchange encrypted email for two reasons: It's not automatic, and the vast majority of users don't have GPG support installed anyway - and I'm not going to push others towards using encrypted email as long as it's harder than "install this plugin and you're done". I have other causes to spend mental energy on.
[0] See other threads about problems with fake keys in the web of trust.
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.
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.
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.
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.
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.
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/) lists a PGP key (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:
Wrote my brief email using mutt (which was designed as a reference case for MIME-encoded PGP email), and awaited a response.
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):
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....
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/) lists a PGP key (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
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.
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.
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....
This is no longer necessary with MiniLock. See http://minilock.io/ and this article:
http://www.wired.com/2014/07/minilock-simple-encryption/
http://www.wired.com/2014/07/minilock-simple-encryption/
miniLock doesn't solve public key distribution problem.
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'
'https://pgp.mit.edu', 'http://pool.sks-keyservers.net', 'http://keys.gnupg.net', 'http://keyserver.ubuntu.com', 'http://pks.gpg.cz'
Great to hear! Thanks! Do you know if you are using the SKS keyserver gossip implementation or did you roll your own?
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.
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..
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..
>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.
This is equally valid for PGP keys, and a common practice among the security conscious.
I updated the post with more detailed threat modeling and SSH as a TOFU case study for UX. Thx for the feedback everyone!
I like Google's End-to-End design better. It seems to add a few extra security checks.
I encode a public key and bitcoin address into my gravatar image.
Edit: I also have invites available if you are interested in checking it out. Contact me via my HN profile