Hello :-)
I've been working on implementing OpenPGP.js in Roundcube for the past couple of days. It's still an unfinished project in development, but since there's such high demand for the result I ought I'd ask you guys for some early feedback.
For those of you who don't know: OpenPGP.js is a fork of the previous GPG4Browsers. The intent is to port all OpenPGP functionality into JavaScript so that third party software isn't required for PGP activity. It uses HTML5 web storage and standard PKI keyrings (private keys excluded).
So far the plugin, rc_openpgpjs, has a "temporary"(?) user interface for key management and selection. Its consciously using a pretty rough UI at the moment because the new design for Roundcube is just around the corner, but just not finished enough yet to start working on. Also the Enigma plugin interface looked in trouble in Larry.
Speaking of Enigma: I'm sure someone will ask why I extend that instead. With all due respect to its authors and fans, Enigma has been stuck in development for 2 years, and PGP support has been planned for Roundcube for 6 years. I'm not sure whether Enigma is really relevant or not. Also I can not support a plugin that implements encryption as a server side solution. The main goal of encryption is to ensure that the data can not be accessed by unauthorized people. I believe that people hosting other people's mail should be treated as unauthorized, and giving private keys away to somebody else really fights against the entire purpose. And then arises the exact same problem that Hushmail users are experiencing: http://www.wired.com/threatlevel/2007/11/encrypted-e-mai/
Even though most Roundcube users probably host their own email I'm quite sure most people don't have problems with a client sided solution instead. That said, I'm not opposed to the Enigma plugin in any way. I was only too lazy to bother learning its structure and layout, which turned out to not be entirely supported by the Larry design. I wouldn't mind a merge later on.
Anyhow! Check it out, and tell me what you think. I strongly welcome UI recommendations, patches or any other tip about how I should progress. It's still in early development, but most of the key management features are implemented and so is the decryption of emails. Nothing about the UI is finished.
https://github.com/qnrq/rc_openpgpjs
Cheers!
/Nik
On Sat, Jun 30, 2012 at 5:34 PM, Niklas nik@qnrq.se wrote:
Hello :-)
Hi Nik
I've been working on implementing OpenPGP.js in Roundcube for the past couple of days. It's still an unfinished project in development, but since there's such high demand for the result I ought I'd ask you guys for some early feedback.
For those of you who don't know: OpenPGP.js is a fork of the previous GPG4Browsers. The intent is to port all OpenPGP functionality into JavaScript so that third party software isn't required for PGP activity. It uses HTML5 web storage and standard PKI keyrings (private keys excluded).
Interesting approach indeed!
So far the plugin, rc_openpgpjs, has a "temporary"(?) user interface for key management and selection. Its consciously using a pretty rough UI at the moment because the new design for Roundcube is just around the corner, but just not finished enough yet to start working on. Also the Enigma plugin interface looked in trouble in Larry.
Speaking of Enigma: I'm sure someone will ask why I extend that instead. With all due respect to its authors and fans, Enigma has been stuck in development for 2 years, and PGP support has been planned for Roundcube for 6 years. I'm not sure whether Enigma is really relevant or not.
It's stalled due to lack of time as well as technical and conceptual issues. One of the conceptual questions was whether to store the private keys on the server or not...
Anyhow! Check it out, and tell me what you think. I strongly welcome UI recommendations, patches or any other tip about how I should progress. It's still in early development, but most of the key management features are implemented and so is the decryption of emails. Nothing about the UI is finished.
After a first run, I didn't fully understand what the plugin can do. I tried to import my private key but it didn't appear in the list nor did I get an error message or whatnot. When looking at the code, I don't yet see actual encryption/decryption of mail contents. Or did I miss something? Speaking of decryption, this is where the client side approach will make things pretty complicated. It might work for simple plain text messages but once an entire multipart message with attachments needs to be decrypted, we'd also need mime parsing functionality implemented in javascript and the entire message has to be transferred from the IMAP server vis the Roundcube webserver to the client. We'd need a full client side implementation of message parsing and file handling. Not that this is entirely impossible but a huge amount of work and be expected.
However, I'm willing to help you with the implementation of a Roundcube plugin. For now here are a few suggestions:
- Move the key management stuff to the settings task. I'd suggest to
add another tab/section similar to the password or filters plugin.
- Hook into the 'message_part_structure' plugin hook to make sure
encrypted message contents will make it to the html output. See enigma plugin for reference.
- Add some UI elements to sign/encrypt outgoing messages.
More to be added...
Best, Thomas
Hey-hey!
The key manager uses HTML5 web storage to store keys, perhaps your browser doesn't support it yet? I've confirmed that part to work in both Firefox and Chrome. The plugin is heavily depending on HTML5 and things like window.crypto, which Chrome currently supports but Firefox is lagging (for some reason they're holding the release back because it's not finished for the mobile app).
Decryption works as a proof of concept currently and currently it can only decrypt using one (the first) private key in the key manager. The decryption function is on rows 275-334 here: https://github.com/qnrq/rc_openpgpjs/blob/master/js/openpgpjs.js
I see what you mean about message parsing being a big project to get working somehow on the client side. I can't say that I'm looking forward to that part, but for now the most important thing imho is to get any PGP safely into Roundcube. It might be something that requires patching openpgp.js and that's fine by me, I've already planned doing modifications there.
I think it's OK if it takes some time to get full multipart messaging support. Browsers haven't implemented HTML5 fully yet so either what is done with the plugin it won't function 100 % until things like that are ready.
This is what I have in mind before releasing it as a beta (besides what's already slightly working):
- Move key management to settings as you suggested (at this stage it's
nice to have it all in my face for easy debug)
- Create key select that spawns pre-decryption (same window as where the
user enters the passphrase) if the user has several private keys
- Easy import-export functionality of data stored in the HTML5 web
storage (I know openpgp.js was looking at cryptostick support, not sure how that's going for them)
- Encryption function (missing entirely)
- Verification after decryption (depends on PKS support)
- Public key server connection*
- According to the specification and the implementations I've tried the
PKS sends and receives traffic through HTTPS. This creates two problems:
- theoretically possible to alter data (MITM) and 2) an attacker with
access to the clients network traffic knows whose keys the user is requesting or which keys are being submitted, which would decrease anonymity even when SMTP servers use TLS between each other. My solution is to write a PHP proxy that the JavaScript parts of the plugin can communicate with for PKS activity (retrieving and adding). This way users of Roundcube installations on HTTPS have anonymized PKS traffic and users on HTTP are unaffected. Hopefully everybody runs Roundcube on HTTPS.
Once again, if this project takes very long time to develop, I wouldn't really mind. I'd rather take long time than get in the same classical paradox with private keys and crypto calculations on the server instead of the client as so many others :-) I don't mess with backdoors. And hopefully plugin users agree with the philosophy of releasing early and releasing often and don't spam me too much about multipart support :-D
Thanks a lot for your input, I really appreciate it!
Regards, Nik
On 7/11/12 9:11 PM, Thomas Bruederli wrote:
On Sat, Jun 30, 2012 at 5:34 PM, Niklas nik@qnrq.se wrote:
Hello :-)
Hi Nik
I've been working on implementing OpenPGP.js in Roundcube for the past couple of days. It's still an unfinished project in development, but since there's such high demand for the result I ought I'd ask you guys for some early feedback.
For those of you who don't know: OpenPGP.js is a fork of the previous GPG4Browsers. The intent is to port all OpenPGP functionality into JavaScript so that third party software isn't required for PGP activity. It uses HTML5 web storage and standard PKI keyrings (private keys excluded).
Interesting approach indeed!
So far the plugin, rc_openpgpjs, has a "temporary"(?) user interface for key management and selection. Its consciously using a pretty rough UI at the moment because the new design for Roundcube is just around the corner, but just not finished enough yet to start working on. Also the Enigma plugin interface looked in trouble in Larry.
Speaking of Enigma: I'm sure someone will ask why I extend that instead. With all due respect to its authors and fans, Enigma has been stuck in development for 2 years, and PGP support has been planned for Roundcube for 6 years. I'm not sure whether Enigma is really relevant or not.
It's stalled due to lack of time as well as technical and conceptual issues. One of the conceptual questions was whether to store the private keys on the server or not...
Anyhow! Check it out, and tell me what you think. I strongly welcome UI recommendations, patches or any other tip about how I should progress. It's still in early development, but most of the key management features are implemented and so is the decryption of emails. Nothing about the UI is finished.
After a first run, I didn't fully understand what the plugin can do. I tried to import my private key but it didn't appear in the list nor did I get an error message or whatnot. When looking at the code, I don't yet see actual encryption/decryption of mail contents. Or did I miss something? Speaking of decryption, this is where the client side approach will make things pretty complicated. It might work for simple plain text messages but once an entire multipart message with attachments needs to be decrypted, we'd also need mime parsing functionality implemented in javascript and the entire message has to be transferred from the IMAP server vis the Roundcube webserver to the client. We'd need a full client side implementation of message parsing and file handling. Not that this is entirely impossible but a huge amount of work and be expected.
However, I'm willing to help you with the implementation of a Roundcube plugin. For now here are a few suggestions:
- Move the key management stuff to the settings task. I'd suggest to
add another tab/section similar to the password or filters plugin.
- Hook into the 'message_part_structure' plugin hook to make sure
encrypted message contents will make it to the html output. See enigma plugin for reference.
- Add some UI elements to sign/encrypt outgoing messages.
More to be added...
Best, Thomas _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
On Wednesday 11 July 2012 17:00:42 Niklas wrote:
I'd rather take long time than get in the same classical paradox with private keys and crypto calculations on the server instead of the client as so many others :-)
I fully agree and really like your approach! :)
Good luck and many thanks for working on that!
Regards, Torsten
On Wed, Jul 11, 2012 at 5:00 PM, Niklas nik@qnrq.se wrote:
Hey-hey!
The key manager uses HTML5 web storage to store keys, perhaps your browser doesn't support it yet? I've confirmed that part to work in both Firefox and Chrome. The plugin is heavily depending on HTML5 and things like window.crypto, which Chrome currently supports but Firefox is lagging (for some reason they're holding the release back because it's not finished for the mobile app).
I tried with Chrome and importing public keys worked fine. Nevermind, I guess the problem was somewhere between the chair and the keyboard :-)
BTW: as far as I understand HTML5 local storage, the key store is restricted to the host/domain of the Roundcube installation. Of course that's a reasonable security feature. But it also means that I'd have to install my keys at every website using openpgpjs individually, right?
Decryption works as a proof of concept currently and currently it can only decrypt using one (the first) private key in the key manager. The decryption function is on rows 275-334 here: https://github.com/qnrq/rc_openpgpjs/blob/master/js/openpgpjs.js
I see what you mean about message parsing being a big project to get working somehow on the client side. I can't say that I'm looking forward to that part, but for now the most important thing imho is to get any PGP safely into Roundcube. It might be something that requires patching openpgp.js and that's fine by me, I've already planned doing modifications there.
I recently found http://gpg4browsers.recurity.com which actually heads into that direction.
I think it's OK if it takes some time to get full multipart messaging support. Browsers haven't implemented HTML5 fully yet so either what is done with the plugin it won't function 100 % until things like that are ready.
That's certainly true. But as always, users want that feature ASAP...
Yeah, the keys will have to be imported for every individual site using openpgpjs. I'm not very concerned about that, I think the users are more than willing to import keys everywhere. I think that's just normal usage of PKI, kind of how SSH users would have to put all their public keys on remote hosts.
One thing related to this that I haven't looked into though is: how persistent is the HTML5 web storage, and when and under what circumstances does it expire? It would suck to have to import private keys from a local storage once a day. Perhaps if that becomes a problem later on JavaScript cookies could be used as backup. But once again, I haven't looked at this at all, and it might not be a problem at all.
OpenPGP.js is actually a fork of GPG4Browsers :-)
Regards, Nik
On 7/12/12 10:19 PM, Thomas Bruederli wrote:
On Wed, Jul 11, 2012 at 5:00 PM, Niklas nik@qnrq.se wrote:
Hey-hey!
The key manager uses HTML5 web storage to store keys, perhaps your browser doesn't support it yet? I've confirmed that part to work in both Firefox and Chrome. The plugin is heavily depending on HTML5 and things like window.crypto, which Chrome currently supports but Firefox is lagging (for some reason they're holding the release back because it's not finished for the mobile app).
I tried with Chrome and importing public keys worked fine. Nevermind, I guess the problem was somewhere between the chair and the keyboard :-)
BTW: as far as I understand HTML5 local storage, the key store is restricted to the host/domain of the Roundcube installation. Of course that's a reasonable security feature. But it also means that I'd have to install my keys at every website using openpgpjs individually, right?
Decryption works as a proof of concept currently and currently it can only decrypt using one (the first) private key in the key manager. The decryption function is on rows 275-334 here: https://github.com/qnrq/rc_openpgpjs/blob/master/js/openpgpjs.js
I see what you mean about message parsing being a big project to get working somehow on the client side. I can't say that I'm looking forward to that part, but for now the most important thing imho is to get any PGP safely into Roundcube. It might be something that requires patching openpgp.js and that's fine by me, I've already planned doing modifications there.
I recently found http://gpg4browsers.recurity.com which actually heads into that direction.
I think it's OK if it takes some time to get full multipart messaging support. Browsers haven't implemented HTML5 fully yet so either what is done with the plugin it won't function 100 % until things like that are ready.
That's certainly true. But as always, users want that feature ASAP... _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
Hello,
I'm really happy to see PGP/GPG support in roundcube progressing ;)
Am 30.06.2012 17:34, schrieb Niklas:
I've been working on implementing OpenPGP.js in Roundcube for the past couple of days. It's still an unfinished project in development, but since there's such high demand for the result I ought I'd ask you guys for some early feedback.
For those of you who don't know: OpenPGP.js is a fork of the previous GPG4Browsers. The intent is to port all OpenPGP functionality into JavaScript so that third party software isn't required for PGP activity. It uses HTML5 web storage and standard PKI keyrings (private keys excluded).
It sounds like a interesting implementation.
Speaking of Enigma: I'm sure someone will ask why I extend that instead. With all due respect to its authors and fans, Enigma has been stuck in development for 2 years, and PGP support has been planned for Roundcube for 6 years. I'm not sure whether Enigma is really relevant or not. Also I can not support a plugin that implements encryption as a server side solution. The main goal of encryption is to ensure that the data can not be accessed by unauthorized people. I believe that people hosting other people's mail should be treated as unauthorized, and giving private keys away to somebody else really fights against the entire purpose. And then arises the exact same problem that Hushmail users are experiencing: http://www.wired.com/threatlevel/2007/11/encrypted-e-mai/
I agree that in most situations users shouldn't trust their ISPs. At least they shouldn't give them private keys. But in other cases it's actually the other way round: If people host their own webmail, and have full control over the server hosting it, it might be much safer to store a passphrase-encrypted subkey on this server than to import the secret key into browser cache on public internet clients. The great thing about server-side key storage is, that the secret key never leaves the server.
I actually see good reasons for both implementations. But the best would be to merge both as much as possible and keep code / function duplications small.
Regards, jonas
-
Jonas Meurer -
Niklas -
Niklas Femerstrand
-
Thomas Bruederli -
Torsten Grote