
Making PGP Key Management Invisible So Johnny Can Encrypt - tanx
https://blog.whiteout.io/2015/02/06/making-pgp-key-management-invisible-so-johnny-can-encrypt/
======
mey
[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

~~~
malgorithms
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...](https://keybase.io/docs/server_security/merkle_root_in_bitcoin_blockchain)

[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
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
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.

~~~
diafygi
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!

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

------
x1798DE
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

      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
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.

~~~
TheLoneWolfling
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.

~~~
dredmorbius
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](https://en.wikipedia.org/wiki/Seth_Schoen)

His hopelessly out-of-date homepage:
[http://www.loyalty.org/~schoen/](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.

~~~
schoen
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.

~~~
dublinben
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.

~~~
schoen
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.

------
Thespian
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
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)

------
jlrubin
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.

~~~
murbard2
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
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
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...](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)

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
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.

------
jrochkind1
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
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.

------
bokonist
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
1\. What's wrong with the existing key server protocol?

2\. Why TXT and not SRV?

~~~
bokonist
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.

------
krzyzanowskim
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.

------
spiralpolitik
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
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
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
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
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...](https://blog.whiteout.io/2014/07/07/secure-pgp-key-sync-a-proposal/)

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

~~~
tanx
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
Nice!

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

~~~
rakoo
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.

~~~
MichaelGG
Then just require TLS on SMTP. Bam, no more dragnet, zero inconvenience to
users. And, no problems with spam filtering or data recovery either.

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

------
dredmorbius
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....

------
mfrager
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
miniLock doesn't solve public key distribution problem.

------
diafygi
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
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
Great to hear! Thanks! Do you know if you are using the SKS keyserver gossip
implementation or did you roll your own?

------
drzaiusapelord
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.

~~~
darklajid
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..

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

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

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

