backtop


Print 21 comment(s) - last by karimtemple.. on Mar 31 at 12:39 PM

This will stop websites from leaking data

An MIT researcher has created a service that keeps data encrypted on servers at all times, only decrypting the data on a person's computer for them to see. 

According to MIT Technology Review, MIT researcher Roluca Popa developed the system -- called "Mylar" -- along with Meteor Development Group. It aims to stop websites from leaking data or allowing hackers to steal data. 

Mylar runs code inside a user's browser, which handles most of the processing and displaying of information (in other words, it takes over what a traditional service's servers would do). A server can still perform actions the user needs, but doesn't have a way to decrypt the data, as the user is the only one with a password in their browser. This password encrypts data there before it ever makes its way to the server. 

Popa said a service using Mylar could search across encrypted data stored on its servers, enabling a user to search documents they had uploaded to a file storage service. Mylar can also let users share data with other users, because a system distributes the necessary encryption key in a way that protects it from being seen by the server or anyone monitoring activities. 
 

Raluca Popa [SOURCE: cra.org]
 
There's even an optional browser extension that can protect against the server stealing the key needed to decrypt a person’s data.
 
Popa used the Web service building tool called Meteor to create her system, which will make it more simple for developer's to use. 
 
A big upside to this system is its ease of use. Popa said a group of patients at Newton-Wellesley hospital in Boston are currently testing Mylar for their medical information, and all the change needed in the hospital's current system was changing 28 lines of code out of 3,659 total. 
 
“You don’t notice any difference, but your data gets encrypted using your password inside your browser before it goes to the server,” said Popa. “If the government asks the company for your data, the server doesn’t have the ability to give unencrypted data.” 

Source: MIT Technology Review



Comments     Threshold


This article is over a month old, voting and posting comments is disabled

Ummm...
By chripuck on 3/26/2014 3:22:44 PM , Rating: 4
So what? I did this a month ago for an internal website. You just write your software to encrypt using local encryption libraries before you send the data. This method is easily available in .net libraries and any website can implement it.

What am I missing?




RE: Ummm...
By bitterman0 on 3/26/2014 3:50:34 PM , Rating: 5
quote:
What am I missing?
... a huge pile of money in a form of a government "research" grant?


RE: Ummm...
By karimtemple on 3/31/2014 12:39:49 PM , Rating: 2
It's interesting how these sorts of articles get read so defensively by people. "A team of researchers from MIT partnered with a web tech group to create a web encryption tool that works in a way that no other current web encryption tool does." "PSSSHHH! I did this a month ago!" lmao. Calm down, Nick Burns.


RE: Ummm...
By NellyFromMA on 3/26/2014 4:09:06 PM , Rating: 2
There isn't anything different... It's the same general method as today, except encryption seemingly happens on client, and the "salt" aka password is kept on the encrytpting client, presumably storage in some very simple encryption.

If the encryption can happen in any unit of time close to 'real-time' on the client, then it is almost next to useless in thwarting anyone who WANTS to decrypt said data.

If servers were involved in the encrypt / decrypt, at least you could presume (although unlikely) that server farms would team-up to offer more compute cycles than the client could spare in an effort to make the cipher harder to unravel.

This is on the assumption that we are talking about NATIVE code in the browser. If the cited implementation is aactually a universal javascript-based endeavor.. say goodbye to any practical use.

Bottom-line: If a single client has enough cpu cycles to offer the decryption thread to do so in 0-30 seconds (30 is very generous in terms of usability) without other client/server assistance then any hacker could easily reverse engineer with brute-force using a comparable device or PC.

It's a great experiment to teach a student the values of encryption and respect for data-sensitivity, but its just not much of anything in the way of solving the issue.


RE: Ummm...
By mousewiz on 3/26/2014 6:14:20 PM , Rating: 3
quote:
It's a great experiment to teach a student the values of encryption and respect for data-sensitivity, but its just not much of anything in the way of solving the issue.


From the linked article:
quote:
She points to how she previously led development of a system called CryptDB, software that allows databases to be fully encrypted, which has since been adopted by Google and the business software giant SAP. “I think Mylar will be at least as useful, if not more,” she says.


The article implies that your assumption that this is just a student project is wrong.

The contributions here seem to be:
1) Fixes to flaws in existing systems (eg: Kim Dotcom's MEGA does something like this, but doesn't protect against a malicious server)
2) Combine it into an easy (26 lines) to roll out package


RE: Ummm...
By NellyFromMA on 3/27/2014 2:17:45 PM , Rating: 2
I'm not "just saying" its a student project. I'm saying that's about all I perceive it to be.

Even if Google, for example, (or MS for that matter) implements the decryption natively in it's browser, the conversation is still the same: A single client with full-logic to decrypt data near real-time. Further, if the algorithms in use are to be standardized across browsers/clients, its really not overly difficult to reverse-engineer the algorithms for those who desire to and are capable.

Without involving server-farms or other additional resources for encryption decryption, you aren't hindering brute force decryption attempts by much.

