I thought this article was interesting because the author talked about how encryption can be used to "delete" data from distributed systems instantly, by just removing the key.<p>Not really a new idea, I don't think, but not one that gets surfaced much when people talk about client-side crypto.
Two projects for client-side encrypted cloud data:<p><a href="https://css.csail.mit.edu/mylar/" rel="nofollow">https://css.csail.mit.edu/mylar/</a><p><a href="https://css.csail.mit.edu/cryptdb/" rel="nofollow">https://css.csail.mit.edu/cryptdb/</a><p>Microsoft also released a homomorphic encryption project for bioinformatics last week:<p><a href="http://research.microsoft.com/apps/pubs/default.aspx?id=258435" rel="nofollow">http://research.microsoft.com/apps/pubs/default.aspx?id=2584...</a>
Client side encryption is definitely the way to go, soon enough computation will become possible on the encrypted data. Maybe there will be homomorphically encrypted virtual machines/ containers.
I wrote a client-side encryption library for the communication part of the equation:<p><a href="http://stringphone.readthedocs.org/" rel="nofollow">http://stringphone.readthedocs.org/</a>
I keep wondering: Browsers have been dealing with some of these issues for quite some time now, both for SSL purposes and password storage. They should agree on common interfaces to expose safe crypto functions to client code, so that users could be relatively sure that servers will never get, say, a plaintext password. Is it terribly hard?<p>It would likely be safer than hamfisted attempts at JS cryptography which can be compromised down the wire.
I don't worry so much about encryption, since I am really not into keeping secrets, but I agree about the client-side part.<p>...and now a brief word from our corporate sponsors...<p>Haha, not really :) I'm just trying to get the thing that I've been working on "out there". It's an operating system that runs in a web browser. How's that for client-side awesomeness? The current project I'm hawking is called "The Native Client Proving Ground", in order to get people to see the inherent awesomeness of running arbitrary computational logic on the client. So yeah, encryption is definitely do-able, though not extremely interesting IMO.<p>I posted this here a couple days ago, and actually got it onto the front page for a brief minute. So fire up your Chrome browsers and check out the infinite potential that exists on the client-side: <a href="https://nacl-pg.appspot.com/desk?intro=the-shaker" rel="nofollow">https://nacl-pg.appspot.com/desk?intro=the-shaker</a><p>If you didn't know, Native Client (NaCl) is the plugin architecture for Chrome so you can run arbitrary C/C++ code inside of a sandboxed runtime.<p>Join the revolution!
Writing Go code, I've always been frustrated at how writing code to encrypt/decrypt data always felt like brain surgery using the standard libraries. I wrote a simple library around NaCL's secretbox that has a very simple user-friendly interface, while (hopefully) also being secure.<p><a href="https://github.com/ereyes01/cryptohelper" rel="nofollow">https://github.com/ereyes01/cryptohelper</a><p>As far as the secure part, I'd appreciate eyes on the code (which there isn't a whole lot of) to verify this works well. This library could also possibly be enhanced to support other encryption methods, such as AES. An easy interface with sensible defaults to Go's AES interfaces would be nice.
It's interesting that the very security minded disable javascript in their browser for security reasons, which makes most client-side crypto not possible.