[riquito]

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]

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.

[jarrett]

My biggest hesitation here is that you're still trusting the server. Which, not coincidentally, has always been one of the biggest objections to JS crypto. That is, if the server is compromised, it can serve malicious JS, and it can just as easily steal any data that's being encrypted server-side.

To me, one of the most important things about PGP is that the plaintext and the encryption process are entirely in your control. (At least to the extent that you control your own computer.) You lose that assurance if you do server-side encryption.

[riquito]

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]

"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

[Joeboy]

> 5. The web app's client sided code, JavaScript, sends the message to Alice's pygpghttpd listening on localhost

So either you're trusting the web app's js, or there's some other unspecified mechanism for ensuring that it's behaving in a trustworthy way.

[calgoo]

They just released a pgp for js. I was thinking of making a IM using it: http://openpgpjs.org/