It's the same as its always been. The same programmable unit used to decrypt with salt can be used to brute force since at the highest level, the same resources are available to the process in each scenario. So, one huge obstacle (perhaps the most important one IMO) for said hacker has been nullified as they have been provided a given which is the one thing you need to avoid in implementation for security purposes. Reverse engineering and hence hacking relies on reproducible givens.

Further, if you expounded on this and said the hacker actually has access to a couple of other PC's, they just exponentially increased their chances of decrypting without salt via brute force because they have inherently exceeded the available resources of the original encryption hardware to begin with and hence decreased the time it will take for brute force to yield a result.

What it WOULD do is stop the clear-text transmission of data which is all too easy to obtain. What it would NOT do is substantially protect your data from actual hackers. What I described above is applicable to decryption cracking in all scenarios. Brute force decryption attempts with single "salt" is exponentially more likely to yield decryption when the compute units used in the brute force attempt meet or, ideally, exceed the decrypting hardware's resources when encrypt/decrypt is expected to happen near realtime as it would need to for this to be useful at all in this application.

What's my point? There is no "generic encryption" that substantially protects your data. If its purpose is broad and its decryption on widely available hardware can happen near real-time then it's highly likely to be cracked in a short order of time.


RE: Ummm...
By SlyNine on 3/28/2014 5:55:57 PM , Rating: 2
So you're saying AES 128, PGP and others all are worthless? AES128 can be encrypted at around 3gbps with aes-ni (any laptop Core I5). But is for all intensive purposes secure from brute force because it takes many times the age of the universe to brute force.

Does this not apply to this situation; if not why?


RE: Ummm...
By thecubanate on 3/26/2014 7:36:07 PM , Rating: 2
It's likely it is a javascript-based functionality given that is the way Meteor works. Her contribution, in my opinion, is that she used a framework to demonstrate the principle and made it easy for the server to locate information. Hopefully, the paper will provide more details about searching and specially recovering the password.

quote:
A Meteor application is a mix of JavaScript that runs inside a client web browser, JavaScript that runs on the Meteor server inside a Node.js container, and all the supporting HTML fragments, CSS rules, and static assets. Meteor automates the packaging and transmission of these different components. And, it is quite flexible about how you choose to structure those components in your file tree.


RE: Ummm...
By YearOfTheDingo on 3/26/2014 4:09:07 PM , Rating: 2
This part?

quote:
Mylar allows the server to perform keyword search over encrypted documents, even if the documents are encrypted with different keys.


RE: Ummm...
By mousewiz on 3/26/2014 6:05:05 PM , Rating: 2
The paper isn't out yet, so I can't look, but that's a thing (to a certain degree: the linked article says it's a new trick, so she probably did something newish with it) already, too.


RE: Ummm...
By NellyFromMA on 3/27/2014 2:20:26 PM , Rating: 2
Likely a clear-text or substantially less secure encryption on a subset of clear-text values in the data deemed "key" that are associated with the actually encrypted data.

Otherwise, if you could so easily search the encrypted data that would just further prove how this can't add much security to the equation.


RE: Ummm...
By Hammer1024 on 3/27/2014 1:20:34 PM , Rating: 2
Yup... nothing to see here... move along... move along.


"Mylar" Encrypts Data in Browser
By vladio on 3/26/2014 5:20:53 PM , Rating: 2
One word: Backdoors
Two words: Intel-MS-(3LetterNames), Backdoors
p.s.
All or Nothing!
Expected: ToTaL Solution
Actually: partially solved `cute staff`
-VJO




By superstition on 3/27/2014 6:50:36 AM , Rating: 2
"It aims to stop websites from leaking data or allowing hackers to steal data" [while enabling the NSA to thieve as usual].


Nationality
By Scootie on 3/26/2014 5:25:22 PM , Rating: 2
Judgeing by her name she could be romanian. Would have been interesting to find out more about her research.




RE: Nationality
By ipay on 3/27/2014 10:26:21 AM , Rating: 2
Yes, from Sibiu. You can read more about her research here: http://web.mit.edu/ralucap/www/


wow she's young
By TheDoc9 on 3/26/2014 3:02:31 PM , Rating: 2
Talk about a huge career in the future! Congrats!




ZenMate any good?
By BubbaJoe TBoneMalone on 3/26/2014 10:21:34 PM , Rating: 2
Just started searching on encrypting browser traffic because of this article and found ZenMate. Installed it on my Comodo Dragon Chrome browser. Are there any others that are better?




surprised
By Bobhacks on 3/27/2014 6:47:51 PM , Rating: 2
I'm surprised no one mentioned that she's kinda cute.

Cute + smart = win




Nicely done.
By Motoman on 3/26/2014 3:27:19 PM , Rating: 1
For your efforts, I award you with a vigorous rogering. Swing by anytime to claim your prize.




surprised
By Bobhacks on 3/27/2014 6:39:52 PM , Rating: 1
I'm surprised no one mentioned that she's kinda cute.

Cute + smart = win




"My sex life is pretty good" -- Steve Jobs' random musings during the 2010 D8 conference











botimage
Copyright 2014 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki