Live data from Hacker News

A thorough PGP tutorial

futureboy.us

51–60 of 115 posts

Re: A thorough PGP tutorial

#51
post #46
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…

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…

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?

Re: A thorough PGP tutorial

#52
post #51
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…

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?

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

Re: A thorough PGP tutorial

#53
post #50

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

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

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.

Re: A thorough PGP tutorial

#54
post #52
post #51

Earlier quoted context omitted.

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?

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

No problem, I believe you - I was just curious.

Re: A thorough PGP tutorial

#55
post #17

Earlier quoted context omitted.

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.

That's because W3C's goal in having a cryptography standard isn't security, but rather interoperability; they see encryption as another step towards making the web a first-class application development environment. Without it, they can't get Netflix to run on pure "open" web technology.

It's unfortunate, because we could use a secure browser crypto interface much more than we could use better browser interoperability with random non-web technology. But our industry is, of course, fundamentally unserious about security.

Re: A thorough PGP tutorial

#56
post #42
post #39

Earlier quoted context omitted.

I've thought some more about S/MIME, and right now my biggest concern is the CAs. I don't like having that central point of trust/failure. Do you know if S/MIME can work on a distributed model? Also, what are the advantages of S/MIME over PGP? I hear what you're saying about enterprise adoption, but I'm more concerned with the thoroughness of peer review than usage rates.

CAs are not a single point of failure because your private key should never leave your computer. S/MIME is based on X.509, same thing that powers TLS/SSL.

CAs are a single point of failure if a government can get a key that your counterpart's UI will claim belongs to you.

Re: A thorough PGP tutorial

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

Re: A thorough PGP tutorial

#58
post #30
post #27

Earlier quoted context omitted.

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

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.

Re: A thorough PGP tutorial

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

Re: A thorough PGP tutorial

#60
post #52
post #51

Earlier quoted context omitted.

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?

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

Are they better in that they are easier to use (and thus promote security)?
Post reply on HN