A thorough PGP tutorial

by steveklabnik • 13 years ago

183 109 13 years ago

2bluesc• 13 years ago

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

lmgftp2• 13 years ago

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.

jarrett17• 13 years ago

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.

lmgftp2• 13 years ago

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.

asdliajd3• 13 years ago

Install gpg-curl, use hkps (TLS key exchange)

https://we.riseup.net/riseuplabs+paow/openpgp-best-practices...

Edit: nevermind, i see you meant the site with the tutorial, not key exchange

Newky• 13 years ago

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.

epistasis• 13 years ago

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

ghayes• 13 years ago

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

tlrobinson• 13 years ago

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• 13 years ago

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• 13 years ago

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.

maaaats2• 13 years ago

This links illustrates nicely why PGP is not more adopted.

jlgreco• 13 years ago

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

maaaats2• 13 years ago

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.

jarrett17• 13 years ago

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

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

chiph• 13 years ago

GPG Tools for OS X isn't bad - it integrates with Mail.app decently.

https://gpgtools.org/keychain/index.html

However, it's still a minor pain to use for web-based email. You have to remember to select the entire body, right-click, Services, then select Encrypt. Not sure what can be done other than make it a browser extension, but the history on them isn't exactly stellar, security-wise.

jarrett17• 13 years ago

I didn't find it to be a good user experience. The GUI is OK, but when I talk about UX, I'm talking about more than that. I'm talking about what it feels like to visit the product's site for the first time with no clue what it is.

Go to the GPG Tools homepage. It's kind of a mess of links, without a dead-obvious path for the absolute beginner. Should I click "Quickstart tutorial" or "introduction?" Or should I just download the installer, which is my first step for 90% of applications? And the experience doesn't get less confusing when you get past the home page. If anything, it gets more so.

GPG Tools strikes me as a project that is by hackers, for hackers. Nothing wrong with that. But it's very different from what I envision. I want a UX that holds my hand. It should be like a teacher, patiently guiding me through everything I need to know to use GPG.

Fortunately, the mental model for how GPG works isn't actually that complicated. I think most people can understand, for example, what key signing is, if it's explained well.

Apologies to the maintainers of the GPG Tools. Their work is admirable and greatly exceeds the whole lot of nothing I've contributed. I'm hoping this will be interpreted as constructive criticism.

However, it's still a minor pain to use for web-based email.

I don't see this problem being solved without something implemented in native code. See:

http://www.matasano.com/articles/javascript-cryptography/

There have been proposals to add a crypto API to browsers, where such API would be implemented in native code. I.e. you could call the API from JS, but the algorithms would all run in native code. I don't know if any of these proposals will go anywhere.

Conceivably, one could also just up and write C modules for popular browsers. But then you'd have to get those accepted by the browser makers.

Either of these solutions is beyond the scope of what I envision, at least for now.

rmoriz4• 13 years ago

use S/MIME, leave gpg for special cases.

S/MIME works everywhere (Outlook, Mail.app, iOS, Thunderbird, BlackBerry, Windows Phone, Lotus, ... ) out of the box. No plugins required.

Osmium• 13 years ago

I hear this, but I have absolutely zero idea how to get s/mime working and I'm faintly aware it might involve having to buy a digital certificate off someone (and doesn't that mean that someone could decrypt my email anyway? if they're the ones who generate the certificate?)

What I'm trying to say here is: I'm a bit of a geek, and if I don't understand how it works, there's no way e.g. my parents are. If s/mime is the solution, there's a serious education battle that needs to be fought.

I say this as someone who uses GPG (via GPG Tools on OS X) without any bother.

jarrett17• 13 years ago

Do you mean we should build a good UX around S/MIME? It seems clear to me that none currently exists.

I'd be curious to hear from security specialists about S/MIME. How thoroughly studied is it? How are the libraries? I have hardly ever heard it discussed, so I'm a little hesitant at the moment.

unhammer• 13 years ago

S/MIME suffers from the same problem as SSL/TLS: everyone puts their trust in CA's, and CA's regularly get hacked, tricked, controlled by governments, etc. etc. It does not matter that you created your own private key if someone else can create their own private key too and have that signed by a bad (but trusted-by-everyone) CA.

How many regular users do you know who actually edit their list of trusted CA's in their browsers? (I sure don't, though I probably should.) Who would manually remove DigiNotar immediately because they heard on the news they got hacked? No, Big Well-Designed Site is signed by Big Company, user trusts it.

On the other hand, if I give you a key that's signed by someone you trust, you can make an informed decision on whether to trust my key. It is a decision on a level where the regular user might feel they have something to say (whereas a regular user is not likely to feel they know more about security than Big Company).

Perhaps most users would have very few keys that they trust/verify. But I'd say that's a good thing, because if you haven't gotten real verification, it's just a false sense of security.

