Client-Side Encryption: The Right Security Model for the Cloud | Hacker News Reader

Client-Side Encryption: The Right Security Model for the Cloud

blog.balboa.io

82 pointssquidlogic27 comments

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.

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

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

Two projects for client-side encrypted cloud data:

https://css.csail.mit.edu/mylar/

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

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

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.

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.

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

http://stringphone.readthedocs.org/

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

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

Different NaCl. Yes, the naming collision is unfortunate.

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

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

Thank you! It's pretty lightweight.

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.

Also that would probably greatly simplify key management as opposed to having 10 apps all wanting you to use their own mechanism every time you move to another device.

Unfortunately so far things are moving in the opposite direction. After Chrome dropped Java support it appears there's no cross-browser way to do reasonably reliable crypto right now.

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

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

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

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.

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

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!

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?

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

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.

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.

> 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. I am currently working on a second project which uses the CLI interface. The HTTP interface will remain broken for some time.

Do they disable it globally or selectively enable it?

Both, as far as I know. Plugins like NoScript disable it globally and allow you to whitelist domains/subdomains.

Reply on news.ycombinator.com