OpenPGP JavaScript implementation
github.com
github.com
Both this and GnuPG encrypt and decrypt data with PGP keys. GnuPG, however, does this securely, in many, many senses of the word. For instance, GnuPG maps all of its buffers to protected memory pages, and clears its buffers frequently and early.
A very large portion of GnuPG's code is dedicated to protecting your private keys, and the techniques that they use simply aren't available to javascript.
This doesn't mean the JS library is bad, it's just a good thing to keep in mind. Don't run your nuclear launch codes through this.
Just keep them in your coat pocket:
(a Javascript PGP library that might be safe for nuclear launch codes)
That distinction is silly.
But, really:
openpgpjs, the topic of the article, is a program that implements the OpenPGP standard, and the cryptographic algorithms it depends on.
node-gpg, the topic of this comment, does not implement any part of the OpenPGP standard, nor any cryptographic algorithms. It executes a local C program, GnuPG. If you don't have that C program, it does nothing.
Suggesting that they are the same thing is silly. The distinction is massive.
Otherwise, I could claim I just implemented a world-class PGP implementation! To try it out, just run: perl -e "exec 'gpg'"
This is an example of cargo cult thinking: well, cryptography is good, right? It protects me. I wish I had ENCRYPTED WEBMAIL, wow!
But seriously, think for a second what the threat model is.
Do you trust the webmail host to securely store your data and only give it up under warrants, etc? If so, then ordinary plain text communication over SSL is fine.
Do you not trust the host? Then them saying "oh, look at us, we're encrypting your emails" shouldn't make you feel any better. I mean, if you use the site to view your damn emails, then THEY'RE SITTING THERE "DECRYPTED" ON THE PAGE, and the host that you don't trust can do a simple $.post(...) of its contents, for example.
I seriously fail to see any example where this library is useful. Anyone have suggestions? In your suggestion be sure to note whether you trust the host or not, and if so why not just use SSL, and if not, why the host can't just bypass it with a line of jquery.
I could even use gmail as the pop3/smtp server, if the mails are encrypted anyway.
Anyway if you control the host, and it communicates with you through SSL using a self-signed certificate, and you make sure you have no awkward browser extensions installed then your attack vectors are dwindling fast.
Ofcourse once the machine is compromised it can trick you into giving it the key, but there are also countless scenarios where that is not possible. It is really an improvement onto your security.
Lets not pretend that read-protected memory is such a secure way of storing private keys.
In other words, if the host is sitting on your desk. Chances are good that you have more control over the computer you type your messages on than some server you set up. What makes you think that the rack mount you left in your mom's basement is not being tampered with while you are away?
"your attack vectors are dwindling fast"
Now you need to trust both the host and your client machines, while before you only needed to trust your clients.
Wow really? I don't think those chances are good at all.. I'm not sure how often it happens that a running server is tampered with physically but I don't think that chance is as high as my client system running any malware beyond my control.
Let us for example say that I have a server which you are fairly certain that noone will compromise, but you do have a concern that someone might physically steal it. In such a case you might be more likely to trust the javascript it serves than you are to trust it with storing your actual private key.
(Yes, I realize that someone who gets physical access to the machine will be able to modify its code, etc. Yet, while it might be fairly easy for someone to physically break into a building it might be harder to do so without leaving any traces behind, alerting you of possible tampering.)
By the way, my trust example above is fairly similar to the use of ssh-agent forwarding; where you trust a machine enough not to abuse an active forwarding, but without having to trust it to actually store your private ssh key.
Neither do I understand why you appear to say that SSL would provide a comparably security. OpenPGP will definitely provide a stronger transport security than the possibly of there being SMTP StartTLS being done. Likewise might OpenPGP matter for the recepient, especially if that person are doing the decryption locally on a workstation/laptop, saving that person from having to trust his/her mail provider.
Here is why it might actually be a good thing:
1. Encrypting in the browser provides a more audit-able process. You still can't audit the webmail provider's server security, you can't ensure that they won't start serving borked Javascript in a month, but you can audit your data exposure assuming they do that correctly (which you have to assume anyway). Example: you have no way of verifying that <webmail-provider-X> isn't storing backups of your email on a publicly accessible endpoint (say, a public Dropbox). With PGP in browser, you may not care about that oversight.
2. Your trust in a provider is somewhat revokable. The webmail provider is able to launch an on-line attack against you by serving different Javascript, but they may not (depending on how the code is implemented) be capable of acquiring historical user data. This could be useful if, for example, an incident occurs where you no longer trust a provider (for example, after an event occurs, like Skype being sold to Microsoft, you could change providers safely assuming that Skype pre-Microsoft was 'safe').
3. Exposing a webmail PGP interface makes it easy for less technical people to communicate with people who may not trust their provider. For example, you may believe that gmail isn't going to do anything bad, and therefore have no interest in setting up Thunderbird+Enigmail. However, you may want to send email to a person who is forced to use an untrustworthy provider (and therefore uses a 'correct' PGP setup like Enigmail).
4. Exposing a webmail PGP interface allows people to play with PGP and become familiar with it before investing the time in a more robust software configuration.
With Chrome, Firefox, and Safari, it is possible to deliver web apps as signed, local browser plugins, applications and extensions. This greatly helps with solving the problem. In fact, I believe that it is necessary to deliver JavaScript cryptography-using webapps as signed browser extensions, as any other method of delivery is too vulnerable to man-in-the-middle attacks to be considered secure.
The government can subpoena your emails on gmail, but I think they might have a more difficult time convincing google to change their javascript to add a $.post to steal your decrypted emails.
Also, these attacks rely on the user actively logging in. So if you are in jail or dead , your data will be safe.
But don't release them as products. Especially don't release them as RFC compliant secure products!
A few people need effective security. Not having good crypto puts those people at risk of lifetime imprisonment, or death, or torture.
Proper cryptography is hard. There are very many seemingly small things that can ruin the security of the cryptography.
This is something that well funded governments have struggled with. The people involved with making and breaking crypto systems are smart, and experienced, and sometimes have considerable resources available to them.
WebPG (http://webpg.org/) is the best implementation so far for GMail integration, and as far as I can tell it's the only one still being developed, but it falls over at the last hurdle, it won't send the email :)
As a resident of the UK, with our governments boner for introducing a snoopers charter this kind of thing really interests me.
Encrypting the content of your messages will do nothing to prevent people from getting the information available to them under the snoopers charter.
Also, check out their site at http://openpgpjs.org/
Would it not be possible to develop a 'client' node.js application with this library?
I mean, node.js is all the rave out there for severs but surely you can use it in (so to say) bundled client apps?
Please: correct me, for I may be wrong (I have _no_ idea of node.js) but it does not sound like 'nuts' to me. Just another language, another runtime, another PGP library. Download once, run whenever you need it.
I am not well-versed in the issue, but I have read the infamous Masanto cryptography in JS article, rebuttals, differents JS projects revolving around cryptography.
I currently am evaluating Firefox's WebPG for some functionality, but the dev has to work hard to basically build a Firefox plugin (in JS, so we are back to the same problem) to call GnuPG calls and return the data.
So, we have browser specific plugins and web-app code in a language that is controversially unsuitable for such use in decryption cases. What can we use as alternative to secure web applications? Does asm.js change anything? As far as I can tell, no. Alternative browser languages? I guess, but still a pain. Are we going to have to build this functionality into web browsers, as a standard or otherwise. I am generally curious what people who are trying to engage this problem see in the future.
Build a portable version of Firefox onto a flash drive.
Plug in drive, open up that Firefox
In the local storage of ff-USB is my private key password protected
Now bring up the web page, sign the json message irrevocably and post it back. One button click
The risks of malicious cross site scripting is huge here. But that's the main use case afaik
I can get you to encrypt data with your public key before I upload it to my server. If the cops ever come to _me_ asking for your data, I can say "Sure! Here's the pgp encrypted blob. Sorry, I never get to see the unencrypted data." (Unfortunately, as per xkcd #538, they'll then just hit me with a $5 wrench until I send you a version of the OpenGPG javascript that bypasses the encryption step…)
Webmail for reading and decrypting emails.
Creating "Real" private communication in social networks.
Signing comments in news websites, and on-the-fly verification.
Verify/provide identity across several non-connected social networks.
On-the-fly verification of software packages in repositories like github.
Potentially making Web-of-trust easier to use and expand.
And that is for technologies already in existence as current web-browser plugins. Securing future API's as suggested in this comment thread sound also very interesting.
Encryption in GMail and maybe other webmails for chrome/chromium. It is surprisingly secure (see http://www.mailvelope.com/blog/security-audit-and-v0.6-relea... ) and super easy to use.
It doesn't support signing and signature verification though.