
A thorough PGP tutorial - steveklabnik
http://futureboy.us/pgp.html
======
jarrett
There have been several calls in recent weeks for a nice UX wrapping GPG. I'm
thinking of what Cryptocat aims to be, but with a sound implementation resting
on GPG. The crypto community seems supportive of this idea.

I'm not saying I'd be the one to implement this, but at the vert least, I'd
like to start collecting ideas. Maybe I or someone else could realize them
eventually. So let's talk. Please post your thoughts on what would make for a
good, user-friendly, and secure wrapper around GPG. Thoughts from security
specialists would be especially appreciated.

I'll get the ball rolling with a few basic requirements:

* No roll-your-own crypto. Absolutely none. All algorithms must be provided by a mature, universally trusted library. (And those algorithms must of course be GPG, since that's the whole point of the project.)

* Don't use any libraries that, while sound, expose a low-level API such that we could unwittingly _call the API in unsound ways._ An example of this would be OpenSSL. (Just an example; obviously OpenSSL != GPG.) See this for a discussion of the library misuse problem: [https://news.ycombinator.com/item?id=4779015](https://news.ycombinator.com/item?id=4779015)

* Users should have to understand as little as possible about the inner workings of PGP/GPG. However, in any instance where hiding details would compromise security, details must not be hidden. For example, people need to understand the _implications_ of signing someone's key. We don't hide that part from them. But they shouldn't have to fiddle with text files and command lines. We do hide that part.

* A "good user experience" is more than just a GUI. We already have GPG GUIs. User experience doesn't start when the user first boots the program. It starts at the moment a person first hears about GPG and wants to learn more. Thus, good UX is as much about documentation (including the product homepage) as it is about software.

~~~
tptacek
My prediction is that the kernel of the idea that will make GPG usable is to
dispense with the idea of a single keypair, and instead build features that
generate ephemeral keypairs on the fly. Make the system workable for users
even if they don't understand what a keypair is. Some of what makes OTR
effective can be implemented using PGP as the underlying cryptosystem.

When one suggests replacing OTR, one tends to get an earful about the
importance of forward secrecy. I think forward secrecy is very important for
systems in which there are extremely high-value keys that are "stationary
targets". I think forward secrecy is less valuable in desktop applications,
where the attacks that would cough up a persistent key would tend to be
devastating to the whole cryptosystem anyways.

It's also worth saying that PGP isn't a particularly great cryptosystem.
"Modern" PGP predates a lot of important stuff in crypto. But it's a very well
studied cryptosystem.

There are strong cryptographers who are working on much, much better systems
than PGP. The problem is that those systems will compete with amateur systems
and the winner won't be chosen by security. At least with PGP, we know what
we're getting.

~~~
lemming
_There are strong cryptographers who are working on much, much better systems
than PGP._

Could you give us some examples of these? How far away from prime time usage
do you estimate they are? Are any of them usable right now?

~~~
tptacek
I would if I could, but another distinction between real cryptographers and
amateur ones is a desire not to publicize things until the design is
trustworthy. I think you'll have to take my word for this (but I'll try to
think of one I can share).

~~~
tricolon
Are they better in that they are easier to use (and thus promote security)?

~~~
tptacek
What does this mean? We just got finished talking about a system that was
profoundly less secure because it tried too hard to be easy to use.

~~~
DanBC
I understand this discussion is about avoiding snake oil, and only using good
quality trusted respected systems, and using them carefully, but making them
easier to use.

Some examples from PGP include Bob signing Ann's key without sufficient
verification, or people publishing their private and public keys by accident.

Remembering that many people are just hopeless at security ('123456' used as
passwords; people clicking through browser certificate warnings; people
installing malware and ignoring OS warnings about untrusted sources) it seems
a reasonable point to make: "Secure products can be made easier to use, and if
they are both good and easy to use it will enhance security".

------
epistasis
The barriers to modern cryptography seem to be far more social and
psychological than technical.

