Live data from Hacker News

A thorough PGP tutorial

futureboy.us

11–20 of 115 posts

Re: A thorough PGP tutorial

#12
post #5
post #4

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.

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) willin…

[deleted]

Re: A thorough PGP tutorial

#13
post #10

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 jus…

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.

Re: A thorough PGP tutorial

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

Re: A thorough PGP tutorial

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

Re: A thorough PGP tutorial

#16
post #14

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…

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.

Re: A thorough PGP tutorial

#17
post #16
post #14

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…

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.

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.

Re: A thorough PGP tutorial

#18
post #14

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…

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.

Re: A thorough PGP tutorial

#19
post #17
post #16

Earlier quoted context omitted.

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.

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 d…

The W3C working group will eventually produce a crypto API standard, though whether that standard will meet the requirements you describe remains to be seen. In particular, it exposes primitives (the proposed API can definitely be called in unsound ways), which a whole lot of people think is a terrible idea but which the standard editor seems bound and determined to ship. It's very frustrating.

Re: A thorough PGP tutorial

#20
post #18
post #14

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…

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.

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.

Post reply on HN