11 ms·

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 mysel

• jakejake 13y ago
  Allow me to pimp my own lib which might be useful since roundcube is PHP: https://github.com/jasonhinkle/php-gpg https://github.com/jasonhinkle/php-gpg I'm working on encryption and signing as well. Key generation would be nice as well. I need a little help with it though.
  • 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.
• riquito 13y ago
  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 level encryption.
  • qnrq 13y ago
    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.
    • riquito 13y ago
      Maybe I misinterpreted. 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?
      • qnrq 13y ago
        "Didn't you just loose the security that you wanted by encrypting on localhost?" No, the sensitive information isn't being protected from localhost but from server A and anything else on the path between user and message destination. localhost is the user. For clarification: GPG is on user's localhost, not the server. 1. Alice uses a web app served by server A 2. Alice wishes to send an encrypted message through the web app served by server A to Bob 3. Alice writes the message on her client sided browser 4. Alice finishes and clicks "Send" 5. The web app's client sided code, JavaScript, sends the message to Alice's pygpghttpd listening on localhost 6. pygpghttpd responds with the ciphertext to Alice's web browser 7. Alice's web browser replaces the cleartext content with the encrypted content 8. The encrypted content is sent to server A to be routed to Bob --------------- 1. Bob receives encrypted message from Alice on web app served by server 1 2. Web app's client sided JavaScript sends the encrypted message to Bob's pygpghttpd listening on Bob's localhost 3. pygpghttpd responds with the decrypted message 4. The decrypted message is rendered for Bob