
Spideroak debuts Crypton, framework for end-to-end encrypted cloud applications - jtemplin
https://crypton.io/
======
moxie
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?"

~~~
rarrrrrr
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!

~~~
rdl
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.

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

------
alexjeffrey
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/>

~~~
jacques_chester
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.

~~~
infodroid
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-...](http://www.forbes.com/sites/jonmatonis/2012/07/30/cryptocat-
increases-security-in-move-away-from-javascript-encryption/)

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.

~~~
jacques_chester
> _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.

------
rarrrrrr
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!

~~~
cbsmith
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?

~~~
rarrrrrr
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>

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

~~~
dekz
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.

~~~
jacques_chester
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.

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

~~~
ecto
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...](https://github.com/SpiderOak/crypton/tree/master/client/examples/diary)

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

~~~
rarrrrrr
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.

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

~~~
ecto
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.

~~~
dfc
What is wrong with sjcl's PBKDF2?

[https://github.com/bitwiseshiftleft/sjcl/blob/master/core/pb...](https://github.com/bitwiseshiftleft/sjcl/blob/master/core/pbkdf2.js)

It looks like there will be no CFB in sjcl:

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

------
davidje
How does this relate or compare to homomorphic encryption technologies?

~~~
wmf
It actually has a chance of working.

~~~
swordswinger12
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.

~~~
wmf
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?

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

~~~
dhain
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.

