Spideroak debuts Crypton, framework for end-to-end encrypted cloud applications | Hacker News Reader

Spideroak debuts Crypton, framework for end-to-end encrypted cloud applications

crypton.io

98 pointsjtemplin47 comments

Interesting project, but if this page is for developers, I think there should be less text and more code in it. If the idea is to make it dead simple to host opaque content, the second paragraph should say "it's this simple!" with a 10 line code sample for this project's hello world equivalent (a simple backup service, for instance).

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?"

Great question!

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!

I'd like to see some way to combine public-key crypto (receiving and encrypting incoming unencrypted mail, received over starttls) with periodic mail indexes built on the client, so you could search a server-hosted encrypted mailbox.

> search results on encrypted data by making liberal use of the cheap containers to automatically save indexes as the data is modified.

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!

This is interesting, but I think they make some incorrect assumptions. For instance, people won't use Evernote for most stuff, and then a more-secure app for specific things -- they'll either use Evernote and accept the security weakness, for everything, or find something marginally less easy to use or more expensive, but much more secure, and use that for everything. The issue is exactly how much less easy to use vs. how much more secure, and how much users care about each.

The only problem here is that because the Javascript is delivered by the server which is supposedly offering privacy from itself, nothing is stopping the developers from simply changing the Javascript and stripping away the encryption through either capturing keys or not applying it in the first place.

see: http://www.matasano.com/articles/javascript-cryptography/

Of course, but that's not the threat model we're protecting against. Note that we link to that article (and agree with it!) in the discussion. This isn't just for browser based products. The reference implementation is in JS and intended for packaged HTML5 mobile apps, and we'll follow with implementations in C, Python, Java, etc.

You say it's appropriate for browser apps on the the landing page.

