81–90 of 115 posts
This links illustrates nicely why PGP is not more adopted.
Does it actually? I think it shows why proverbial grandmothers aren't using it, but what this describes is well within the grasp of technical users (among whom adoption is also poor).
Earlier quoted context omitted.
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, th…
You can't do cryptography in Javascript (yet). There is no point in encrypting client side if 1) the server provided the cryptographic libraries (so they may be compromised) 2) every kind of javascript code external to the crypto library can modify it, modify the environment, read everything that is passed around I don't know how the not yet standardized window.crypto will adress 2), but as of now you can't trust DOM…
But yes there is JS crypto in the project, as a planned separate optional driver.
Earlier quoted context omitted.
You can't do cryptography in Javascript (yet). There is no point in encrypting client side if 1) the server provided the cryptographic libraries (so they may be compromised) 2) every kind of javascript code external to the crypto library can modify it, modify the environment, read everything that is passed around I don't know how the not yet standardized window.crypto will adress 2), but as of now you can't trust DOM…
Check the links posted in the comment you replied to, it's not cryptography in JavaScript: it's JavaScript posting to a httpd on user's localhost which bridges GnuPG. It's not for doing cryptography in JavaScript, it's for doing cryptography in GnuPG and passing it through a httpd which the js talks to. But yes there is JS crypto in the project, as a planned separate optional driver.
1) you connect to server A
2) you want to encrypt sensitive informations. You send them to (localhost) B
3) you receive encrypted data
4) you use them through server A
Aren't you sending sensitive informations though javascript served by server A? Didn't you just loose the security that you wanted by encrypting on localhost?
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.
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.
you need a cross-platform USB stick program, with all your secrets on it encrypted properly, for that kind of thing. (The simplest hack I can think of would probably be python binaries, with a local-webserver based interface.) I don't know of such an application, or whether the approach is rigorous, I'm afraid. But I think that's the shape of the solution.
Earlier quoted context omitted.
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, th…
You can't do cryptography in Javascript (yet). There is no point in encrypting client side if 1) the server provided the cryptographic libraries (so they may be compromised) 2) every kind of javascript code external to the crypto library can modify it, modify the environment, read everything that is passed around I don't know how the not yet standardized window.crypto will adress 2), but as of now you can't trust DOM…
Earlier quoted context omitted.
CAs are a single point of failure if a government can get a key that your counterpart's UI will claim belongs to you.
Not necessarily true. There are certainly CAs that are able to keep their private keys out of the hands of most governments. But there is definite uncertainty about who to trust. For the truly cautious, wouldn't it make sense to explore setting up your own CA? Something like OpenCA or TinyCA should do the trick.
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.
How many regular users do you know who actually edit their list of trusted CA's in their browsers? (I sure don't, though I probably should.) Who would manually remove DigiNotar immediately because they heard on the news they got hacked? No, Big Well-Designed Site is signed by Big Company, user trusts it.
On the other hand, if I give you a key that's signed by someone you trust, you can make an informed decision on whether to trust my key. It is a decision on a level where the regular user might feel they have something to say (whereas a regular user is not likely to feel they know more about security than Big Company).
Perhaps most users would have very few keys that they trust/verify. But I'd say that's a good thing, because if you haven't gotten real verification, it's just a false sense of security.
Earlier quoted context omitted.
you need a cross-platform USB stick program, with all your secrets on it encrypted properly, for that kind of thing. (The simplest hack I can think of would probably be python binaries, with a local-webserver based interface.) I don't know of such an application, or whether the approach is rigorous, I'm afraid. But I think that's the shape of the solution.
Doesn't help. First, I'm not remotely interested in running my own mail infrastructur anymore. Been there, done that. Today it's much too hard to get mails accepted by others. But more important: iPads don't have an USB connector, my mobile phone doesn't have one. Friends have Macs, in other places there might be other crippled devices. The web is a universal building block. USB sticks are not.
They could be compromised, but they claim all data is encrypted locally before being sent to their servers. I have not verified that claim.
Earlier quoted context omitted.
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.
You can improve the written documentation with diagrams or produce a graphic novel for the reading impaired.
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.