Live data from Hacker News

A thorough PGP tutorial

futureboy.us

41–50 of 115 posts

Re: A thorough PGP tutorial

#41
post #33
post #31

Earlier quoted context omitted.

The problem with that method is the recipient of your mail is still relying on that CA to validate your public key. The CA could (willingly or under duress) sign some other public key and claim it's yours, then use that key to impersonate you, and even trick recipients into using that public key to encrypt emails intended for you. That would form the basis of a man-in-the-middle attack. It's unlikely to work if you'v…

that's possible with PGP, too, if you don't verificate key in person. E.g. "hey Alice, I lost my passphrase, please use the attached key or ID xxxx on one of the keyservers" It's even easier to do, because you don't have to trick a CA in creating a duplicate key.

> It's even easier to do, because you don't have to trick a CA in creating a duplicate key.

In some ways it's easier with PGP, yes.

But in some ways relying on a possibly-hostile CA is worse: if the software doesn't really give the user any visibility of key changes, then the impersonator won't even need to social-engineer the recipient with "whoops I lost my key". Instead, the duped recipient will just see "Signed by Big Trusted CA" with a shiny green padlock, and will think everything is fine, even though the key under the hood has changed.

Re: A thorough PGP tutorial

#42
post #39
post #36

Earlier quoted context omitted.

It's already build in e.g. Mail.app. We need no software. We need public awareness, tutorials and probably some easy to use CA. I bet the adoption rate of S/MIME is way beyond gpg if you check corporations and large enterprises. for example: Germany https://gist.github.com/rmoriz/5945400

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.

Re: A thorough PGP tutorial

#43
post #29

Earlier quoted context omitted.

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

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

[deleted]

Re: A thorough PGP tutorial

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

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

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.

Re: A thorough PGP tutorial

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

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.

Re: A thorough PGP tutorial

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

Re: A thorough PGP tutorial

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

Re: A thorough PGP tutorial

#48
post #44

Earlier quoted context omitted.

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

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

That makes sense and I think my comment was a little ambiguous. It wasn't so much an endorsement of cryptocat itself, but the idea that using a centralized system that supports encryption may be a reasonable compromise to protect against indiscriminate collection by third parties, and something I think existing companies that handle most communication already could generally implement.

Re: A thorough PGP tutorial

#49
post #29

Earlier quoted context omitted.

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

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

I agree with your first two points and if the complexity of using pgp were reduced to that of simply using email then I think it'd become more widely used.

I didn't mean to imply that cryptocat itself is a reasonable compromise (I don't know enough), but that a centralized system that implements encryption for its users might be which leads into your fourth point.

Yes javascript client-side encryption is fundamentally flawed in its current form from targeted attacks, but I'm thinking of untargeted and immediate wide spread adoption.

If you're collecting everything from everyone in perpetuity the risk for abuse I see is when someone becomes interesting to the government they can query their data set and use it against them.

I'd think there would be a way to use client side encryption by these companies to protect a user's data until they become 'interesting' at which point they'd have to use more fundamentally secure methods (which is how it currently is anyway).

Seems like the easiest way to get the most people generally protected from abuse.

Is using https enough? If that's the case then it seems like most communication would be protected anyway. I got the impression that this wasn't true - not because I don't trust google, but because of something else (it seemed google genuinely didn't give access to everything yet people made comments about no digital communication being secure: http://www.youtube.com/watch?v=vt9kRLrmrjc).

Re: A thorough PGP tutorial

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

Post reply on HN