7 ms·

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 add

by 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.

deleted 13y ago
[deleted]
bigiain 13y ago
Given that practically all (to at least 4 significant digits) of my mail arrives at the mail server un-encrypted,I think there's still some value in encrypting it before the server stores it. I'm setting up some perl scripts to help exim encrypt to my public key any non-encrypted mail before it delivers it into the local mailbox. That's still subvert-able by anybody with enough power to lean on the hosting company, but then all that mail was interceptable in transit anyway - at least I've made sure that stored archives on the hosted server aren't in cleartext. I'm also considering setting up some scripts for outbound mail - to automatically encrypt any (non-encrypted) mail I send if I've ever received encrypted mail from the recipient. Have the mail server keep a record of email addresses and public keys, and auto encrypt where possible. (And in regards to in-browser crypto - I'm unsure there are strong enough guarantees of security in javascript to make me entirely comfortable having my private keys and passphrases hanging around in the process space where rogue javascript and/or plugins might be able to scoop them up…)
- qnrq 13y ago
  That's a valid point, but you won't be effectively encrypt incoming email in the layer of a webmail client. You'd be better off incorporating that before the message is even saved to disk - in the mail delivery of your MTA. So once again it wouldn't be PHP (I hope for your sake!). "(And in regards to in-browser crypto - I'm unsure there are strong enough guarantees of security in javascript to make me entirely comfortable having my private keys and passphrases hanging around in the process space where rogue javascript and/or plugins might be able to scoop them up…)" Your sarcasm is entirely valid, but you didn't actually look at the project that you are criticizing. The entire point of what I linked in my comment is that nothing critical should be exposed to the JavaScript, just an API that it can interact with to send commands to: such as keygen, verify this message, send cleartext and receive ciphertext in response, etc. You're preaching to a believer here, :-) Your ~/.gpg/ is -not- accessible to JavaScript. The interface, the GnuPG binary, is. That's the point. Now we can both agree that exposing private keys in such an API is a bad idea.
  - bigiain 13y ago
    On the incoming email encryption - yeah, that's in the MTA not the webmail software - having said that, I'm basing what I'm doing off this: https://grepular.com/Automatically_Encrypting_all_Incoming_Email https://grepular.com/Automatically_Encrypting_all_Incoming_E... at least partly because Perl is my goto hack-shit-together langiage, I could _easily_ imagine a lot of my cow-orkers choosing to do that in php. And yeah, I hadn't followed your links, and made poor assumptions about your project. I just briefly skimmed through some of them and I've got a question - have you got a way to protect the passphrase from ending up somewhere the browser can see it? (or, if the decryption is "passphraseless" from the browsers point of view, how do you ensure rogue javascript could pass encrypted data in and retrieve cleartext?)
    - qnrq 13y ago
      The questions that you raise is of course what I am interested in discussing. I can't think of any way that PGP/GPG protects you against keyloggers or a pre-infected computer. I agree that they are relevant threats but my question is if it's up really to the developers to prevent rogue JavaScript in third party software and user's localhost. The same threats can be applied on all existing cryptosystems, as for with one-time pads where someone could look you over the shoulder - but that itself is not considered to break the underlying strength of the design. Or another example, how does Enigmail for Thunderbird protect you against having code injected and keys stolen? I don't think it does, but Enigmail isn't considered insecure. I think the questions are fair to raise but I see them raised far more often when people confront new ideas in comparasion to established practice, which I truthfully consider is a bit unfair judgement. One of the factors which can narrow the scope of attackers is to use products like crypto stick, but then again what is preventing a computer from being rootkitted and having it's keys stolen as soon as they are exposed in the system? Developers can of course only address weaknesses in what they have control over. We can't stop your computer from being infected by neither rootkits nor rogue JavaScript from plugins that you have volontarily installed. My advice would be to be careful and audit everything that may be a threat in order to at least try and minimize the risks. Unfortunately I don't think many users do that but it's not something we as developers can address and prevent. The dilemma here is the same as with filesharing: if it's accessible it can be copied and transferred. There's no patch against that.
jakejake 13y ago
Thanks for the opinion. Good luck implementing your crypto.