In the browser app scenario, we also declare on that very same page that the threat model is explicitly this: you're an application provider who doesn't want the liability of having a database of plaintext user supplied content. (I.e. protecting a business from its customers' activities.) Not the other way around.

Nonetheless you do have at least some liability because if your server is compromised for long enough for one or more users to sign in, their details could be captured using modified Javascript and used to decrypt their private data. It does provide protection against hackers stealing the whole database in one shot though.

Javascript replacement is a problem with every single scheme that relies on the browser being an active participant.

I know this because I designed such a scheme and it was hilariously, fantastically broken.

Do you think this can be remedied by moving the code out of the web container?

Cryptocat moved away from delivering its crypto code over JS to a browser plugin: http://www.forbes.com/sites/jonmatonis/2012/07/30/cryptocat-...

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.

> Do you think this can be remedied by moving the code out of the web container?

That's what I did in my own design. My protocol's purpose is different from cryptocat's, but the problem that in-browser javascript is untrustworthy is the same.

I designed my protocol so that it needn't be embedded in the browser at all -- or for that matter, piggybacked on HTTP.

This is the problem I have with Lastpass - someone could hack their servers, replace the javascript encryption file to send the decryption password to their server, and get all of your passwords.

you are talking about web access from a public computer I suppose? if you are connecting from your computer then I suppose the decryption happens in the browser extension and you are safe from the scenario you describe, or am I missing something?

I am talking about either situation. Someone could hack their site (angry employee, outside person, etc), and modify the code to send the decryption password to their server. This would work for either situation since the person could push an update out for the browser extension.

I'm sure they are very careful about the security of their system, but they are still one step away from having all of your passwords (a simple extension update, or site javascript modification). If I use a program like keepassx, I know when it's updated, and can verify that it doesn't attempt to communicate with a remote server.

Hello -- cofounder of SpiderOak here. We're at a launch event during RSA so responses will be slow, but I'll check back here later. Thanks for your interest!

I didn't quite understand what was unique about the application of crypto in your product. I had assumed from the headline it was a productized homomorphic encryption, but at least at first glance I'm thinking it is more a productized implementation of a key-value store with records encrypted client side. Is that correct?

Close. It's not a key value store, but rather an object database (with design goals similar to ZODB[1])

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.

[1] http://en.wikipedia.org/wiki/Zope_Object_Database

When is your launch event (I'm...still finishing my talk for wednesday :( )...but would be really interested in learning more.

Right now. https://spideroak.com/blog/20130221160525-announcing-penetra...

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.

Good stuff, Alan!!

Upfront, I'll say that I'm not a particularly good crypto person.

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.

I relied in part on javascript running in a browser. That doesn't work. It seems that so far the Crypton team are going to spend about 50% of their time explaining yes-it's-javascript-no-it's-not-all-in-the-browser.

Anyhow, any time you have code running the browser, it's unsafe against a malicious publisher. Your first instinct is "I'll serve my js files over HTTPS", which is lovely, except that in the browser execution everything can be found, introspected and replaced by javascript sent by the publisher.

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.

I get the feeling this is more of an example client written in js. Look more to the server and its API rather than how client implementations are served.

I've spelunked the code a bit, but I am having trouble determining what is running where (JS is not really my bag). Even the stuff in the client/src subdirectory has server-like parts.

Genuine question - why in Geneva and why would you need a patent examiner for smth like that? US trolls?

There are different ways of applying for international patents.

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.

My wish is for something like this to be provided as a service. I want to be able to write a collaborative, multi-user web app without having to run any servers and without having any access to my users' data. The way desktop apps used to be, except I want my users to be able to share data with each other easily. I also would like my users to have flexibility to choose between data providers (or even run their own), so their data is never held hostage.

Hey, I'm one of the developers working on the project. The possibility of "Crypton as a Service" is something we've been thinking about since we started working on this. It's coming soon, but we've been busy getting the fundamentals out - watch for the client SDK which will hook up to a SpiderOak-hosted Crypton server.

For a good (though hastily assembled) example of a client-side demo, check out https://github.com/SpiderOak/crypton/tree/master/client/exam...

This sounds just like the remoteStorage protocol It's a protocol for building web apps with pluggable remote data stores. http://remotestorage.io/

More detail about this sort of "unhosted" architecture: https://unhosted.org/

But unlike Crypton, in remoteStorage you have to trust your storage provider because it can access all the app data.

Something I thought I'd understood, but now clearly don't: Does Spideroak roll its own cryptography code, or does it leverage an existing, accepted, and open library?

The crypto specs for the SpiderOak backup/sync product are here: https://spideroak.com/engineering_matters

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.

Why do so few projects use SJCL? Whenever I see a project like this I always have my fingers crossed that they will be using sjcl but it never pans out.

We evaluated several libraries (all JS crypto libraries we could find actually - there aren't many) and CryptoJS suited our needs the best. Specifically, it includes PBKDF2 and CFB mode for AES which SJCL doesn't have right now.

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.

What is wrong with sjcl's PBKDF2?

https://github.com/bitwiseshiftleft/sjcl/blob/master/core/pb...

It looks like there will be no CFB in sjcl:

https://github.com/bitwiseshiftleft/sjcl/issues/7

I guess I would have to ask what they would be using SJCL on, but I believe that there have been several conceptual issues noted by guys like tptacek to keep from recommending any client-side JS crypto (incl. SJCL) in general.

I was under the impression crypton used cryptojs:

https://github.com/SpiderOak/crypton/tree/master/client/src/...

EDIT: And jsrsasign:

https://github.com/SpiderOak/crypton/tree/master/client/src/...

FYI, our choices for upstream JS crypto libs aren't set in stone. We may ultimately go with SJCL -- we're not fully satisfied with the libs we're using. They need some cleanup in various areas if we do stick with them.

How does this relate or compare to homomorphic encryption technologies?

The idea with homomorphic encryption is that you can have the host perform computation against the cyphertext without decrypting it. They've gotten this to work, but it's still much too slow to be of practical value. It'll get faster naturally though, even if they don't actually refine the algorithms.

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.

Actually, there are many cloud-hosted services that aren't HTTP services and could use such a framework as well. With plenty of power for homomorphic encryption.

It actually has a chance of working.

There are certain special cases for which homomorphic cryptography should would acceptably. Blinded signatures are one example of something essentially a special case of it.

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).

What makes you say homomorphic encryption doesn't have a chance of working? I grant you that it will be at least 15 years before a commercially viable homomorphic encryption product is released, but to say it has no chance of working is silly. My research advisor likes to tell a story of his friend going to see Rivest give some of the first lectures on RSA circa 1977. All the systems people in the room laughed at the naivete of this young cryptographer and his hope that such an absurdly slow encryption method would gain widespread adoption.

I suspect Crypton is for people writing apps now, not 15 years from now. Who knows what moral panic we'll be getting worked up about in 2025?

I looked through the doc a bit but didn't see an answer.

Can someone explain the key management strategy? Is there any key escrow? What happens if someone loses their computer / mobile device?

We form a hierarchy of keys to unlock the various data contexts in the system. At the lowest level, we store keys for payload data on the server, encrypted to the user's public RSA key (and in the case of shared data, the public keys of any other users who have access to read the payload).

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.

Reply on news.ycombinator.com