And if this is supposed to be a generic framework, I think the FAQ should jump straight to the problems inherent in this type of generic solution. For instance "How do we give you sorted results to queries if everything is encrypted?"
The fast and very technical answer is that you get search results on encrypted data by making liberal use of the cheap containers to automatically save indexes as the data is modified. But note how our timeline includes the Object Database having advanced features (save triggers, derived objects like indexes) that do this for you. (Full text search and similar features.)
Note also that we built this in about 3 weeks so it's minimal, but will grow fast. See the timeline section on the site.
For code examples, look in the GitHub checkout under client/examples. For understanding the server's data structures, look at server/lib/stores/postgresql/setup.sql.
Thanks for your interest!
That's nice to read: I ended up with that for an application I'm responsible for. I was pleased with what I came up with, but it's one of those things where end users think something like "oh, huh, nice, you can finally do search on this site", but they don't have any idea how difficult it is!
I know this because I designed such a scheme and it was hilariously, fantastically broken.
Cryptocat moved away from delivering its crypto code over JS to a browser plugin:
Do you think a dedicated native client would work? Something like a lightweight site-specific browser with Crypton libs. The same way you can appify sites with Chrome.
I designed my protocol so that it needn't be embedded in the browser at all -- or for that matter, piggybacked on HTTP.
You can use an Object DB like a key value store, but there's a much richer feature set available.
You can also share objects securely with other users of the application for building multi user collaborative apps.
53 Bluxome Street, San Francisco, from 7 to 10 tonight. Come by if you like. We're cohosting the event with Phil Zimmerman and the Silent Circle team.
For my honours project I developed a scheme for tracking users as they visited websites, with a design goal that I, with the tracking servers, can identify users -- but that publishers cannot. Or at least, they can't by intercepting anything sent as part of the tracking protocol.
This particular problem totally breaks the design I came up with. I didn't realise it at the time. Luckily there's no requirement to submit a secure protocol to get good marks, so I got a degree anyhow.
Subsequently I rewrote the tracking protocol multiple times, each time sending it for review by A Well Known Crypto Expert You've Heard Of. Each time he would pick holes in it. This went on for about 3 months. After this long process I managed to arrive back at a protocol that meets my original goals: track users without revealing to publishers who they are (unless the user wants their identity to be revealed). It's currently sitting in Geneva somewhere, waiting for a patent examiner to take a look.
Edit: Wait, that sounds kinda threatening out of context. It's not meant to be. Crypton has a very different use case in mind from me.
The one I chose is called "the PCT process". It costs more upfront, but it gives you more flexibility with timing. Under the PCT process you can opt to file directly with WIPO in Geneva.
I was lucky to find a lawyer with a computer science background who has an interest in startup entrepreneurship.
For a good (though hastily assembled) example of a client-side demo, check out https://github.com/SpiderOak/crypton/tree/master/client/exam...
More detail about this sort of "unhosted" architecture:
But unlike Crypton, in remoteStorage you have to trust your storage provider because it can access all the app data.
Crypton is an entirely new project in early stages. It's not production. It hasn't had any security review. We only started it a few weeks ago.
We have encountered subtle problems with the CryptoJS API, and we plan on giving back and writing a JS crypto library using the lessons we've learned from this project.
It looks like there will be no CFB in sjcl:
EDIT: And jsrsasign:
From what I can gather from this link they are just concentrating on encrypting the data stored in something like S3, and having an application that you've developed handle the decryption/encryption.
IMO, the right way to do hostproof is some combination of trusted computing (HSMs, TXT, etc.), protocols which can prove things clearly but not keep them confidential (like bitcoin -- something which used certifications to prove source code hasn't been altered and compiles to the binary you're talking to would be a great leap forward), special-cases of homomorphic crypto, and client side execution (either all the time, or for some statistically significant subset of operations, to catch cheaters eventually).
Can someone explain the key management strategy? Is there any key escrow? What happens if someone loses their computer / mobile device?
Each user's private RSA key is stored on the server, encrypted to an outer-level key that only ever exists in memory. This outer-level key is derived from the user's password using PBKDF2. This arrangement means that when a user loses their computer, or simply wants to access data from another device, their password is all they need to know to decrypt the whole chain.
We also use a zero-knowledge proof to establish that the user knows their password before sending the ciphertext of their keychain to their client, or otherwise access the system.