Data Encryption On the Rise In the Cloud and Mobile 83
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.
Except in the UK! (Score:5, Funny)
Re: (Score:2, Informative)
Dual layers are pretty much required too. Use some FOSS to encrypt it locally, then do it again on the cloud. No single point of failure or single point of pressure.
Re: (Score:2)
Dual layers are pretty much required too. Use some FOSS to encrypt it locally, then do it again on the cloud. No single point of failure or single point of pressure.
Depends on your point of view. If you mean someone breaking your encryption, agreed that is no "single point of failure". But from the other point of view -- legitimately retrieving your information -- there are now TWO single points of failure. That is to say, two individual points at which any failure means total failure.
So that does not come without potential cost.
Re: (Score:2)
Re:Except in the UK! (Score:5, Insightful)
We can't allow politicians to turn the Internet into a police state, that is something that happens in China and North Korea, it can't happen in Europe
*cough* 1939 *cough*
Re: (Score:1)
Yes, the politics of fear is known to work very well.
Re: (Score:3)
Re: (Score:2)
That's what we have the European Declaration of Human Rights and the associated courts for. To stop governments doing shit like this and taking us back down that path.
Re: (Score:2)
The ONLY thing that can stop a madman with a gun is a sane man with a gun. But we're not supposed to say that... according to some.
Re:Except in the UK & the US! (Score:2)
His buddy Barack agrees. Thankfully, the chances of this actually happening here in the US is probably much less. At least for now.
It's just moving your trust to someone else (Score:5, Insightful)
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.
Re:It's just moving your trust to someone else (Score:5, Interesting)
So now you are placing your trust in those who wrote the code that runs your server or encrypts your data (or did you 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. That's not possible for most people, including myself. So most of us are left with choosing amongst Faustian bargains. That fucking sucks, but seems to be the reality in modern times. And it gets even better, because if you end up choosing the best shitty compromise that actually kind of works, you flag yourself for extra scrutiny because you are using an effective solution. FML. I'm going for a hike in the woods with my dog. Ahhhh. That's better.
Re: (Score:2)
You could always use several layers of encryption, written by different groups (e.g. a GPG'd file inside a Truecrypt container, stored on a Bitlocker volume inside a Windows virtual machine run on a Linux computer with encfs).
This part I have no solution for. : (
Re: (Score:2)
And it gets even better, because if you end up choosing the best shitty compromise that actually kind of works, you flag yourself for extra scrutiny because you are using an effective solution. FML.
This part I have no solution for. : (
I gave you one: Step away from the computer, walk past the smartphone, leash up the dog and head for the woods (or nearest park/nature preserve/whatever). When that becomes illegal it's game over.
Re: (Score:2)
You could always use several layers of encryption, written by different groups
Encrypting something already encrypted has to be done very carefully, otherwise the data is less secure, not more. In the widely known 3DES, which was used as an interim upgrade to DES before AES, the second encryption is actually done with the DES decryption function, while the first and third encryptions are done using the DES encryption function.
And when layering different algorithms, it is possible for the weaknesses of one algorithm to exacerbate the weaknesses of another algorithm. This requires under
Re: (Score:3)
Do you have an example?
To my naive understanding, the output of any encryption should appear random. Then, encrypting anything random should also be random -- the only effective difference should be that you now need (some mathematical function of) both keys to decrypt it.
I could accept that the above could be wrong, but I'd love for you to explain why it's wrong.
Re: (Score:1)
It's wrong. /being/ random, and /appearing/ random (but being generated by an analytic funciton).
I suggest you look at your own text, see that you use both the words "appear" and "be", and then ponder the difference between
Re: (Score:2)
"encrypting anything random should also be random"
In theory there's no difference between theory and practice, but in practice there is.
can't trust what you wrote either (Score:3)
>. 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 guy
lack of salt (Score:3)
He didn't salt the hashes, so it was a simple lookup
Re: (Score:2)
I don't think he was talking about heartbleed. I think he was talking about GOTO FAIL [imperialviolet.org]
both. unchecked input is very common (Score:2)
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 intention
Re: (Score:2)
If you really know what you are doing then setting up your own server is the best option, because the security services prefer to target large providers where they can compromise millions of accounts in bulk instead of doing after individual systems with varied security.
If you are not capable of setting up something really secure yourself you are better off trusting someone who can.
Re: (Score:2)
My understanding is that what you're talking about, is how these services are claiming to work. Trust is still happening, but it's moved from trusting a data service to not provide keys to adversaries, to trusting a code repository (i.e. the user trusts Apple/Google/Microsoft to have not included (or include in an automatic update) a backdoor in the user's OS, which causes your computer to give up keys upon request).
That's a step in the right direction.
And I think people can see the obvious next step fro
Re: (Score:1)
I am the creator of a password manager app called Easy Password Storage that can sync data between devices using a zero-knowledge cloud server.
The passwords are encrypted on the user's device with their secret key before they are ever sent to the cloud servers. I have no way of decrypting their data, even if I wanted to. That's by design: I don't want the ability to see anyone's password.
There is trust involved, but the users can always examine their data transmissions to see exactly what's going back and
Good luck with that. (Score:1)
"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.
Re:Good luck with that. (Score:5, Insightful)
It doesn't matter.
Don't trust them? Encrypt your data with a private key before you upload it to them.
The point of encryption is that you can just give your encrypted data to people. Without the key, there's bugger-all they can do with it. You don't HAVE to trust them. You just have to ensure they don't have the key. And why would they need to?
Hence, don't trust them. Don't believe them. Who cares? Encrypt it yourself anyway, and it's game over.
And, if you want to get really pedantic, so long as you NEVER provide them with the public or private keys yourself, there's no way they can decrypt it. Now, they may be embedded in their software, or potentially accessible by their app, or whatever, but that's for you to determine. If they can't get your keys, it doesn't matter what happens on their end. That's the whole point of encryption.
And exactly why use of it has exploded. It's as simple as not giving Samsung, Google, Apple, etc. your actual KEYS but letting them hold your data.
Don't trust them, if you don't want to, because you have absolutely no need to do so in order to let them hold your (encrypted) data.
Re: (Score:1)
The point of encryption is that you can just give your encrypted data to people. Without the key, there's bugger-all they can do with it. You don't HAVE to trust them. You just have to ensure they don't have the key. And why would they need to?
We're talking about the article here, which is talking about cloud providers providing encryption for their clients. If you're relying on a third party to encrypt your data, that means they have access to your unencrypted data. There's no point in encrypting it after
Re: (Score:2)
If you used a ( insert manufacturer here ) device to input your key data, then you are already running the risk of your keys being compromised.
There are just too many attack vectors to get your keys from you. Hardware, software, corporate cooperation, exploits and even human espionage.
If they want your data bad enough, you're really going to have to place the bar really high to make them work for it.
Cloud is useless in Canada (Score:2)
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".
Re: (Score:2)
You only have alternatives if you live in or near a big city. My only other choice is "no Internet".
Re: (Score:2)
That's true, but it's not like I'm the only one with such a problem. Not everyone lives in big cities, so I guess my title should have been "Cloud is useless for a lot of Canadians".
Re: (Score:2)
Re: (Score:2)
I've known about Teksavvy for a few years but they're not available in my area.
"at least theoretically" (Score:2, Funny)
Re: (Score:2)
Re: (Score:2)
No control (Score:2)
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 up
Re: (Score:1)
That's an extraordinary claim, and you haven't provided any evidence to backup your assertion. Care to elaborate?
Re: (Score:1)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Thanks dudes, I love Slashdot! So relevant and helpful!
No means to access encrypted data is misleading (Score:2)
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,
Encryption services (Score:1)
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 so
Re: (Score:2)
"The chair is against the wall, the chair is against the wall. John has a long mustache, John has a long mustache."
Re: (Score:2)
"Pardon me - does this train go to the airport?"
DIY (Score:2)
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?
Welcome to the new reality (Score:3)
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." [wikipedia.org] 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.
DIY (Score:1)
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.
Gov. mandating key escrow (Score:1)