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.
Making PGP Key Management Invisible So Johnny Can Encrypt
31–40 of 78 posts
Re: Making PGP Key Management Invisible So Johnny Can Encrypt
#32Earlier quoted context omitted.
key distribution is the easiest thing about PGP The problem is if you look at the key server and find there are two keys - one legitimate, one posted by an adversary (who has read access to the recipient's e-mail) - both have a few signatures, but the signatories are several degrees away from you in the web of trust.
Someone made a fake key for each of the participants in a particular keysigning party in October 2013 (including me) and uploaded the fake keys to keyservers. Because the creation date of the fake key for me is newer than the creation date of my real key, apparently Enigmail is suggesting it to people and they're choosing to use it, despite the lack of signatures. More than a dozen different people have now sent me e…
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.
Re: Making PGP Key Management Invisible So Johnny Can Encrypt
#33https://keybase.io/ with it's social media identity proofs have been interesting way to allow finding contacts in my social network's pgp keys. Edit: I also have invites available if you are interested in checking it out. Contact me via my HN profile
Two things we're particularly proud of at Keybase are (1) that there's no server trust of these proofs, and (2) we pin the entire state of the directory to the bitcoin blockchain, to prevent forking. [1] In other words, if you ask for Twitter user X's public key, your client can check that proof on twitter itself (rather than trusting that a key server did it for you, like it would with email proofs), and it can trus…
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:
Re: Making PGP Key Management Invisible So Johnny Can Encrypt
#34Earlier quoted context omitted.
key distribution is the easiest thing about PGP The problem is if you look at the key server and find there are two keys - one legitimate, one posted by an adversary (who has read access to the recipient's e-mail) - both have a few signatures, but the signatories are several degrees away from you in the web of trust.
Someone made a fake key for each of the participants in a particular keysigning party in October 2013 (including me) and uploaded the fake keys to keyservers. Because the creation date of the fake key for me is newer than the creation date of my real key, apparently Enigmail is suggesting it to people and they're choosing to use it, despite the lack of signatures. More than a dozen different people have now sent me e…
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.
Re: Making PGP Key Management Invisible So Johnny Can Encrypt
#35Earlier quoted context omitted.
Two things we're particularly proud of at Keybase are (1) that there's no server trust of these proofs, and (2) we pin the entire state of the directory to the bitcoin blockchain, to prevent forking. [1] In other words, if you ask for Twitter user X's public key, your client can check that proof on twitter itself (rather than trusting that a key server did it for you, like it would with email proofs), and it can trus…
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 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.
Re: Making PGP Key Management Invisible So Johnny Can Encrypt
#36Nice 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.
Re: Making PGP Key Management Invisible So Johnny Can Encrypt
#37So... 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.
Re: Making PGP Key Management Invisible So Johnny Can Encrypt
#38So... the answer is to decrease security by just dismissing whole attack classes?
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.
Re: Making PGP Key Management Invisible So Johnny Can Encrypt
#39So... the answer is to decrease security by just dismissing whole attack classes?
The real goal here is not to provide state-level security; it is to increase the cost of massive surveillance by deploying the easy parts of PGP everywhere. The people who are highly dependent on security will run through the whole procedure anyway, they won't just rely on whiteout. "Johnny", on the other end of the spectrum, will see the privacy of his communication greatly improved againts passive attacks. Much lik…
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?
Re: Making PGP Key Management Invisible So Johnny Can Encrypt
#40Interesting, 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:
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....