Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Encryption Cellphones Cloud Privacy Security

Data Encryption On the Rise In the Cloud and Mobile 83

Posted by Soulskill from the setting-a-standard dept.
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.
This discussion has been archived. No new comments can be posted.

Data Encryption On the Rise In the Cloud and Mobile More

Data Encryption On the Rise In the Cloud and Mobile

Comments Filter:

  • Except in the UK! (Score:5, Funny)

    by infolation ( 840436 ) on Friday January 23, 2015 @11:17AM (#48885049)
    Courtesy of our beloved prime-minister's entirely feasible encryption ban. [theguardian.com]

    • Re: (Score:2, Informative)

      by Anonymous Coward

      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.

      • 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.

      • 7-Zip [7-zip.org] is by far the easiest way to do this. Select files, right-click, 7-Zip, Add to archive... and if you supply a password and check "encrypt file names" the whole archive is AES-256 encrypted with the password you used. Upload that bad boy and feel more secure. On the other end, download it, right-click, "extract here" and then delete the 7z file. It's just one extra step prior to upload and after download and the shell integration makes it dead simple. If you're on Linux using p7zip at a command prompt,

    • 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)

    by Rosco P. Coltrane ( 209368 ) on Friday January 23, 2015 @11:21AM (#48885099)

    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)

      by c0d3g33k ( 102699 ) on Friday January 23, 2015 @11:32AM (#48885205)

      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.

      • 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).

        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. : (

        • 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.

        • 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

          • 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.

            • It's wrong.
              I suggest you look at your own text, see that you use both the words "appear" and "be", and then ponder the difference between /being/ random, and /appearing/ random (but being generated by an analytic funciton).

            • "encrypting anything random should also be random"

              In theory there's no difference between theory and practice, but in practice there is.

      • >. 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

      • Re: (Score:2)

        by AmiMoJo ( 196126 ) *

        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.

    • 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

    • 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)

    by Anonymous Coward

    "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)

      by ledow ( 319597 ) on Friday January 23, 2015 @11:30AM (#48885179) Homepage

      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)

        by Anonymous Coward

        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

      • Chuckle.

        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.

  • 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)

      by Azmodan ( 572615 )
      Teksavvy has unlimited uploads and 300gb downloads, FYI Not getting paid or anything, I'm a satisfied customer.
  • In theory there is no difference between theory and practice. In practice there is. Yogi Berra
    • I really didn't say everything I said. [...] Then again, I might have said 'em, but you never know. - Yogi Berra. In this case, he didn't.

  • 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

  • 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,

  • 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

  • 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)

    by Virtucon ( 127420 ) on Friday January 23, 2015 @12:28PM (#48885799)

    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.

  • 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.

  • Once a unbreakable encryption is developed the Gov. FBI, Police and others will demand key escrow otherwise "Goto Jail!"

Slashdot Top Deals

In the long run, every program becomes rococco, and then rubble. -- Alan Perlis

Close