Nivatius• 13 years ago

I think a plugin that whould do the following whould be great allready:

"Paste and crypt" paste text into field or mark it. hit encrypt. pop/menu/whatever lets you choose or import public keys.

"paste and decrypt" basically the same funtionality backwards

jarrett17• 13 years ago

Do you mean a browser plugin? Probably the biggest issue currently is that browser plugins tend to be written in JS. See this for why it's a problem:

http://www.matasano.com/articles/javascript-cryptography/

If we someday have an ecosystem of C browser extensions, in-browser crypto may be much more promising. Or not. I suppose there could be other problems besides the language.

floatboth• 13 years ago

iPGMail http://ipgmail.com The website is pretty helpful.

jarrett17• 13 years ago

Yes, that's a step in the right direction. (In terms of UX. I won't make any claims either way about its security.) In any case, I'd definitely want a solution that works on the desktop. I don't know if iPGP integrates with keyservers, but that would also be an important feature.

scoot2• 13 years ago

A simple and secure means to copy your private key between devices would be high on my list.

jarrett17• 13 years ago

Yes, very good point. I'd probably be in favor of having two ways of doing it:

* Some kind of "sync" for people who hate dealing with files.

* Copying a single file by whatever means you see fit, such as a USB stick. Many people, such as myself, prefer the simplicity and transparency of a good old file.

Each of these has potential security pitfalls. Those would have to be thought out.

gonehome3• 13 years ago

The issue with security is that you're not competing with other secure solutions, but with the convenience of unsecured. I've read that even journalists that face real risk communicating without pgp don't bother because it's difficult to participate in something that requires others to also participate. There's also the issue that email is only one (slow) form of digital communication.

Cryptocat (ignoring security for a moment) is an attempt to solve the accessibility problem in a way that actually works. Widespread adoption works well with some central aspects - and if we're talking about dragnet avoidance for most people then this is probably a reasonable compromise.

If Google generated public/private key pairs for each gmail user tied the keys to each account and then used the public keys to encrypt all email (taking a similar approach to using real OTR for google hangout) then all google->google communication would have a layer of protection from unwanted ISP monitoring. Granted you're still trusting google with the private key and warrants or some request could still reveal it, but you'd actually have wide scale use of the thing. Facebook could do something similar for their chat and then you'd have most of how people actually communicate covered across multiple devices in a way that protects against sweeping surveillance.

I'm pretty ignorant about most of this - am I missing something obvious that would prevent this from working? Obviously you're stil trusting the companies, but we were doing that anyway.

jarrett17• 13 years ago

The issue with security is that you're not competing with other secure solutions, but with the convenience of unsecured.

True, but that doesn't mean the convenient and insecure apps have to totally dominate the market. I'd be willing to bet there are plenty of people who want true, reliable security, and are willing to take on a little hassle for it.

I've read that even journalists that face real risk communicating without pgp don't bother because it's difficult to participate in something that requires others to also participate.

The same could be said of the early days of email: It's only useful if other people are also using it. But we overcame that chicken and egg problem. The same could happen for PGP. It's a cost-benefit equation: People need to be sufficiently worried about privacy, and the friction of PGP needs to be sufficiently low. There must be some tipping point.

Cryptocat...is probably a reasonable compromise.

Not if it can be cracked with the processing power of a mere desktop computer. I've heard claims to this effect. What are the use cases for a sort-of-secure app like Cryptocat? Certainly not hiding from sophisticated adversaries. So it's just about protecting your data from casual users then. But in that case, I'd argue that even your basic instant messaging client is adequately secure, in that a casual user doesn't know how to play man-in-the-middle.

If Google generated public/private key pairs for each gmail user

Either you're encrypting server-side or client-side, in that scenario. If server-side, you're not much better off than just using HTTPS. Google still has your plaintext. So if you trust Google, just use HTTPS. And if you don't trust Google, then encrypting server side is pointless. Client-side encryption isn't currently viable: http://www.matasano.com/articles/javascript-cryptography/

tptacek9• 13 years ago

Cryptocat is an attempt to solve the accessibility problem that essentially handwaves away many key problems in cryptographic security. It's a system that is simple for users to use because it's simplistic, and is thus less secure even than some other very-simple systems.