by qnrq 13y ago

deleted 13y ago

[deleted]

bigiain 13y ago

Given that practically all (to at least 4 significant digits) of my mail arrives at the mail server un-encrypted,I think there's still some value in encrypting it before the server stores it. I'm setting up some perl scripts to help exim encrypt to my public key any non-encrypted mail before it delivers it into the local mailbox. That's still subvert-able by anybody with enough power to lean on the hosting company, but then all that mail was interceptable in transit anyway - at least I've made sure that stored archives on the hosted server aren't in cleartext. I'm also considering setting up some scripts for outbound mail - to automatically encrypt any (non-encrypted) mail I send if I've ever received encrypted mail from the recipient. Have the mail server keep a record of email addresses and public keys, and auto encrypt where possible. (And in regards to in-browser crypto - I'm unsure there are strong enough guarantees of security in javascript to make me entirely comfortable having my private keys and passphrases hanging around in the process space where rogue javascript and/or plugins might be able to scoop them up…)

qnrq 13y ago
That's a valid point, but you won't be effectively encrypt incoming email in the layer of a webmail client. You'd be better off incorporating that before the message is even saved to disk - in the mail delivery of your MTA. So once again it wouldn't be PHP (I hope for your sake!). "(And in regards to in-browser crypto - I'm unsure there are strong enough guarantees of security in javascript to make me entirely comfortable having my private keys and passphrases hanging around in the process space where rogue javascript and/or plugins might be able to scoop them up…)" Your sarcasm is entirely valid, but you didn't actually look at the project that you are criticizing. The entire point of what I linked in my comment is that nothing critical should be exposed to the JavaScript, just an API that it can interact with to send commands to: such as keygen, verify this message, send cleartext and receive ciphertext in response, etc. You're preaching to a believer here, :-) Your ~/.gpg/ is -not- accessible to JavaScript. The interface, the GnuPG binary, is. That's the point. Now we can both agree that exposing private keys in such an API is a bad idea.
- bigiain 13y ago
  On the incoming email encryption - yeah, that's in the MTA not the webmail software - having said that, I'm basing what I'm doing off this: https://grepular.com/Automatically_Encrypting_all_Incoming_Email https://grepular.com/Automatically_Encrypting_all_Incoming_E... at least partly because Perl is my goto hack-shit-together langiage, I could _easily_ imagine a lot of my cow-orkers choosing to do that in php. And yeah, I hadn't followed your links, and made poor assumptions about your project. I just briefly skimmed through some of them and I've got a question - have you got a way to protect the passphrase from ending up somewhere the browser can see it? (or, if the decryption is "passphraseless" from the browsers point of view, how do you ensure rogue javascript could pass encrypted data in and retrieve cleartext?)
  - qnrq 13y ago
    The questions that you raise is of course what I am interested in discussing. I can't think of any way that PGP/GPG protects you against keyloggers or a pre-infected computer. I agree that they are relevant threats but my question is if it's up really to the developers to prevent rogue JavaScript in third party software and user's localhost. The same threats can be applied on all existing cryptosystems, as for with one-time pads where someone could look you over the shoulder - but that itself is not considered to break the underlying strength of the design. Or another example, how does Enigmail for Thunderbird protect you against having code injected and keys stolen? I don't think it does, but Enigmail isn't considered insecure. I think the questions are fair to raise but I see them raised far more often when people confront new ideas in comparasion to established practice, which I truthfully consider is a bit unfair judgement. One of the factors which can narrow the scope of attackers is to use products like crypto stick, but then again what is preventing a computer from being rootkitted and having it's keys stolen as soon as they are exposed in the system? Developers can of course only address weaknesses in what they have control over. We can't stop your computer from being infected by neither rootkits nor rogue JavaScript from plugins that you have volontarily installed. My advice would be to be careful and audit everything that may be a threat in order to at least try and minimize the risks. Unfortunately I don't think many users do that but it's not something we as developers can address and prevent. The dilemma here is the same as with filesharing: if it's accessible it can be copied and transferred. There's no patch against that.

jakejake 13y ago

Thanks for the opinion. Good luck implementing your crypto.