Slashdot Mirror
Data Encryption On the Rise In the Cloud and Mobile
dkatana writes: Overall, demand for encryption is growing. Cloud encryption services provider CipherCloud recently received a $50 million investment by Deutsche Telekom, which the company said positions it for "explosive growth" this year. The services are designed to allow corporations to benefit from the cost savings and elasticity of cloud-based data storage, while ensuring that sensitive information is protected.
Now, both Apple and Google are providing full encryption as a default option on their mobile operating systems with an encryption scheme they are not able to break themselves, since they don't hold the necessary keys.
Some corporations have gone as far as turning to "zero-knowledge" services, usually located in countries such as Switzerland. These services pledge that they have no means to unlock the information once the customer has entered the unique encryption keys. This zero-knowledge approach is welcomed by users, who are reassured that their information is impossible to retrieve — at least theoretically — without their knowledge and the keys.
Now, both Apple and Google are providing full encryption as a default option on their mobile operating systems with an encryption scheme they are not able to break themselves, since they don't hold the necessary keys.
Some corporations have gone as far as turning to "zero-knowledge" services, usually located in countries such as Switzerland. These services pledge that they have no means to unlock the information once the customer has entered the unique encryption keys. This zero-knowledge approach is welcomed by users, who are reassured that their information is impossible to retrieve — at least theoretically — without their knowledge and the keys.
Courtesy of our beloved prime-minister's entirely feasible encryption ban.
So this-or-that company promises you unbreakable encryption or that they won't poke their nose in your data. Do you trust them? I don't. All it takes is a little firm chit-chat from the national security agency of the country your data is hosted in, and your "safe" data isn't safe anymore.
If you really insist on putting files and shit in the cloud, encrypt it yourself before uploading it. Better yet, run your own server and provide yourself with your very own fucking cloud. Those who want real security aren't lazy and do the work themselves.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
"These services pledge that they have no means to unlock the information once the customer has entered the unique encryption keys." And who knows if that's true.
Stupidly low monthly caps means we have better things to do with our bandwidth than to keep uploading and downloading our documents in "the cloud".
Get free satoshi (Bitcoin) and Dogecoins
In theory there is no difference between theory and practice. In practice there is. Yogi Berra
Hosted applications may or may not handle the passwords properly after they've been entered into the form. It is inescapable that the host must have the raw keys in order to decrypt the data. It may be impervious to 3rd parties *now* but there's nothing that prevents that from changing, and the user has no way of detecting it.
Similarly for mobile applications -- unless one has firsthand knowledge that the currently installed application will not transmit raw keys to a 3rd party, AND prevents all future updates to that application, then the security is fleeting.
It may be that the promise of security is enough for a given use case, but to be sure one needs to encrypted the data with keys that are never transmitted to a 3rd party prior to uploading the data.
Another way of looking at it: If an entity were to hold a figurative gun to the head of a mobile app developer / hosting provider, in such a way that you as a user were unaware of it (ie were still willing to use the application / provider in the normal course of usage), could the application be changed such that the data is exposed?
That's an extraordinary claim, and you haven't provided any evidence to backup your assertion. Care to elaborate?
Really now, you have to be an idiot to think that the companies that provide encryption have absolutely _no_ means to break your encryption. Sure, they may not be able to break the encryption by brute force (nobody can really), but they are being misleading. The lie, if you were to call it such, is that anyone that can push software updates to your device, can also push malware to it. This includes software designing by governments with unlimited funds to develop such malware to steal your encryption keys, and issue warrants that order said software companies to push it down to your device. About the only defense against such attacks would be a device that has no "back door" means around authentication while the device is turned on, and one which you never put online for updates from IP addresses that are known to be used by your device, nor serial numbers that uniquely identify your device, so the manufacturers can't target you for delivery of the payload from the authorities.
Come on people, wake up and smell the coffee. Headlines only hype the "we can't break the encryption" stories so the real idiots, the criminals, think they can get away with anything they want. Hopefully the thicker skull monkeys among us actually read this enough times for it to sink in ;)
There isn't an encryption scheme the NSA hasn't already secretly cracked.
One time pads are unbreakable if you have truly random pads and never reuse them.
All you can know is that the block is x characters long and you can only really presume that, as the text could be compressed.
I built an end-to-end cloud encryption service for file transfer. As much as I thought it would gain traction, getting and retaining users was very difficult. The security community is ultra-paranoid (as they should be) and don't want to rely on third parties at all if possible, and normal users don't really understand encryption and largely can't be bothered.
I found of the two features, inline encryption and big file transfer the latter was the selling point for the people who used it.
I'll probably open source the code soon, as few as I get a few days to clean it up. Empty landing page at www.senderdefender.com
If the encryption is provided as a black-box by the cloud provider, I will never trust it. Besides, it is brain-dead easy to mount an encfs volume on Dropbox. Just give me disk space. I'll encrypt it myself before you ever see it, ok?
This isn't going to be good for the NSA or other government agencies trying to snoop into your data but like a thief there will be some way that they'll find a weak point. Whether that's a weak key, a weak cipher some flaw in the negotiation protocols or brute force they'll find some way to get into it. They could just outlaw strong encryption technology as "munitions." I just thought that being a private citizen, one who values his privacy, wouldn't necessitate playing cat and mouse with my personal communications or data. If it's my possession, in my house, in my car there's constitutional safeguards against unreasonable searches and seizures. If it's transmitted to a server outside of my control or across the Internet or even a waxed string between two bean cans then those protections somehow vanish and my own government collects every piece of data they can about me like sweeping up so many fish in the ocean. To me that's not liberty, it's fascism. Secret courts with secret rulings, your information warehoused in Utah on who you called, where you went, who you emailed. That's not my country and doing it to fight "terrorists" doesn't work as an excuse either. I'm already migrating to overseas e-mail services and offshore cloud storage services and that's a shame because I should be able to have the same rights to privacy as somebody in Switzerland.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
If you send or receive an encrypted message to a bad guy, then you must be bad yourself.
That premise might be changing. The fact that you need or want to use encryption indicates that you're doing something bad. Like the police arresting you for carrying too much cash because you might use it to buy drugs.
I use a cloud service as back-end storage in my web application and compress and encrypt all files before sending them off. I don't think I would trust a cloud provider's encryption, even if it was available. Perhaps just layer it on to my own.
There isn't an encryption scheme the NSA hasn't already secretly cracked.
One time pads are unbreakable if you have truly random pads and never reuse them.
All you can know is that the block is x characters long and you can only really presume that, as the text could be compressed.
The message can also be padded with random data as well so you you don't even know the true length of the message.
"The chair is against the wall, the chair is against the wall. John has a long mustache, John has a long mustache."
Once a unbreakable encryption is developed the Gov. FBI, Police and others will demand key escrow otherwise "Goto Jail!"
>. write it yourself?). Better than believing "trust us - we don't track you/log you/etc" (looking at you, Startpage and DuckDuckGo), but you have to trust someone unless you do it all yourself from scratch.
Even if (especially if) you wrote it from scratch yourself you can't trust it. Just ask the folks who wrote Apple's SSL implementation, or openssl. They wrote it and later found out that it wasn't actually we secure. Unless you can prove that you're MUCH better at encryption than the openssl guys are ...
I recently tool a look at some password storage a colleague did. He was sure it was secure because he didn't store plaintext passwords, only hashes of them. It took about 60 seconds for me to tell him his password.
"Pardon me - does this train go to the airport?"
Thanks dudes, I love Slashdot! So relevant and helpful!
The ratio of people to cake is too big
You specifically said "as the text could be compressed" and nothing else. I wasn't sure if you had thought of padding the message as well.
He didn't salt the hashes, so it was a simple lookup
I was talking about both.
Programmers generally think about how to make it work. Their mindset is not how break it, therefore unchecked inputs are extremely common, in all sorts of code. In fact, I'll go further and say that fully cross-validating input is rare. With Heartbleed, each input value was valid, it was only the RELATIONSHIP between input values that was unchecked. Most programs don't go so far as to validate the relationships between inputs.
Therefore, while Heartbleed COULD have been intentional, it's precisely the kind of error we see all the time. It's just like a web form that allows you to enter your address as California, UK. The IV that NSA recommended was intentional. Heartbleed is a very typical piece of code. Most code has a similar same "flaw" - it just doesn't matter much in other code.
His buddy Barack agrees. Thankfully, the chances of this actually happening here in the US is probably much less. At least for now.