Feeds

back to article Modern 'primitive' could ease the pain of encrypting massive amounts of data

Researchers have devised an encryption scheme that could simplify the protection of sensitive information by allowing banks, hospitals and other organizations to lock files using keys that are based on specific attributes, such as an employee's position or geographic location. The method, which was unveiled last week, adds to …

COMMENTS

This topic is closed for new posts.

This post has been deleted by a moderator

Silver badge

Solutions

The solution is to just not store sensitive information on a computer. See, problems solved and the waste of resources that is IT is now under control.

0
0

Symetric and assymmetric encryption systems

"Functional encryption is designed to solve the hassle tied to traditional public-key encryption resulting from distributing and managing thousands or millions of private keys authorized people need to decrypt protected data. If 1,000 people in an organization need to securely share their public key with their co-workers, that requires close to one million separate exchanges."

You seem to be getting confused between symmetric and assymmetric encryptions. In a symmetric system you have a seperate secret key that you exchange with everybody. Total number of keys needed is n(n+1)/2 which does get very near to a million for 1000 employees.

In an assymmetric system you have one public key that is available to everybody. There is no need to secure your public key, as it's a public key: there is a clue in the name after all. In an assymmetric system you only need n keys.

0
0

Similar tech already used

by some financial institutions. Any account details are sent in a pdf, password-protected with the account holder's SSN. Not the same as encryption, but it's a similar principle.

0
0
(Written by Reg staff)

@Simon Whitehouse

Ever heard of key signing parties? Even with asymmetrical schemes, there is a need to securely exchange public keys. If a bad guy fools me into using the wrong public key to encrypt a message, the entire system fails.

So yes, an organization of 1,000 people still need to figure out a way to securely distributed their public key to each of their colleagues, and if you do the math, that's very close to 1 million exchanges.

0
0

Am I being dense?

Maybe I'm just being dense here, but I always thought the purpose of encryption was to make sure people viewing the data couldn't decipher it. If you use something as useless as a person's name or geographic location as a key (or even their social security number at this point, since that's not even close to secret/private anymore), then a brute-force attack to decrypt the data will take relatively little time. In other words, the encryption will be virtually useless.

Isn't this why we tell people to use complex passwords? Isn't this why we tell them not to use personal info in their passwords (own/spouse/child's name, birthdays, etc)?

And yet now we're telling people this is a good way to encrypt sensitive information?

0
0
Coat

good thing I read this

Because its time to enforce a password reset: 26 character minimum, contain 5 numbers, and 4 odd characters. And remember to shoot anyone who leaves with their laptop.

Its California, i don't need one

0
0
Silver badge
Boffin

Re: Am I being dense?

True. Its kind of stupid using easily-guessed "keys" to encrypt sensitive stuff. Even if it is what I understand, names of different persons, there are finite number of combinations to be tried. On top of that, full names in English-speaking countries usually are name + 1 surname, which ends up having lots of collisions (just how many 'John Smith' can you find?) and reducing even more the probabilities. Which anyone would get by doing a simple SELECT * FROM employee.

@Dan Goodin: Thats what CA's were made for. You get *one* single Root CA, and do all the checks to verify the public key comes from the actual user. Place the signed public key on an LDAP, and the distribution problem goes away, isn't this what PKI is all about? ;)

Disclosure: My previous job involved Information Security, PKI, and other fun stuff.

0
0
Anonymous Coward

Not ideal when time is of the essence

"Mr George Clooney died this morning after the doctor treating him collapsed from exhaustion and another, drafted in from a different hospital due to staff shortages, was unable to access his medical records on account of administrative delays."

"It seems that the doctor had obtained the necessary paperwork, passed it to the Departmental Authoriser who, when he got back from lunch, passed it to the Senior Authoriser who, upon returning from his golfing holiday, approved it and passed it to an assistant, who faxed it to the offshore call centre that handles the hospital's IT admin. They queued, prioritised, processed and filed the request in accordance with their SLA, and then notified the doctor."

"However, by the time that all this had been completed, it seems that the unfortunate Mr Clooney had been dead for several days."

0
0
Anonymous Coward

George Clooney dead??

Anon, that's hilarious. That kind of administrative overhead is what keeps people from implementing this kind of fine-grained access with mechanisms available today (i.e. ACLs). No matter how strong your enforcement, you still need a person to sit there doling out credentials and assigning ACLs to the database records. This functional encryption scheme is just stronger enforcement but doesn't change the fundamental policy overhead.

Also, one point I made that wasn't in the article is that better auditing is important to resolving this issue. If staff is notified that a random user will be selected each month to have all their queries reviewed, then they will be more careful to avoid exceeding their authority. The staff that was sacked for looking up celebrity records were only found because there was a "lock" on those records. But this doesn't stop looking up boyfriends or bosses, etc. so there needs to be some random review process to protect those of us who aren't famous.

-- Nate Lawson

0
0
This topic is closed for new posts.