Slashdot Mirror
The Beginnings of Encrypted Computing In the Cloud
eldavojohn writes "A method of computing from a 2009 paper allows the computing of data without ever decrypting it. With cloud computing on the rise, this may be the holy grail of keeping private data private in the cloud. It's called Fully Homomorphic Encryption, and if you've got the computer science/mathematics chops you can read the thesis (PDF). After reworking it and simplifying it, researchers have moved it away from being true, fully homomorphic encryption, but it is now a little closer to being ready for cloud usage. The problem is that the more operations performed on your encrypted data, the more likely it has become 'dirty' or corrupted. To combat this, Gentry developed a way to periodically clean the data by making it self-correcting. The article notes that although this isn't prepared for use in reliable systems, it is a quick jump to implementation just one year after the paper was published — earlier encryption papers would take as much as half a decade until they were implemented at all."
Practical homomorphic encryption is a fantasy, or at the very least it is so far off that it won't impact any of us any time soon.
If you want to cloudsource sensitive information processing, you will need a highly-secured vendor (most aren't even close). Sorry!
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
The idea that my data is on the "cloud" and I have to pay a monthly fee (or watch some ads) to access it is really not very interesting to me.
While it might be ultimately impractical - there's no harm in researchers getting their work out to intelligent, informed audiences... like, errr, ummmmm... that other place
Wait a minute. I'm a manager, and I've been reading a lot of case studies and watching a lot of webcasts about The Cloud. Based on all of this glorious marketing literature, I, as a manager, have absolutely no reason to doubt the safety of any data put in The Cloud.
The case studies all use words like "secure", "MD5", "RSS feeds" and "encryption" to describe the security of The Cloud. I don't know about you, but that sounds damn secure to me! Some Clouds even use SSL and HTTP. That's rock solid in my book.
And don't forget that you have to use Web Services to access The Cloud. Nothing is more secure than SOA and Web Services, with the exception of perhaps SaaS. But I think that Cloud Services 2.0 will combine the tiers into an MVC-compliant stack that uses SaaS to increase the security and partitioning of the data.
My main concern isn't with the security of The Cloud, but rather with getting my Indian team to learn all about it so we can deploy some first-generation The Cloud applications and Web Services to provide the ultimate platform upon which we can layer our business intelligence and reporting, because there are still a few verticals that we need to leverage before we can move to The Cloud 2.0.
Correct me if I'm wrong but couldn't you just use something like Encfs and fuse and just access your encrypted files as if they were a mounted file system right on your local system with all that implies?
The soylentnews experiment has been a dismal failure.
This has been tried for at least 3 decades. It could never be made to work efficiently and this approach is also not really going to help. It may have some valid crypto application this time (it never got that far before), but you will have to pump in so many more CPU cycles, that it will be a lot cheaper to just spend then directly on you own PC for any non-crypto stuff.
Side note: The things people will claim to make this mostly BS idea of the cloud seem to work never cease to amaze me.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
There's been some progress since this paper.
It's not there yet, but there's hope.
The good news is this will eventually stop the botnets. One all that computing power is reliably usable, there's profit motive to defend it.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
The whole idea behind this is that you'd be able to encrypt your data, upload it to your cloud provider, and use their hardware to do a bunch of work on it, without ever decrypting it. The reason why this is attractive is because you don't want your cloud provider looking at your data. If you can sort your data by plaintext, while still in ciphertext form (ie, without decrypting it on the cloud's hardware AT ALL), then what's stopping your cloud provider from doing it, too? You're leaking information about your data to your provider, and if they wanted to, they could perform a process of elimination and discover your plaintext.
Note, sorting is only ONE example of a class of algorithms that might have to be performed. Pretty much any useful algorithm would in some way leak information about the plaintext, in a way that would be visible to people who don't have your private key. That defeats the whole purpose. Might as well just upload all your data XOR encrypted.
The thing to keep in mind here is that the idea is to make it so your cloud provider has no way to read, or infer information about, your data. I'm in the camp that believes it's not possible, but even if it is possible, known methods (like this one) are neither plausible nor secure.
On the impossibility of cryptography alone for privacy-preserving cloud computing
If you can sort your data by plaintext, while still in ciphertext form (ie, without decrypting it on the cloud's hardware AT ALL), then what's stopping your cloud provider from doing it, too?
Nothing. The result will be a list of ciphertexts which won't reveal anything about the plaintexts.
See also the thesis, page 5 (5 on paper, 15 in pdf):
At a high-level, the essence of fully homomorphic encryption is simple: given ciphertexts that encrypt pi_1, ..., p_t fully homomorphic encryption should allow anyone (not just the key-holder) to output a ciphertext that encrypts f(pi_1, ..., p_t) for any desired function f, as long as that function can be efficiently computed. No information about pi_1, ..., p_t or ..., pi_t), or any intermediate plaintext values, should leak; the inputs, output and intermediate values are always encrypted.
f(pi_1,
So if I give you pi_1 and pi_2, you'll know that E(min(pi_1, pi_2)) = 42 and E(max(pi_1, pi_2)) = 17. What do their encryptions tell you about pi_1 and pi_2?
You're leaking information about your data to your provider, and if they wanted to, they could perform a process of elimination and discover your plaintext.
I don't think it's possible; I must admit I haven't read Gentry's thesis, but I assume he proves what he advertises---that he has a fully homomorphic encryption scheme. In that case, it is indeed possible to carry out any computation on encrypted values without revealing information about neither the plaintext nor the result of the computation.
Of course, if I'm wrong, I would very much like to see your algorithm for discovering the plaintext.
The thing to keep in mind here is that the idea is to make it so your cloud provider has no way to read, or infer information about, your data. I'm in the camp that believes it's not possible, but even if it is possible, known methods (like this one) are neither plausible nor secure.
Gentry's approach uses lattices; his approach should be secure against people whose computational resources are polynomial in the plaintext size, even (I think we think*) if they have quantum computers.
(* I haven't looked closely, so I'm randomly guessing his use of lattices is of the kind where no publicly known quantum attacks exist).
Security isn't an on/off thing. There's a stricter security property Gentry's system either satisfies or doesn't satisfy---that no one can know anything about the plain texts, even if computing on the ciphertexts "forever".
But in-use technology such as SSL, ssh, PGP/GPG doesn't live up to this standard, yet in practical security it's never the *crypto* that's broken.
To say that Gentry's work is not only wrong (not secure) but not plausible I think implies that the PhD committee at Stanford is doing a piss-poor job. Is that really what you mean?
(This is one of the reasons I'm doing my PhD in cryptography: in algorithms, or languages, or $subfield, when there's something you don't know you just know that you don't know how to do X; in cryptography, when there's stuff you don't know, it seems like magic is possible)