Simplified workflow - even across organisation boundaries
An invoice is sent, and if the line manager and their line manager approve the invoice gets paid
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…)
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.
If anybody uses this, please keep in mind the differences in security possibilities between native C code and Javascript.
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.
Thank you for saying it. I find it dangerous to let users believe their data is secure, when the in-js encryption is everything but. It may lead to all sorts of misunderstandings and litigation issues...
This is not a PGP library. It's a wrapper around gpgme, which in turn is a wrapper around gnupg. node-gpg just exposes the GnuPG command line as javascript functions.
And nodejs is not a javascript server, it's just a wrapper around V8 and the kernel's socket API? Linux is not an operating system kernel, it's just a wrapper around X86?
Nothing is anything. We're all just subatomic particles destined for heat death
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 a problem I am interested in a lot, and is perhaps the only reason I cannot completely move away from dedicated email clients on my computer.
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.
I really hope this takes off, there have been several efforts to bring PKS & PKE to the browser than have unfortunately just withered & died.
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.
Sigh, the comments on this page are abysmal. Since no one has shouted the (correct) party line yet: DON'T USE CRYPTOGRAPHY IN THE BROWSER.
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.
There are circumstances where you can trust the host. For example if you run it yourself. I myself would like to run a self-hosted gmail clone if I can find a decent one.
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.
That is a true point :) But keep in mind that there is something to be said for not storing encrypted data on the same machine as the key.
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.
If JS sent by server has access to your key, then by that proxy the server has access to the key too. The security is equivalent to having key stored in encrypted form and decrypted only for the duration of the session/use and the password not being stored on the server.
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.
"Chances are good that you have more control over the computer you type your messages on than some server"
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.
You appear to threat trust as something binary; either you trust a host or not? In my world trust (as well as security in general) is always a spectrum, or something more multidimensional; that you trust various host to different degrees, in different way against different threats.
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.
One example could be indemnification of the host. A host honestly doesn't want to be a target of subpoena for a data that some users put there. So the host honestly says: sorry, all the data is encrypted and we don't have passwords for it, only the users have them. So we have no idea what's there and can't give you anything useful.
Yeah. I don't understand why people don't get this. SSL already provides end to end encryption with the server. The only issue is you have to trust the server. That said, any JS that gets downloaded to the browser for execution has the same exact issue.
We can all agree that running PGP in the browser is sub optimal for a whole host of reasons.
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.
Why haven't signed browser plugins been mentioned yet? They significantly aid with the problem of code delivery.
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.
There seems to be a certain irony here that the recent "doing cryptography in the browser with JavaScript is a bad idea" articles seems to have spurred people's interest in doing just that! It's almost like the Streisand effect. Oh well.
Please: have fun playing with your toy crypto systems. Enjoy making and breaking them. Use it for learning how to implement stuff, and where the difficulties are in implementing secure crypto. Perhaps even use them if your security needs are mild.
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.
There is something I do not get. Everybody complaining about 'do not use this is the browser' but...
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.
node.js doesn't run in the browser. It's typically a server side application. And, yes, I think most would agree that node.js might be one of the few valid use cases for this.
Except this library doesn't have proper memory protection, and node.js has system access so it could just use GnuPG and be a lot more secure (and almost certainly faster, too).
43 comments
[ 1.8 ms ] story [ 99.9 ms ] threadAlso, check out their site at http://openpgpjs.org/
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.
http://www.mailvelope.com/
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.
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:
http://news.bbc.co.uk/2/hi/americas/328442.stm
(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'"
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.
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.
(http://www.bbc.co.uk/news/uk-northern-ireland-20677850)
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.
http://log.nadim.cc/?p=33
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.
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.