For instance, OTR (as implemented by IM clients) is an example of an extraordinarily simple cryptosystem (I'd argue too simple) that at least provides for a notion of persistent keys.

joshuak2• 13 years ago

I don't understand why webmail seems to be such a conundrum for everyone. Can't we just write plugins that looks for encrypted messages, and signatures in a page or ajax request and if you have the key in your keychain you get promoted for it. It seems like this would be an even easier plugin then the Mail.app one.

That being said I think the real solution is OS level integration. Perhaps a facebook app to help grandma with web of trust.

jarrett17• 13 years ago

The issue is that plugins must generally be written in JavaScript. It's generally felt that, at least with the current state of technology, in-browser JavaScript interpreters haven't been sufficiently vetted to trust with crypto. For more details on this point: http://www.matasano.com/articles/javascript-cryptography/

DanBC3• 13 years ago

There's some stuff about trust of keys. When Alice uses Bob's public key she has to know that it actually is Bob's key.

Looking at other password / certificate mistakes (people use 123456 as a password for important accounts, people click through warnings) I think this might be harder than it seems.

See for example some of the hoax accounts on Twitter. People do get confused, even though it should be easy enough to spot the real account over the hoax account.

Online reputation and trust is important. It's a shame that Klout (totally irrelevant to this) is what most people think of when I say 'online reputation'.

unethical_ban2• 13 years ago

I'd call out something I mentioned in my other comment in this thread: Enigmail + Thunderbird makes it pretty easy to get PGP up and running. Make an elegant doc on configuring that, put up a refreshing landing page, and you're golden.

tptacek9• 13 years ago

It still requires users to understand that they have a public and a private key, and just one of them, and a "key ring" to which they add their counterparties public keys, and that those keys themselves have to be authenticated and "signed" if the system is to be secure.

tptacek9• 13 years ago

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.

lemming3• 13 years ago

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?

beagle3• 13 years ago

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.

Is there anything available today that you'd recommend over PGP, regardless of usability or ubiquity? e.g., if one has to include crypto inside an internal-use only email product, that requires both encryption and/or signatures - what's an alternative to PGP that would be considered reliable?

jarrett17• 13 years ago

generate ephemeral keypairs on the fly

You're right--that would be a major boost to usability. One question though: Does this undermine the security of PGP in terms of identity verification? I mean, if I'm receiving an ephemeral public key over the wire, how do I know it's not being generated by a man in the middle? With semi-permanent, published keys, I can put my trust in the signatures. But I'd imagine that the scheme you're proposing doesn't have signed keys. Or am I mistaken about that?

It's also worth saying that PGP isn't a particularly great cryptosystem.

Do you feel the best move is to push forward with PGP, use something else now, or wait for newer systems to be better-studied?

qnrq6• 13 years ago

Hi,

I'm glad I found your comment, I just pushed something like what you just described to one of my repos yesterday. Hear me out, I'm not self promoting myself out of context here.

I'm currently working on an OpenPGP integration for the Roundcube webmail project and have so far added functionality from the OpenPGP.js library. The pros of this is of course usability and that no external applications are necessary, the cons are, amongst others, what you just wrote above.

To be able to support briding local GPG binaries and keyrings into graphical browsers without exposing any critical information I threw together an HTTPD which listens on the client's localhost. The concept is already proven to work, now it's a mere matter of implementation. It's based on the PyGPG library which wraps GPG into Python and is compatible with both Windows and *NIX systems as long as they can execute GPG and Python (which they can).

It's still a work in progress but currently supports key generation and key listing in response to HTTP requests. Through cross-origin resource sharing users can specify which domains should be allowed to speak to it in a simple text file separated by line breaks.

I wrote up more detailed info on the approach and usage here: https://github.com/qnrq/rc_openpgpjs/issues/64#issuecomment-... Source code currently available here, although it will be separated to its own repository later: https://github.com/qnrq/rc_openpgpjs/blob/pygpghttpd/pygpght...

I can conclude that what you are requesting is actively being built and partially already exists but still needs to be put to use. Hope you don't view this as shameless advertising, because it's not. I'm only responding because your ideas are spot on what I pushed yesterday.

Any form of feedback is greatly appreciated.

Much love!

jakejake3• 13 years ago

Allow me to pimp my own lib which might be useful since roundcube is PHP:

https://github.com/jasonhinkle/php-gpg

I'm working on encryption and signing as well. Key generation would be nice as well. I need a little help with it though.

riquito2• 13 years ago

You can't do cryptography in Javascript (yet). There is no point in encrypting client side if

1) the server provided the cryptographic libraries (so they may be compromised)

2) every kind of javascript code external to the crypto library can modify it, modify the environment, read everything that is passed around

I don't know how the not yet standardized window.crypto will adress 2), but as of now you can't trust DOM level encryption.

unethical_ban2• 13 years ago

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.

noselasd• 13 years ago

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.

frio• 13 years ago

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.

asdliajd3• 13 years ago

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.

Tomte4• 13 years ago

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• 13 years ago

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.

Tomte4• 13 years ago

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.

dfjiasdfjkl• 13 years ago

Why rely on the (possibly compromised) OS of the host computer's hard drive when you can boot your own OS straight from the USB itself? What you are looking for is tails (https://tails.boum.org/) with a luks encrypted persistent partition.

asdliajd3• 13 years ago

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.

A thorough PGP tutorial

Related Stories