It seems as though many of the web-of-trust issues that impeded PGP 15+ years
ago could be helped by current day social networking practices, if a social
network pushed it. PGP/GPG could be used under the hood, as long as the user
never has to deal with an actual file anywhere unless they wanted to.

The consequences of evil twin attacks [1] may be worse, but if the 'verify'
action was not as casual as mere friending, then perhaps it would be less
susceptible.

Are any startups working from this angle?

[1]
[http://my.safaribooksonline.com/book/-/9781597495455/chapter...](http://my.safaribooksonline.com/book/-/9781597495455/chapter-4dot-
evil-twin-
attacks/chapter_4_evil_twin_attacks#X2ludGVybmFsX0J2ZGVwRmxhc2hSZWFkZXI/eG1saWQ9OTc4MTU5NzQ5NTQ1NS82Mw==)

~~~
ghayes
I've been thinking about the possibility of doing it under the hood via a
browser extension on major social networks. Something akin to 1) you publish a
photograph of yourself to Facebook that contains your PGP key in EXIF. 2) Your
friends, who can see that photograph, encrypt messages for all friends with
"public key" photographs. Finally, 3) The browser extension seamlessly decodes
all PGP messages through page manipulation (e.g. walking all text nodes and
looking for a specific sentinel, and then decrypting all messages that match
the sentinel). This way, you would be able to communicate securely over a
social network with nothing but a browser extension.

I have a very rudimentary prototype up on Github if anyone is interested. It
has some throw away keys and allows you to encrypt for those via right-
clicking text in a textarea. The code uses OpenPGP.js.

[https://github.com/hayesgm/orangutan](https://github.com/hayesgm/orangutan)

~~~
tlrobinson
Great idea. It has the potential to spread virally if those who don't have the
extension installed are shown a message telling them the benefits of
installing it.

------
wfn
This is a very nice tutorial.

A very small (but rather important, depending on occasion/readership) detail:

    
    
        [...]
        gpg --encrypt --sign --armor -r recipient@email -r your@email.com filename
        [...]
        -r recipient Specifies recipients of the message. You must already have private keys of the people listed. [...]
    

The author probably meant, "You must already have _public_ keys of the people
listed," not _private_. (Probably just a typo-level thing, they doubtlessly
know what they are talking about.)

~~~
bkanber
Glad somebody else pointed this out. I read that and thought it should have
said "public" too, but the rest of the article was so strong that I started
doubting myself and felt like I was going crazy.

------
unethical_ban
My tutorial:

    
    
      * Get Thunderbird and Enigmail.
      * Use Enigmail to generate your keypair
      * Upload your public key to the keyserver (via the GUI)
      * Proceed to use email.
    

BAM! Done a hell of a lot easier than this tutorial.

------
lmgftp
Scary bit is it's not server on HTTPS, which is probably a must-have for sites
that publish public-key information. Much easier to MITM attack the site and
claim to be posting "his" public key and email address while really publishing
your own info, etc.

A great tutorial, however. Very accessible in my opinion and considering it's
purpose my previous paragraph is more of an aside.

~~~
jarrett
That's the purpose of key signing. The author--like almost all PGP users--has
gotten his key signed by third parties. This means that its integrity can be
verified. E.g., if a man in the middle were to intercept the HTTP response and
change the contents of the key, it would lack the signatures.

Still, I suppose it's possible for an adversary to work around this as well.
If you can find enough people who are 1) willing to falsely sign a key, and 2)
trusted by others, you can have these people sign a spoofed key. But then
these people would be putting their reputations on the line, and the
probability of being exposed is high. Thus the cost of the attack is high.

The lesson being: If you're emailing info that is valuable enough to warrant
such a costly attack, verify the key through some other means. Meet the
message recipient in person, for example. And consider a thorough security
audit of everything in your digital and physical life. You're obviously
operating in a far more dangerous world than I do. There are probably many
vulnerabilities available to attackers that have nothing to do with your
email.

~~~
lmgftp
Of course, you're entirely correct in that :)

My warning was truly an aside, and given the nature of a large group of
visitors, of course a handful might not follow best practices and verify the
signatures, etc.

~~~
jarrett
Ah, good point. I see what you mean--if someone is just learning about PGP the
first time, they might not know about issues surrounding key integrity, and
the need for trusted 3rd-party signatures.

------
maaaats
This links illustrates nicely why PGP is not more adopted.

~~~
jlgreco
Does it actually? I think it shows why proverbial grandmothers aren't using
it, but what this describes is well within the grasp of technical users (among
whom adoption is also poor).

~~~
maaaats
Well, I read an Ask HN thread the other day about a guy using PGP, and what
you have to do and give up to have secure email is just not worth it. Not for
me, at least.

------
asdliajd
Some misinformed info in there about not starting your messages with obvious
niceties "Dear fred" or including the same text at the bottom of all your
emails (your email signature). If the crypto is good, this doesn't matter -
it's not deterministic encryption. If it can't pass a known plaintext attack,
you shouldn't be using it. GPG does.

------
noselasd
I have a serious beef with this. The main problem is you need a tutorial like
this. As long as it is as convoluted to set up and operate like this, end to
end security and privacy will only be for the few of us.

This should be ubiquitous, and easy to set up for everyone, which it isn't,
nor are any of the numerous Outlook plugins either.

------
2bluesc
I like it, it's quite a bit more then a tutorial.

------
Newky
It could be my version of GPG, but the following does not work for me:

gpg --armor --export --sign <email>

I changed to

gpg --armor --export <email>

and it works. Just pointing this out as a typo.

------
frio
The tutorial makes no mention of sub-keys. I thought using sub-keys was a
generally accepted good practice? The use-case being that if the sub-key is
compromised, you can invalidate it and issue a new one -- and others who trust
the root don't need to update much.

Is that still the case? Was it ever? I don't know enough about PGP to know,
unfortunately.

~~~
asdliajd
Yes, using subkeys and rotating them is good practice. But really the hardest
problem with pgp is getting people to use it in the first place, so let's not
focus on subkey use, or upgrading from sha1 to sha256 (or better), or key
length (the author uses 1024 bits only).

Though I'm not sure why the author focuses on non-threats like known plain
text attacks, which gpg isn't vulnerable to, and not these issues.

------
Tomte
I have played with GPG time and again, my Enigmail/Thunderbird/OpenPGP card
setup is fully functional.

But what's holding me back is webmail.

I don't use the web interface often, but it has proven to be absolutely
crucial to be able to get some important mail (boarding pass, mail explaining
how to get somewhere etc.) from any computer.

~~~
tehwalrus
you need a cross-platform USB stick program, with all your secrets on it
encrypted properly, for that kind of thing. (The simplest hack I can think of
would probably be python binaries, with a local-webserver based interface.)

I don't know of such an application, or whether the approach is rigorous, I'm
afraid. But I think that's the shape of the solution.

~~~
Tomte
Doesn't help.

First, I'm not remotely interested in running my own mail infrastructur
anymore. Been there, done that. Today it's much too hard to get mails accepted
by others.

But more important: iPads don't have an USB connector, my mobile phone doesn't
have one. Friends have Macs, in other places there might be other crippled
devices.

The web is a universal building block. USB sticks are not.

~~~
rahoulb
I use Lastpass, which has a client for most platforms.

They could be compromised, but they claim all data is encrypted locally before
being sent to their servers. I have not verified that claim.

~~~
Tomte
A password manager does not encrypt or sign mails.

~~~
rahoulb
Sorry, I wasn't clear. I use last pass to transfer my private key to the PGP
app on my iPad (and elsewhere) (as opposed going through Dropbox or whatever).

Relies upon trusting last pass and trusting the iPad of course, both of which
are questionable.

~~~
Tomte
My friend's computers don't have PGP installed. Neither do "surf terminals". I
certainly cannot install PGP there.

Everything that requires some special software to run is a non-starter.

