15 ms·

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

by jarrett 13y 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 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 13y ago
GPG Tools for OS X isn't bad - it integrates with Mail.app decently. https://gpgtools.org/keychain/index.html 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.
- jarrett 13y 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/ 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.
  - maradydd 13y ago
    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.
rmoriz 13y 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 13y 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.
  - scoot 13y ago
    No, you generate your own, then have the public key signed by a CA having proven your identity to some greater or lesser degree, depending on the level of certification - but generating your own and having it signed is not a straightforward process in my (limited) experience.
    - ncraike 13y ago
      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've already been communicating using the real public key (depending on how the software handles new keys), but for new recipients in particular, it's possible.
      - rmoriz 13y ago
        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.
Nivatius 13y 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
- jarrett 13y 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/ 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 13y ago
iPGMail http://ipgmail.com http://ipgmail.com The website is pretty helpful.
- jarrett 13y 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.
scoot 13y ago
A simple and secure means to copy your private key between devices would be high on my list.
- jarrett 13y 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.
unethical_ban 13y 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.
- tptacek 13y 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.
  - xradionut 13y ago
    You can improve the written documentation with diagrams or produce a graphic novel for the reading impaired.
    - TillE 13y ago
      I've been using Enigmail for about a decade, and PGP longer than that, and I still think it's a pain in the ass. Whenever I'm configuring a new mail client, I have to fiddle with multiple settings just to get it to send encrypted mail. There's a real opportunity to build something much, much simpler on top of PGP. All you really have to do is pick some sensible defaults and automate a few steps. Look at how many nerds can't be bothered with encrypted communication, let alone normal people.
      - xradionut 13y ago
        Making GPG and programs that use it easier to use would be nice. But the primary issue is that many people that should be able to comprehend PKI basics and necessary background material to use it, are too "busy" or "lazy" to spend the limited time to even scratch the surface. I face this daily, since I'm the go-to guy at my office for scripting/coding solutions for these folks. They just want it to work without having to learn or understand their decisions. And these are the same people that will spend hours figuring out complex lunch accounting issues or read volumes on video game strategies or rebuild engines.
fossuser 13y 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.
- jarrett 13y 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/ http://www.matasano.com/articles/javascript-cryptography/
joshuak 13y 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.
- jarrett 13y 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/ http://www.matasano.com/articles/javascript-cryptography/
  - joshuak 13y ago
    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.
    - jarrett 13y ago
      > 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.
- DanBC 13y 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'.
tptacek 13y 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.
- lemming 13y 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?
  - tptacek 13y ago
    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).
    - lemming 13y ago
      No problem, I believe you - I was just curious.
    - tricolon 13y ago
      Are they better in that they are easier to use (and thus promote security)?
qnrq 13y 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-20568610 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/pygpghttpd/pygpghttpd.py 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!
- jakejake 13y ago
  Allow me to pimp my own lib which might be useful since roundcube is PHP: https://github.com/jasonhinkle/php-gpg 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.
  - qnrq 13y ago
    My plugin does nothing crypto based on the server side, everything is happening locally in the browser through JavaScript and in the future there will be an additional driver for performing crypto opts in GPG binaries as described in my comment above. I don't mean to be harsh but server sided crypto is far from a good idea. It provices violent regimes, such as America, a technical ground to force hosts into backdooring their server sided crypto. Anything alike must be done on the client for safety and privacy to be ultimately achieved. You should rethink that design strongly.

by jarrett 13y ago

chiph 13y ago

GPG Tools for OS X isn't bad - it integrates with Mail.app decently. https://gpgtools.org/keychain/index.html 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.

jarrett 13y 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/ 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.
- maradydd 13y ago
  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.

rmoriz 13y 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 13y 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.
- scoot 13y ago
  No, you generate your own, then have the public key signed by a CA having proven your identity to some greater or lesser degree, depending on the level of certification - but generating your own and having it signed is not a straightforward process in my (limited) experience.
  - ncraike 13y ago
    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've already been communicating using the real public key (depending on how the software handles new keys), but for new recipients in particular, it's possible.
    - rmoriz 13y ago
      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.

Nivatius 13y 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

jarrett 13y 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/ 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 13y ago

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

jarrett 13y 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.

scoot 13y ago

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

jarrett 13y 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.

unethical_ban 13y 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.

tptacek 13y 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.
- xradionut 13y ago
  You can improve the written documentation with diagrams or produce a graphic novel for the reading impaired.
  - TillE 13y ago
    I've been using Enigmail for about a decade, and PGP longer than that, and I still think it's a pain in the ass. Whenever I'm configuring a new mail client, I have to fiddle with multiple settings just to get it to send encrypted mail. There's a real opportunity to build something much, much simpler on top of PGP. All you really have to do is pick some sensible defaults and automate a few steps. Look at how many nerds can't be bothered with encrypted communication, let alone normal people.
    - xradionut 13y ago
      Making GPG and programs that use it easier to use would be nice. But the primary issue is that many people that should be able to comprehend PKI basics and necessary background material to use it, are too "busy" or "lazy" to spend the limited time to even scratch the surface. I face this daily, since I'm the go-to guy at my office for scripting/coding solutions for these folks. They just want it to work without having to learn or understand their decisions. And these are the same people that will spend hours figuring out complex lunch accounting issues or read volumes on video game strategies or rebuild engines.

fossuser 13y 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.

jarrett 13y 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/ http://www.matasano.com/articles/javascript-cryptography/

joshuak 13y 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.

jarrett 13y 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/ http://www.matasano.com/articles/javascript-cryptography/
- joshuak 13y ago
  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.
  - jarrett 13y ago
    > 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.
DanBC 13y 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'.

tptacek 13y 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.

lemming 13y 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?
- tptacek 13y ago
  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).
  - lemming 13y ago
    No problem, I believe you - I was just curious.
  - tricolon 13y ago
    Are they better in that they are easier to use (and thus promote security)?

qnrq 13y 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-20568610 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/pygpghttpd/pygpghttpd.py 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!

jakejake 13y ago
Allow me to pimp my own lib which might be useful since roundcube is PHP: https://github.com/jasonhinkle/php-gpg 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.
- qnrq 13y ago
  My plugin does nothing crypto based on the server side, everything is happening locally in the browser through JavaScript and in the future there will be an additional driver for performing crypto opts in GPG binaries as described in my comment above. I don't mean to be harsh but server sided crypto is far from a good idea. It provices violent regimes, such as America, a technical ground to force hosts into backdooring their server sided crypto. Anything alike must be done on the client for safety and privacy to be ultimately achieved. You should rethink that design strongly.