5 ms·

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

82 points by squidlogic 11y ago

squidlogic 11y ago
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 11y ago
  Mobile operating systems often use that as a quick and solid-state-storage friendly way to clear devices.
  - bmm6o 11y ago
    And also for "deleting" an entire class of data from all of your backup media.
mtgx 11y ago
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=258435 http://research.microsoft.com/apps/pubs/default.aspx?id=2584...
- deleted 11y ago
  [deleted]
- tmullaney 11y ago
  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 11y ago
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 11y ago
  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 11y ago
I wrote a client-side encryption library for the communication part of the equation: http://stringphone.readthedocs.org/ http://stringphone.readthedocs.org/
- sarciszewski 11y ago
  I like that you're using NaCl. I'm earmarking this for review later. :D
  - StavrosK 11y ago
    Thank you! It's pretty lightweight.
  - denniskane 11y ago
    It's quite a coincidence that you posted this while I was writing up my own post evangelizing the virtues of NaCl :)
    - napoleond 11y ago
      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 11y ago
        I want to use NaCl with NaCl to connect to GCM using AES-GCM.
denniskane 11y 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 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 11y ago
  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 11y ago
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 11y ago
It's interesting that the very security minded disable javascript in their browser for security reasons, which makes most client-side crypto not possible.
- privacy101 11y ago
  Do they disable it globally or selectively enable it?
  - brobinson 11y ago
    Both, as far as I know. Plugins like NoScript disable it globally and allow you to whitelist domains/subdomains.
- anon1385 11y ago
  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 11y ago
    > 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.
toyg 11y ago
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 11y ago
  What you describe already exists. It's called client certificates.
  - toyg 11y ago
    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 11y ago
      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/keygen https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ke... (
      - toyg 11y ago
        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.

82 points by squidlogic 11y ago

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 11y ago
Mobile operating systems often use that as a quick and solid-state-storage friendly way to clear devices.
- bmm6o 11y ago
  And also for "deleting" an entire class of data from all of your backup media.

mtgx 11y ago

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=258435 http://research.microsoft.com/apps/pubs/default.aspx?id=2584...

deleted 11y ago
[deleted]
tmullaney 11y ago
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 11y ago

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 11y ago
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 11y ago

I wrote a client-side encryption library for the communication part of the equation: http://stringphone.readthedocs.org/ http://stringphone.readthedocs.org/

sarciszewski 11y ago
I like that you're using NaCl. I'm earmarking this for review later. :D
- StavrosK 11y ago
  Thank you! It's pretty lightweight.
- denniskane 11y ago
  It's quite a coincidence that you posted this while I was writing up my own post evangelizing the virtues of NaCl :)
  - napoleond 11y ago
    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 11y ago
      I want to use NaCl with NaCl to connect to GCM using AES-GCM.

denniskane 11y 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 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 11y ago
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 11y ago

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 11y ago

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

privacy101 11y ago
Do they disable it globally or selectively enable it?
- brobinson 11y ago
  Both, as far as I know. Plugins like NoScript disable it globally and allow you to whitelist domains/subdomains.
anon1385 11y ago
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 11y ago
  > 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.

toyg 11y ago

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 11y ago
What you describe already exists. It's called client certificates.
- toyg 11y ago
  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 11y ago
    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/keygen https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ke... (
    - toyg 11y ago
      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.