top | item 2652863

My weekend project - AES encryption for Gmail or anything else

152 points| eran | 15 years ago |encipher.it | reply

67 comments

order
[+] moe|15 years ago|reply
Wouldn't it make more sense to revive FireGPG[1] and, while you're at it, port it to all other major browsers?

I am still disappointed that PGP in the browser never gained traction. Not only would it help with e-mail security, it could also be used for passwordless website logins, portable web identities, all that jazz[2].

One proper, user-friendly browser plugin could put an end to all those nasty kludges called OAuth, OpenID, LastPass, etc...

[1] http://getfiregpg.org/s/home

[2] http://en.wikipedia.org/wiki/Web_of_trust

[+] Inufu|15 years ago|reply
I'm currently working on this. So far, recognition of encrypted text and decryption works fine. However, it breaks Gmail if the text is part of an email there - only reloading get's it to work again.

Since I have zero experience with JS, I'm thankful for any help. Code is on: https://github.com/Mononofu/CryptoChrome

The plugin I'm using was compiled on Ubuntu x64 and probably doesn't work anywhere else. It was written using firebreath, basically it's just a wrapper to gpg.

[+] IgorPartola|15 years ago|reply
Are there any webmail providers out there that support PGP? GMail never will since it needs the ability to read your email to show you ads.
[+] jgrahamc|15 years ago|reply
Your key derivation function is pretty weak. Looking at your code you are doing SHA256(password entered by user). You should take a look at using http://en.wikipedia.org/wiki/PBKDF2 for the key derivation. SHA256 is really fast and given that you are getting entropy from some user entered password (which is likely to be badly chosen) you want something _slow_ to derive the key. Hence PBKDF2 with lots of iterations.
[+] eran|15 years ago|reply
Thank you point me out. Definitely, I need to implement PBKDF2 (and add salt to password). I planning this, but weekend is too short and finally I just put SHA256 for key derivation. But, until you describe, I do not recognize what the principal difference between hash and password based key derivation function, thanks.
[+] eran|14 years ago|reply
Today I've updated key derivation to use pbkdf2 (1000 cycles, google chrome execution time around 2 sec)
[+] pixdamix|15 years ago|reply

    javascript:(function(){document.body.appendChild(document.createElement('script')).src='http://encipher.it/javascripts/inject.js';})();
You should consider moving to https. After all, what's the point in providing this kind of script if anyone can MITM it ?

Besides that, this is pretty cool. Could you provide a standalone bookmarlet which doesn't need to download any scripts ?

[+] tptacek|15 years ago|reply
He'd also need to HTTPS all the scripts that script requires, and devise some way to ensure that the script was never called from a page that itself included any HTML or JS over a non-HTTPS connection, because any of those document loads could also MITM the script. Isn't Javascript crypto fun!
[+] eran|15 years ago|reply
Yes, I will install ssl cert in future (at least self signed), understand the risk. Standalone bookmark is great idea, but I am not sure if I can fit script to 2048 bytes. Maybe, I'll make html5 cache manifest to avoid network access.
[+] eran|15 years ago|reply
MITM issue fixed, all resources are loading over SSL
[+] agentultra|15 years ago|reply
While I won't point out the technical reasons why encryption is hard, I will say that I think this project is cool.

I think encryption is something more people might use if it were accessible.

But it's hard enough as it is without making it so easy that Joe Sixpack could use it -- especially since implementations as we know it require Joe Sixpack to understand what he's doing or else the encryption fails.

However, tools like this at least give us prototypes for ideas that could one-day bridge the gap.

Good job, dude. Hope you stick with it and find a way to make it better.

[+] Shenglong|15 years ago|reply
I found your "Joe Sixpack" reference extremely comical.
[+] Erwin|15 years ago|reply
Note that Gmail automatically saves your draft as you type it. So while this will offer some protection for the message while it's in transit from Google's server to your destination, your unencrypted message draft will still be sent to Google's servers (and given Google Apps' distributed architecture, I'm not sure you can determine where that unencrypted copy could end up or when it'd be erased).

Perhaps a way around that could be to enhance a text input field so that only the final encrypted message is written to it, so Google's app does not see the plain text.

[+] niels_olson|15 years ago|reply
Firegpg used to support disabled drafts
[+] Ixiaus|15 years ago|reply
I feel like this would be better as a browser extension instead of a bookmarklet... I get a bit queasy about the potential for MITM with this implementation. An extension that could bring GPG to the mix, would be VERY awesome (if that doesn't exist, I actually haven't tried searching for that...).

Cool project though :)

[+] jrockway|15 years ago|reply
Who are you protecting the message from when you do this? Gmail? But they can just send the cleartext to the server before you click "encrypt it", and in fact they do (drafts).

Don't type stuff into a program you didn't write if you don't want the author to see it.

[+] woodall|15 years ago|reply
>Weekend project

>encryption

Choose one.

[+] hollerith|15 years ago|reply
Also: "Browser-based." "Secure." Choose one.
[+] megamark16|15 years ago|reply
This is great, I was just thinking the other day that it should be possible to encrypt gmail messages. Now you should make it possible to encrypt GChat messages automatically when I hit Send, and then decrypt them when they are received, that way they are encrypted end to end, instead of just between my browser and the server :-)
[+] zitterbewegung|15 years ago|reply
Thats pretty neat since you have of the encryption done client side. Which mode of AES do you use?
[+] eran|15 years ago|reply
I use counter mode with 256 bit key Key is generated as sha256 hash of the user password
[+] sweis|14 years ago|reply
This implementation is broken. It concatenates a hash of the plaintext to a CTR-mode ciphertext. That's weakly authenticated and leaks information about the plaintext.

It would be better to HMAC the ciphertext with a second key value.

[+] eran|14 years ago|reply
Fixed. Thank you for advice about HMAC, now I am use it.
[+] js4all|15 years ago|reply
This is interesting, but s/mime is the proper way to encrypt and/or sign emails.

I am not sure though, if it is possible to create a multipart message using JavaScript in gmail.

[+] nopassrecover|14 years ago|reply
I'm pretty amateur on cryptography, and this is cool and everything for basic security, but for those more in the know does the fact that the algorithm knows a password is "wrong" weaken the cryptography (I realise it's a cool feature of this app, I'm talking generally)? Presumably you would have to test each decrypted result for language words etc. otherwise to know if you had decrypted it correctly.
[+] yan|14 years ago|reply
Or prepend a known header to the plaintext you're encrypting..
[+] e-dard|15 years ago|reply
This is neat. Would it be possible to extend it such that you could drop a key file into the password box to do the encryption/decryption?
[+] eran|15 years ago|reply
Sure, but on modern browsers only (utilizing html5 file API). I am thinking about implementing RSA private key generation and online public key registry in future.
[+] mtogo|15 years ago|reply
Hmm, testing it out it constantly confuses weather it should be encrypting or decrypting. I've tried to enter a message and had it request a decryption password.

That combined with the poor crypto practices makes it rather unusable, but it's a fantastic concept! Just needs a bit of work.

[+] antihero|15 years ago|reply
This is an awesome way of doing things. I'm going to be doing a slightly different implementation of this for my WIRE project on the advice of a bunch of people (more intense key differentiation, for a start), but it's good to know people are starting to do this :)
[+] antihero|14 years ago|reply
Edit: Just finished implementing this using the Stanford library - check it out (non-SSL test site) http://wire.0xf.nl
[+] fduran|15 years ago|reply
This tool is interesting and the page has a nice design.

I also created recently a weekend project based on client-side encryption: https://whisperpassword.com , I need to learn about design though ;-)