Live data from Hacker News

A thorough PGP tutorial

futureboy.us

111–115 of 115 posts

Re: A thorough PGP tutorial

#111
post #58
post #30

Earlier quoted context omitted.

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/

Wow this answer is really disconcerting. Are we really so javascript/web programming oriented now that "plug-in" connotes javascript? No I am not talking about JavaScript. I am talking about an actual application level plugin. Think flash, and silverlight not greasemonky. GPG mail is a plug-in to Mall.app. My point is why not a similar browser plugin.

> Are we really so javascript/web programming oriented now that "plug-in" connotes javascript?

Yes, afraid so.

> I am talking about an actual application level plugin. Think flash, and silverlight not greasemonky.

This is absolutely an option. It's a tall order, because there are a lot of browser/OS combinations out there. But I believe it could be very successful.

Re: A thorough PGP tutorial

#112
post #46

Earlier quoted context omitted.

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…

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

My other question about ephemeral keys is whether they're useful for something like email. I understand how they work for transient conversations like HTTPS or chats (although if you archive the chats forever you'd have the same problem). Would you store something like a key version as KeyCzar does and keep multiple keys around, or periodically have to recrypt all archived data as with key rotation? Or have a single key(pair) that is used for archiving data which is different to the one used in transmission?

Re: A thorough PGP tutorial

#113
post #45

Earlier quoted context omitted.

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.

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.

For me at least, this isn't the pain point. Granted, I'm an engineer, but all I've got for data is my own mind, so here's my anecdotal evidence.

The concept of keypairs doesn't seem hard to me. And I think that can be abstracted away a bit anyway. You just need to know that there's this super-secret file (the private key) that you should never leak to anyone, and you need to sync it to your devices. So far, not so bad. As for the public key, I think the software can mostly just handle that for you. I.e. it can take care of uploading it to keyservers.

Signatures might be harder for people to understand. But here still, a good UI could help to abstract that away a bit. Imagine I can just click "get my key signed," enter an email address, and that's it on my end. No more steps for me to take. On my friend's side, it's just an email that comes in, probably with a link using the application's special protocol. My friend clicks the link, her PGP UI boots, and a yes/no pops up. Done.

So I don't think that understanding the mental model is the bottleneck right now. Rather, I think it's that the software and the accompanying documentation are not optimized for getting a naive user off the ground as fast as possible (without compromising security).

Re: A thorough PGP tutorial

#114
post #97

Earlier quoted context omitted.

You can improve the written documentation with diagrams or produce a graphic novel for the reading impaired.

You can do all that stuff, but it's the fact that you have to understand these concepts to use PGP that makes it difficult, not the way they're documented.

I understand this stuff, and I believe I can teach it to my friends. But I don't believe I can convince my friends to put up with the software that is currently available. That is the entire reason I can't find anyone to use PGP with.

Re: A thorough PGP tutorial

#115
post #99

Earlier quoted context omitted.

A password manager does not encrypt or sign mails.

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.

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.

Post reply on HN