
Client-Side Encryption: The Right Security Model for the Cloud - squidlogic
https://blog.balboa.io/yet-another.html
======
squidlogic
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.

Not really a new idea, I don't think, but not one that gets surfaced much when
people talk about client-side crypto.

~~~
mnem
Mobile operating systems often use that as a quick and solid-state-storage
friendly way to clear devices.

~~~
bmm6o
And also for "deleting" an entire class of data from all of your backup media.

------
mtgx
Two projects for client-side encrypted cloud data:

[https://css.csail.mit.edu/mylar/](https://css.csail.mit.edu/mylar/)

[https://css.csail.mit.edu/cryptdb/](https://css.csail.mit.edu/cryptdb/)

Microsoft also released a homomorphic encryption project for bioinformatics
last week:

[http://research.microsoft.com/apps/pubs/default.aspx?id=2584...](http://research.microsoft.com/apps/pubs/default.aspx?id=258435)

~~~
tmullaney
Microsoft's Azure SQL Database also recently released a client-side encryption
feature, called Always Encrypted:

[https://msdn.microsoft.com/en-
us/library/mt163865.aspx](https://msdn.microsoft.com/en-
us/library/mt163865.aspx)

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

~~~
icebraining
In my opinion, homomorphic encryption is the new quantum computing. Remember
all the hype there was 15 years ago, around the time the first quantum
computers were being demonstrated? I think homomorphic encryption will be the
same: it's an interesting concept, and it has some specific use cases where it
excels at, but I think we'll see that it doesn't really beat traditional
encryption for most realistic needs.

------
StavrosK
I wrote a client-side encryption library for the communication part of the
equation:

[http://stringphone.readthedocs.org/](http://stringphone.readthedocs.org/)

~~~
sarciszewski
I like that you're using NaCl. I'm earmarking this for review later. :D

~~~
denniskane
It's quite a coincidence that you posted this while I was writing up my own
post evangelizing the virtues of NaCl :)

~~~
napoleond
Different NaCl. Yes, the naming collision is unfortunate.

([https://developer.chrome.com/native-
client](https://developer.chrome.com/native-client) vs.
[http://nacl.cr.yp.to](http://nacl.cr.yp.to))

~~~
sarciszewski
I want to use NaCl with NaCl to connect to GCM using AES-GCM.

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

It would likely be safer than hamfisted attempts at JS cryptography which can
be compromised down the wire.

~~~
gruez
What you describe already exists. It's called client certificates.

~~~
toyg
1\. client certificates only replace passwords, not arbitrary encrypted data.

2\. client certificate distribution is still a mess. At a minimum, there
should be a standard way for servers to generate certificates and install them
in the browser (with user visibility but without requiring user interaction).

~~~
jimktrains2
1) The problem with that is trusting the code you download to actually encrypt
the data. If it could be linked with the file upload button or some such
functionality solely reliant on the browser to get right, it could work.

2) You mean something like keygen[1]? (yes, I know it was removed from the
standard.)

[https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/ke...](https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/keygen) (

~~~
toyg
1) Exactly. Also, the more crypto you move into the browser, the easier it
becomes to inspect downloaded code and isolate misbehaving developers.

2) Exactly. I don't follow the standard process these days, but it's sad that
we're not really making any progress in such a critical area. We now have
pretty progress bars, but we're still as vulnerable as 20 years ago.

------
denniskane
I don't worry so much about encryption, since I am really not into keeping
secrets, but I agree about the client-side part.

...and now a brief word from our corporate sponsors...

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.

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: [https://nacl-
pg.appspot.com/desk?intro=the-shaker](https://nacl-
pg.appspot.com/desk?intro=the-shaker)

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.

Join the revolution!

~~~
JoshTriplett
I'd love to chat with you about this, but your profile doesn't have an email
address in it. Could you send me an email?

And for that matter, will you be at Chrome Dev Summit tomorrow?

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

[https://github.com/ereyes01/cryptohelper](https://github.com/ereyes01/cryptohelper)

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.

------
deftnerd
It's interesting that the very security minded disable javascript in their
browser for security reasons, which makes most client-side crypto not
possible.

~~~
anon1385
The people disabling javascript are also probably aware that javascript crypto
is utterly pointless with the current browser security model. Javascript
crypto aims to protect you from the server, but you must rely on the server
sending javascript that actually does the encryption. When it can't protect
you against the adversary it's design to protect you against then what is the
point?

Imagine a client-side-encrypted version of google docs that always encrypts
your document before sending it back to the google servers. Any time you visit
the site google could send you a modified version of the site javascript
(possibly at the request of security services) that just uploads the document
without encrypting it first. Browsers currently have no way to prevent that or
even notifying you that it's happening.

If you want to do client side crypto you need to do it in native apps. The web
is just too technically limited to support building platforms on top of it
that have different trust models.

~~~
wnortje
> Imagine a client-side-encrypted version of.......

The project I am working on aims to facilitate these kinds of apps. It is a
native app which have both a CLI interface and (used to before I broke it) an
HTTP interface. The idea is that websites gets proxied through the app. All
data gets stripped out and encrypted before being sent anywhere.

Websites must be aware that this is going to happen for them to work. Unaware
sites won't work. All or nothing.

The project site is
[https://www.selectiveshare.com](https://www.selectiveshare.com). I am
currently working on a second project which uses the CLI interface. The HTTP
interface will remain broken for some time.

