Security Trade-offs of Cloud Backup

This is a good essay on the security trade-offs with cloud backup:

iCloud backups have not eliminated this problem, but they have made it far less common. This is, like almost everything in tech, a trade-off:

  • Your data is far safer from irretrievable loss if it is synced/backed up, regularly, to a cloud-based service.

  • Your data is more at risk of being stolen if it is synced/backed up, regularly, to a cloud-based service.

Ideally, the companies that provide such services minimize the risk of your account being hijacked while maximizing the simplicity and ease of setting it up and using it. But clearly these two goals are in conflict. There's no way around the fact that the proper balance is somewhere in between maximal security and minimal complexity.

Further, I would wager heavily that there are thousands and thousands more people who have been traumatized by irretrievable data loss (who would have been saved if they'd had cloud-based backups) than those who have been victimized by having their cloud-based accounts hijacked (who would have been saved if they had only stored their data locally on their devices).

It is thus, in my opinion, terribly irresponsible to advise people to blindly not trust Apple (or Google, or Dropbox, or Microsoft, etc.) with "any of your data" without emphasizing, clearly and adamantly, that by only storing their data on-device, they greatly increase the risk of losing everything.

It's true. For most people, the risk of data loss is greater than the risk of data theft.

Posted on September 25, 2014 at 2:17 PM • 80 Comments

Comments

Y?September 25, 2014 2:31 PM

(Naturally, when I say self-hosting I mean hosting in a different box from the one you need to back up -- say, a Raspberry Pi in your parents' house or your office, or whatever.)

Anonymous CowardSeptember 25, 2014 2:32 PM

What about the Feudal model of the internet? Isn't this indicative of a larger systemic problem? Can't the data backup problem be solved in better ways? Security analysis also needs to include comparison to alternatives.

Jan WillemSeptember 25, 2014 2:36 PM

I don't understand the article. It seems that the author only knows about cloud backup. I agree, backup is (very) important; but cloud backup is just one solution. A good one for private persons and (small) companies, but a major risk for large companies or governments.

Even for private persons there is a risk. If your name is (unknown to yourself) on some secret list of some country, your data will directly be sent for investigation.

As long as the DropBoxes of these world (including ICloud) can't guarantee (and prove) that there is no backdoor, the surveillance industry will try to spy on data for commercial win or otherwise.

carryonSeptember 25, 2014 2:50 PM

The article is a gigantic straw-man's fallacy. Imagine you send your kids to school one day, only to find that the teachers in that particular school are all child molesters. You naturally decide to stop sending your kids to that school. The article's author, on the other hand, would seem to say "but hang on a second, education is so important for your kids!" In other words, the author is assuming that in order to back up our data we have no other choice but to trust Apple or Google. That is simply not the case. These companies that leech off our data and have been exposed as active collaborators of anti-constitutional mass surveillance programs offer convenient solutions, but they are not, by any means, the only back up mechanism available (even for non-technical users).

JuhaniSeptember 25, 2014 2:58 PM

Please make a quick risk analysis on

Bittorrent Sync.

User generates a pretty long key. I am not able to analyze the algorithms. It seems to be closed so it might be impossible to verify the implementations (WEP).
Remote copies are not encrypted, but you can sync between personal computers / mobile phone - users can have physical control over the synced computers.

Bob S.September 25, 2014 3:03 PM

Backups have always been important, usually a lesson learned the hard way, maybe more than once.

There are at home cloud clients and devices appearing on the market which seem quite good and of course if handled correctly completely eliminate any possible leakage instigated by corporate/government theft.

C04September 25, 2014 3:07 PM

@SJ, Don't all "Forgot your password?" buttons just send an automatic request to the NSA Utah data center? ;-)

Benjamin SchwarzSeptember 25, 2014 3:12 PM

I agree with the other commenters. Cloud backup is only one of the possible backup solutions, and even this solution can be done right. The idea of Mega for example is that your backups are encrypted on your computer and then uploaded to their servers. I didn't yet look at their implementation, so it could be completely broken in their specific case, but the concept is a good one. Even if your account gets hacked, the attacker can only get encrypted files and keys, which are completely worthless. While doing this, the Mega website and client programs are still as easy to use as any cloud provider's.

ScaredSeptember 25, 2014 3:14 PM

With a price of around $100 for a 3TB external HD, what do you need cloud storage for?
A nuclear war, a magnitude 8 earthquake?

CarlosSeptember 25, 2014 3:17 PM

What about external disk backups in your own house? Or what about encrypting your backup data and sending it to the cloud?

I like the idea of encrypting the backup at the client side before sending it to the cloud. I personally use an encrypted external hard disk for automatic backups. But if somebody breaks in and steals all my devices, or if a big flood destroy all my devices, I'm in trouble.

SJSeptember 25, 2014 3:23 PM

@C04: I never knew about the passwords....

As for backups: BitTorrent Sync is a nice too which can synchronize folders accross (almost) all devices... Windows, Linux, Android, OS X, iOS..... it's easy to setup and works fine.

So you could for example use an external drive at work for a backup... if you can't use the work network directly, you can still do it with a small raspberry pi, external harddisk and a usb wifi dongle and tether it to your phone (having LTE or wifi)...

Or just put a small raspberry pi at your parents' or kids' place... or some good neighbours and to the same for them...

Well, if you want decentralized backups of course.

Bruce SchneierSeptember 25, 2014 3:43 PM

"With a price of around $100 for a 3TB external HD, what do you need cloud storage for?"

My mother would never, in a million years, know what to do with a 3TB external HD. She needs cloud backup, because for her there is no other kind. (Unless I am her sysadmin.)

squarooticusSeptember 25, 2014 4:04 PM

Chris:

Just use the framistat to hide your data in the bilateral kelilactiral before pushing it to the feromantle drive. But don't press that button, or you'll blow up the entire feromantle drive.

This is as intelligible to most computer users as your post. These people need backups, too, and it's not reasonable to suggest that everyone become an expert on security to use cloud services.

Jesse ShapiroSeptember 25, 2014 4:06 PM

I think a lot of commenters here are missing the point- it's not about "Are there more secure ways to backup your data?" The answer to that question is unequivocally "yes".

It's about "Which way does the balance between privacy and protection of data swing when it comes to backing data up to cloud services?"

And the answer, for the vast majority of people, is that the potential privacy tradeoff is worthwhile.

I work for $COMPANY. We make $PRODUCT that backs our customers' computers up over the network, automatically, whenever they're connected. $PRODUCT is a bit pricey, compared to a standard external drive, which can be easily used for backups. But, to use a normal external, the customer has to actively choose to plug it in and back up regularly.

In comparison, $PRODUCT requires no interaction to do its job, so backups are more consistent and secure. It's the same kind of tradeoff as the article talks about, except it's money/data retention instead of data privacy/data retention.

RichardSeptember 25, 2014 4:06 PM

Bruce, you didn't preface the post with a disclaimer that your mother had to be able to do it but that is a good standard for the masses. Still, there are easy alternatives to cloud based backup.

I agree with others, local hard disk based backups are easy to do (maybe your mother could handle Time Machine) and i like to make mine bootable (SuperDuper! on the Mac) so if something happens to my machine I can boot another machine from my backup.

I make two (we heat with wood) and keep one in a fireproof box in the basement. I swap them daily.

StefanSeptember 25, 2014 4:16 PM

What about addressing the risks inherent in trying to secure and manage your own infrastructure, if not going with the cloud?

It is commonly accepted that many people and organizations do not make much of an effort to keep systems, devices, and applications up to date.

Is your non-cloud backup solution's security infrastructure equivalent to an SSAE-16 SOC2 or SOC3 cloud provider's? Do you regularly audit it?

I'd rather place my data in the hands of a team with some accountability should it get compromised. Finally, a physical drive is easy to lose, break, or be stolen. It's pretty tough to lose a data center, and they have loads of redundancy. Worried about it getting stolen in the cloud? Encrypt your backups.

DanielSeptember 25, 2014 4:22 PM

"It's true, For most people, the risk of data loss is greater than the risk of data theft."

This statement borders on being disingenuous. It's true enough with one major caveat--based upon people's current valuation of their privacy. Risk--as I constantly remind people--is probability times loss. So in every risk assessment there is an implied value judgement, since not everyone values loss in the same way. Overall, I'd argue that most people, especially older folks who grew up in a different generation, tend to undervalue their privacy.

Taylor Swift (the singer/songwriter) had some interesting comments about privacy in the recent interview she gave to Rolling Stone. She talked about how she scans every restroom for cameras because there is value to pictures of her naked body--that is to say their is value to her loss of privacy. One way to gloss her statements is to view them as the exception to Bruce's rule. But I think a more accurate gloss is to suggest that young people in general tend to understand that privacy has value in a way that many older people simply don't. Bruce's mom didn't grow up in an era of up-skirting, hacked phones, and Snapchat

So Bruce's comment is kind of a half truth for people of a certain generation; I think it's true now but I don't think it will be true a decade from now.

GGYSeptember 25, 2014 5:35 PM

I have a good number of customers with a wide ranging skill set from the nerdy type that thinks he knows everything but still calls someone else when its really broken to the 80 year old grandma who just wants email access and to look at some photo's of the grand children.

I have in the past recommended everything from DVD Backups to USB Drives and NAS boxes with various customized robocopy scripts. Just leave them with an icon above the start button, call it 'Backup & Shutdown' and tell them to click this to turn the computer off and it will robocopy data to the backup whatever and turn the computer off and it will all be fine.....

Turns out Bruce is right... one mouse click is too much... On every recovery I had to do because a hard disk failed / laptop dropped the backup was ALWAYS significantly out of date. (stick it in the start-up group and the good data gets overwritten by the bad at the next boot-up)

I'm now recommending Backblaze. They give you the opportunity to manage your own encryption key yourself, but I suppose its a trust thing that they are using my provided key and not storing it / leaking it to uncle Sam or not just pretending the self managed encryption key is actually doing something other than prompting me for it when I need to do a restore :-)

I'd prefer if if they offered two factor authentication to access a restore though.

The above is all ok for the ordinary user because for the most part its at the limit of what they can understand.

For the 'us' there are many great ways to build these services ourselves, and Owncloud box on a friends network maybe, or I quote like the idea of the Connected Data Transporter boxes, but it is closed source and there is the trust thing again. But the ability to buy, set-up, local sync, ship to a mate, who plugs it in, no NAT'ing, no DYNDNS sounds mighty tempting...

Sancho_PSeptember 25, 2014 6:30 PM

”My mother would never, in a million years, know what to do with a 3TB external HD. She needs cloud backup, because for her there is no other kind. (Unless I am her sysadmin.)”
[Bruce Schneier]

No problem with a cloud backup until your mom’s device encrypts it before sending.

The bank is liable for my money.
The storage provider is liable for my furniture.
The storage provider is liable for my Data.
When the data was (unencrypted) stolen (20.000+ wrong pwd) the service is liable.
They are the experts who make money from using their service, not your mom.
Accountability is the missing word in the law.

Now we come to the key question: Where is the key?
On the damaged / stolen device only?

*****

I also somehow disagree with:
For most people, the risk of data loss is greater than the risk of data theft.
If that’s true it would be a bad perception.

I think for ordinary people the risk of abuse of data is greater than risk of data loss.
What you need are real friends, not data (you’d find out after a serious heart attack / stroke).

As CGY wrote, most backups are out of date. Who was physically hurt by that fact?

Anonymous CowardSeptember 25, 2014 6:49 PM

@Schneier

The problem is that you're presenting a false dichotomy. How about software and hardware at home that automatically backs up data from personal devices?

DazSeptember 25, 2014 8:15 PM

I'm more or less safe from both. I always keep local copies of my data. Plus before I upload anything to the cloud, I have a 7zip batch script that encrypts my synced folder with AES256 and a password before its been uploaded to the cloud.

UbeSeptember 25, 2014 8:24 PM

Is anyone else astonished that Bruce's mom isn't the Henrietta Lange of computing/security?????? I'd really imagined that if she could do it, it'd be waaaay over the heads of the rest of us, not the reverse.

Chris AbbottSeptember 25, 2014 8:55 PM

@squarooticus

You're right. People need simple solutions. I would like a cloud backup service that provides an application that encrypts data on the client-side (hence giving no outside access to the key). 'Enter your password' is easy enough for people to understand.

AdrianSeptember 25, 2014 11:01 PM

I'm not understanding the difficulty here. If we encrypt our data client side, then we shouldn't be worried about a cloud service we don't trust.

ThothSeptember 26, 2014 12:21 AM

@Juhani
I have previously in one of my post pointed out a possible flaw in Bittorrent Sync's protocol. In simply, the PEX protocol where you announce your presence "SHA1(key):ip:port" as described here (https://www.getsync.com/tech-specs). Sync operates on a symmetric secret key protocol (key maybe randomized after use if I remember correctly). Now, you hash your key and announce your IP address and Port number. It is not a very clever move. Firstly, you expose your intentions, your IP address (identity) and you open a port. If someone intercepts ... really ... you are over. What makes it even worse is you tell the world a hash of your secret key and if you don't randomize it after use, someone's gonna figure it out sooner or later (especially ISP and TLAs working with huge resource and have the motivation to deanonymize and crush anyone using crypto).

Sending a key in hash or obsfucated format just like that is a bad idea. The best approach is a permutation of the shared symmetric key in a predictable manner for the session key. I have created a protocol to correct it here (https://bitbucket.org/geraldtay/shasex/wiki/SHASEX) but it doesn't protect if either ends have the secret key compromised.

The idea of end-to-end distributed encrypted storage is not new and there are stuff like MaidSafe (http://maidsafe.net/).

Cloud storage convenient and security have always been contradicting and has always been an issue. If you don't care about being TLA-secure, just use encryption on your files and load them to the cloud but bearing in mind it's dangers. Running your own cloud can be technically challenging and dangerous if misconfigued but it's still not secure against state actors. 7zip with AES-256 encryption before loading onto the cloud would be very convenient as it's a normal 7zip encrypted archive.

For those who are too lazy to 7zip encrypt/Truecrypt/LUKS/whatever-crypt and upload to cloud/Dropbox/whatever-box, you can use CryptSync (http://stefanstools.sourceforge.net/CryptSync.html). It works with Dropbox and how it works is by specifying a directory as a target for sync-ing and all the items in it will be 7zip compressed and encrypted with a password of your choice and uploaded.

IF you are security minded, always make 2 or more images of your backup at a regular interval, timestamp them (and signed with a PGP key). Encryption would be helpful. Do the backup when disconnected from any network and quickly dismount the backup drives once done. This will give some form of air-gap for a short while and is good against low level state actors but if you want more assurance, add a read only hardware setup (data diode/guard) between your target machine and backup drive so that exfiltration of backup materials would be harder.

CSWSeptember 26, 2014 1:37 AM

Yup. The pain felt more when data loses compare to data theft. That's just me maybe. However in my cloudstoragewizard, I had lost all the data without backing them up. So, that's one of the experience that I do not want to go thru again. It's true that we cannot blindly against iCloud or any other cloud provider just because of a single incident, we just hope that they will increase the security and features from time to time to counter this kind of hacking problems.

Danny MoulesSeptember 26, 2014 4:20 AM

"For most people, the risk of data loss is greater than the risk of data theft."

The likelihood, certainly. The severity? Arguably not. Losing your credit card details because you didn't back them up isn't a big deal. Losing your credit cards details to a silent theft generally _is_, even if it happens less frequently.

rj07thomasSeptember 26, 2014 4:36 AM

@carryon: I'm not sure I agree, plus I think picking a school full of paedophile teachers is extreme but I get your point. I think the article is saying (a) don't mistrust all cloud backups based on one leak- which translates to "don't mistrust all schools and all teachers" in your example- and (b) backup IS security. For example, one form of data loss can be data theft- say, stealing your laptop. Having a backup doesn't prevent someone having that data, but it does mean you can get your data back. Plus, cloud backup is way easier than most other forms even though I don't particularly like it.

For years- being a techy- I've backed stuff up onto a usb disk at home (using O&O DiskImage which is excellent), taken that to work, then copied it to a similar sized usb disk which never leaves my work place, therefore achieving some level of off-site backup.

I picked different vendors for the 2 disks hoping to mitigate problems with any one batch of disks, but the whole process is awkward. I could have a storage box of some sort at home but that wouldn't mitigate against fire, for example.

I could keep my storage box in someone else's house- friend or family- but the likelihood of someone successfully breaking in and obtaining my storage is, I'd assume, vastly greater than someone successfully breaking into a cloud datacentre.

Cloud backup is not perfect, but it's a relatively good way of certainly getting off-site backup (for most people). Like anything else it's a risk, but risks have to be balanced. I can't think of a decent way to have off-site backup of home stuff so the cloud provides this, whereas I could keep everything wrapped up at home but this incurs other risks.

triensSeptember 26, 2014 4:38 AM

@Nick P, Chris Abbott: Careful, SpiderOak claims that they do not have access to the key used to encrypt the files client-side, which strictly speaking is true, but that key is the same one as the password used to log on to their website (e.g. when you open & manage your account). SpiderOak therefore store your hash in their system whenever you have a web session open with them. A court order would force them to intercept this and hand the information over to LEAs, who will be easily able to decrypt your files.

t3at4September 26, 2014 4:47 AM

@triens:

", SpiderOak claims that they do not have access to the key used to encrypt the files client-side, which strictly speaking is true,"

I wouldn't even go as far as that. SpiderOak is proprietary code that has had no public audit from any reputable organization. I have no way of knowing whether or not their code is really doing what it claims. Given the number of open-source backup solutions (decentralized and / or based outside the USA) with client side encryption, I'd stay well clear of SpiderOak.

rj07thomasSeptember 26, 2014 4:55 AM

and @Chris Abbott/ Adrian: yeah, client side encryption would be easiest, just wish my Inspiron 1545 had come with W7 Enterprise (impossible) and had a tpm chip!

It did at least come with an Absolute chip, but that's only any good once it's been stolen.

@Anonymous Coward: having a brilliant system at home doesn't help in the case of severe fire/ flood/ break in. Any of these are likely to lead to total loss of source data and backup (although in the case of theft, at least the data would be unreadable).

At the end of the day, cloud backup offers immense physical security with a large attack surface which needs to be guarded. Home backup offers a much smaller attack surface but with greatly weakened physical security. As a few people have mentioned, end-to-end object encryption is really the only good solution but even then there are risks such has loss of keys or passwords (if a laptop gets stolen and the cloud data is protected by some password that was only accessible on the laptop, that's a hard place to be in).

I wonder if my bank would let me drill a small hole through their vault wall to run a Cat6 cable through?

TomSeptember 26, 2014 6:37 AM

I'm one of those "most people". Indeed my biggest problem with data "stolen" would be if the attacker actually deleted my data in the cloud. Copying? I could live with that.

For most people, the best solution is simply to move the Windows "My files" folder location to Dropbox.

JimHSeptember 26, 2014 7:53 AM

"For most people, the risk of data loss is greater than the risk of data theft"

Is is really always theft when someone takes your data from cloud? And will it stay that way? Or will Big Data/Government, etc. interests gradually redefine it otherwise?

BJPSeptember 26, 2014 8:01 AM

Just for all those folks with manual processes, have you looked into the "duplicity" tool? It does rsync/rdiff style encrypted backup to various backends, whether local filesystems, NAS mounts, S3, WebDAV, and so on. This doesn't fix the "you have to remember to plug in the external drive" issue, but I've found it a great solution for many problems.

DBSeptember 26, 2014 8:57 AM

@Bruce Schneier

"My mother would never, in a million years, know what to do with a 3TB external HD. She needs cloud backup, because for her there is no other kind. (Unless I am her sysadmin.)"

There are backup programs that are as simple to use as pluggining the drive in once setup. And the setup is easier than the setup for any cloud backup too, no registration/login/password. One in particular is Time Machine, which comes with a certain OS too.

So cloud backup is not the only option even for your mother. It's just the only one you know about. Which is why criticism of the article for not presenting other options is valid.

CallMeLateForSupperSeptember 26, 2014 9:59 AM

"Your data is far safer from irretrievable loss if it is synced/backed up, regularly, to a cloud-based service.

"Far safer" than ... what?

Since the article makes no distinction between businesses and individuals, a response from an undividual is relevant. I believe *my* data is far safer from BOTH irretrievable loss AND theft because it is backed up regularly and the backups are stored under my physical control. That is, I do not essentially gift my data to some uninterested party, because recent history has shown many times that such parties *silently* cough up data to third parties, which I consider to be as despicable as theft.

MiksaSeptember 26, 2014 10:20 AM

There is talk about using external harddrives or building your own cloud backup system. but we need to remember that the data in question may contain your children's childhood photos and videos, which are completely irreplacable. Your bank account getting emptied is a minor issue in comparison.

And the disaster scenario we need to prepare for is your house burning to the ground. An offsite backup is an absolute requirement. Richard mentioned about keeping the other backup drive in a fireproof box, but I suspect "fireproof" means that papers stored in there would survive for several hours during housefire. I wouldn't rely on it to keep a harddrive intact. Unless the manufacturer has certified that the inside temperature stays well below 100°C during a prolonged fire, 5-10 hours. Richard also has the diligence to switch the harddrive delay. I don't. I upload my photos and videos to my website hosting where everything is publicly viewable if someone knows the address, my mp3 collection I copy to a separate harddrive maybe once a year and for the rest I rely on RAID-6 and hope for the best.

Most people, like me, would probably need a set-it-and-forget-it cloud backup solution for the backups to be useful. As a plus the backups would be encrypted before sending them to the cloud and the software would print the key with big red letters telling you to store the paper in a bank vault. Even better if the backup software is open source so it can be verified.

Setting your own cloud has most the issues as third party clouds, unless you own a separate building where you can house the cloud servers behind locked doors. Or your parents basement can be good too. This prevents the cloud service provider from accessing your backups, but it will be more work to keep the others away from them.

Nick PSeptember 26, 2014 10:29 AM

@ triens

Nothing in the U.S. is legally allowed to totally block authorities from doing a lawful search. Also, the TLA's here are very powerful: they use bribery, coercion, and fronts on both local and foreign companies. The vast majority of readers aren't worried about that risk. So, privacy-centric services like SpiderOak are a decent choice if security, offsite, convenience, and low cost are all in the picture.

People worried about TLA's should also remember they mainly attack endpoints. Even if SpiderOak was perfection, it still wouldn't protect you from any TLA partnered with NSA. Or Russia/China for that matter. There's ways to do it but I assure you the market is *extremely* small. Nobody would recover the costs and so far FOSS isn't making any progress on assurance either.

@ Miksa

Fire safe?

WallendaarSeptember 26, 2014 10:49 AM

The data may be lost in the 'cloud' too, if the vendor decides your activity or files look fishy. A friend of mine had nearly lost his e-mail archive when Google decided that he is probably a spammer/scammer/whatever. 'The account is suspended, go deal with tech support.' The tech support was of no help. If there were no locally kept copies of his archive, he'd be damned.

I wouldn't rely on 'cloud' too much. All your data is at mercy of your vendor, plus it will almost definitely be data-mined because of cp\copyrighted materiel\marketing\etc ad nauseam. Maybe as a secondary/tertiary backupping method but not as primary.

Nick PSeptember 26, 2014 10:55 AM

@ Wallendaar

That's a good point. Perhaps the best option would be a small, convenient storage appliance that syncs to a cloud. So, the backup is local, recovery is fast, and cloud issues don't loose the data. However, if the system fails or a local disaster occurs, the cloud backup covers that situation. The hard disk should also be replaceable in event it wears out.

Note: I'm pretty sure these already exist in backup solutions. I'm just saying turn it onto a convenient, cheap, consumer device.

markSeptember 26, 2014 11:42 AM

I am *not* a fan of the cloud, esp. where significant data's concerned.

Let's note in passing that last year or so, the UK government decided to *not* move a lot of its data to the cloud... because they could not be guaranteed that UK government data would be on UK soil.

I work for a US federal contractor. In our division, we have *internal* firewalls, behind which are the servers which may have HIPAA and PII data. Everyone who works on them is required to have some training on securing that data. I, the couple other admins, and our manager are *required* to have a "Position of trust" security clearance.

You want to tell me that any cloud provider is going to guarantee that all the folks who have access to the cloud servers and storage with that data *all* have clearance, and annual refreshers?

For that matter, if you're a company, esp. bidding on contracts, do *you* want to hope that everyone who deals with the cloud servers that your financials and bids and such are on is trustworthy, and it's all secure?

And if you're sure about that, I have this great little moneymaker for sale, it's a bridge in a northeastern city, and all you need to do is set up a toll booth....

mark

keinerSeptember 26, 2014 2:25 PM

It's a simple calculation to estimate the risk for this trade-off. As long as you have RELIABLE data on the risk of loosing your data in the cloud. If you are a European company, an educated guess gives me a 100% risk to loose my data to US rivals via NSA/CIA...

SasparillaSeptember 26, 2014 3:03 PM

Great article and comments. Have a father in law about to get 1st smartphone and am trying to figure out a strategy for backups (phone and computer) for him. He has a multi drive computer (my doing) and will probably go for local phone backups copied to both drives with certain live phone data taken to the cloud (with the assumption the feds could get the cloud data whenever they want).

Great point brought up by others, things like your photo collection (and other data) are irreplaceable and having an offsite backup is really required (a fire/theft wipes your local copies out).

The other thing here is that alot of photo collections are truly massive in size and many folks have the cheapest slowest Internet connections they could get by with (my father in law being one of them) - i.e. uploading such a thing to the cloud for backup just isn't feasible with a slow connection.

Backing the photo collection up to M Disc blu-rays and storing at another site would be an option. Then maybe SpiderOak for the small stuff for him. I could be the support that.

Peter A.September 26, 2014 3:09 PM

Most of the commenters miss the actual topic of the article - is a factory-built-in (almost-)zero-configuration backup of a consumer device a GoodThing(TM) or not.

It is. For those people who don't know what a backup is or won't be able to set it up or won't be bothered until too late.

For all the other even only slightly technical people there are lots of options to choose from and nearly infinite number of strategies to take.

DanielSeptember 26, 2014 4:18 PM

@Peter A.

That only true if one assumes that those who are ignorant of technology have no interest in privacy. But they do. Sometimes they don't know they do until it is too late. :-*

JuhaniSeptember 26, 2014 4:59 PM


How can we objectively measure the risks of cloud backup vs usb disk backup?

@Thoth

Bittorrent Sync does have time stamped keys, valid for 1 day. They probably don't need another homecooked timestamp algorithm.

It has
20 byte master key,
20 byte public sha-1,
32 byte? public key authentication.

Can we get a 32 byte reasonably strong authentication for that usage (slow brute force?) from a 20 byte + 12 byte key that has to include timestamp (for time limited read-only key)?

I am a bit lost and confused.

AnuraSeptember 26, 2014 5:18 PM

I think we should design a distributed, anonymous, peer-to-peer backup system where everyone devotes space to redundant copies of other people's data. Here's the thing, if you are designing a system specifically so that anyone can get the containers that store the data, but can't decrypt them, then you are going to pay a hell of a lot more attention to security than someone who is making a SaaS behind non-publically accessible (in theory) servers.

I think this is one of the big failures of in-house/closed source security, the illusion that because it's not public, it's safe. How often do we get software with remote access via a password hardcoded into the binaries? Well, if they are compiled, you can't read them, right? It's the same concept here; you should develop assuming that the attackers have direct access to all of your code and servers.

MiksaSeptember 26, 2014 5:23 PM

@ Nick P
My understanding is that fire safe doesn't protect against fire as well as the name implies. I believe they are mainly designed for storing paper. Seems that the ETL 90min test requires that the temperature reaches 350F at most.

@ Wallendaar
That's what backups are for. If your data is in the cloud then you need to store the backups locally or separate cloud. Or if the data is local then you need to backup to the cloud. Theoretically the cloud provider may take backups. But since the backups are behind the same account it's a single point of failure and they don't count.

@ Sasparilla
Slow internet may not be a deal breaker if you can do the initial backup with some other transfer, for example external drives and someone else's internet. After that you just backup new and change data over the slow connection.


Companies have come up in several comments, but this article doesn't really concern them. Companies often have several locations and they can build their own offsite backup system. If nothing else there's always the CEO's basement. Consumers usually have to use cloud, unless you store the backup server in your parent's basement.

ThothSeptember 26, 2014 7:06 PM

@Juhani
I don't care how strong your keys are, the protocol LEAKS the secret keys. That's the worst part of a homebrew protocol like Bittorrent Sync. Why is the PEX leaking the SHA1 of the symmetric keys ? It is as good as saying to the world your keys' SHA1 format which if someone wirth the ability to listen on the network for sometime maybe able to figure out (especially if you don't randomize keys after each use). If you want to do a shared secret over a multicast network, don't broadcast your secret key or hashed secret key.

I have this prickly feeling I always have since a few years ago and have this suspicion I hope Nick P, Clive Robinson and Bruce Schneier can clarify. A set of bits/bytes use for symmetric and asymmetric keyspace is a finite set of elements (in the sense of maths). So many of us have been using key generations knowingly or unknowingly for sometime. What's the likelihood the exact keys may have been inadvertently be generated (due to weak RNGs or bad seeding) ? Let's say if NSA could use their programs to inntercept any keys, generate any random keys, capture any keys that have been surrendered to LEA/TLAs over the years and build a rainbow table with their immense resources and capabilities, how likely are we going to generate keys within a finite keyspace that somehow may reside in NSA's rainbow tables ?

Just for abit of commercial end-to-end crypto love, I have personally seen commercial end-to-end crypto protocols sold to payment industry for their end-to-end business critical operations that maybe susceptible to side channel attacks and also replay attacks. I was shaking my head when I was reviewing the source codes. Even the security industry do not always get their assurance and security level done properly, let alone homebrew crypto protocols like Bittorrent Sync who are not a crypto/security company by their blueprints.

@Nick P and all
Here is a schematic I have thought of for your higher assurance backup.

You will need 2 physical modules with network/serial connection on 2 ends of each modules. Each module will have a connection to a hard disk and a connection to your working computer. You will need to generate a SafeCurve ECC key pair that is verified safe by Daniel J Bernstein. Reason for ECC key pair is it's much more compact and faster than vanilla RSA key pairs.

Decide which of your module to be the Read module and which is the Write module. In the Read module, load the private key and Write module, the public key.

When reading files, plug your external disk to the Read module and connect the Read module to your computer. Send a command to read data to the Read module which will have the program logic to read and decrypt within the Read module and pass you the plaintext.

When writing files, plug your external disk to the Write module and connect the Write module to your computer. Send a command to write files to the Write module which will have the program logic to write and encrypt the files inside the Write module and will do the writing to external storage for you.

I have not defined a set of protocol to interact with the modules and the logic program within the modules but the essential idea is to create a homebrewed data diode or guard for you to backup your stuff in encrypted format.

tzSeptember 26, 2014 7:14 PM

The only missing piece is having a backup password encrypting what is in iCloud so that without it, the files are gibberish, i.e. so Apple could not help law enforcement with iCloud blobs any more than they can now do with iOS 8.

I don't particularly like Apple, but if they ever introduce "trust no one" "pre-internet encryption" for iCloud, I would get an iPhone the same day.

(I'd clone my hard drive, install iTunes, activate and set-up things, then securely erase to destroy the paring record).

There are two functions for the cloud: Archiving and Mirroring. They are different.

If I want every picture I've ever taken to be safe, I need archiving.

If I want to restore the state and/or context for a device, I need mirroring.

On the iOS8 device, I need to enter my passcode to decrypt things.

On iCloud, there is NO encryption.

p. aranoid.September 26, 2014 10:24 PM

@steve37:

But this also can a kind of theater.

Yup, sort of like an attempt to get criminals to spill their guts.

Otherwise I would be surprised on how come The Empire has not done anything to protect its children from potential pedophiles?

Don't they think someone will now be saving their cr*p specifically on Apple devices?

Or is The Empire losing its control?

Jonathan WilsonSeptember 27, 2014 12:56 AM

I recon there is a good market out there for someone like WD or Segate to make (if they haven't already done so) something that is basically a nice big USB external disk along with some simple plug-and-play backup software.

Something that's as easy for the clueless users (without geeks in the family to help them) to use as the cloud solutions but without the ongoing costs or privacy/security issues involved with the cloud solutions.

Ask MarkSeptember 27, 2014 5:42 AM

There is no such thing as a secure cloud backup provided by TrustedCompany Inc - how ever, a thing called decentralized file system shouldn't be an impossibility. Things like Tahoe-LAFS seems interesting.

We, the good guys have nothing to hide, yet still most of us wear clothes, some of us close the door when going to bathroom, the most alarmed tinfoilhats quiet themselves down when talking serious or confidental things with their friends. Is that a crime? I think our moms can understand this logics, and we should talk about the issue to them _in their language_.

We the techies have a responsibility. Now that we understand our tech and it's implications, and we do have things like encryption and decentralized services like d*, status.net and all those - now we need to focus with our understanding towards useful, relevant things and practices which our moms can - and are very willing to use - even if mom doesn't understand how the thing does what it does. Wether it's written in python or brainf*ck is irrelevant to them.

TõnisSeptember 27, 2014 6:39 AM

The only things I use Box/cloud for are the very few things I'm willing to share with select individuals and/or the world (e.g. on web sites). I realize one could encrypt the stuff he stores there, but people for whom cloud services seem to be ideal are consumers who don't know how (and won't bother to learn) how to do this, for whom anyway security is "too hard." Besides, encryption could impede their narcissistic sharing with the entire population of the planet.

At this point, I only have about twelve gb of data I really care about, and that data is backed up off site ... in my back pocket. I have a 32 gb micro sd card in my BlackBerry Q10, and the data is backed up in encrypted form on the card. I have mobile access to all the data on my computer using BlackBerry Link's secure Remote File Access feature. If I forget a file at home, no big deal. I can get it right over the air using this terrific feature. In these past few days BlackBerry came out with a new handset, the Passport, which can take advantage of a similar program called BlackBerry Blend which allows the user to access the files, presentations, etc. he puts in Blend over multiple devices cross-platform. The BlackBerry Passport user can now access the files stored on his handset (in Blend) from his iPad, Android tablet, other laptops, etc. securely using Blend. There's the other way for intelligent consumers for who care about secure file access and who don't immediately have the knee-jerk reaction, "Security is too hard!"

In any case, the more options, the better. I love the external hdd idea. Keep forgetting to pick one of these up. Will do it soon.

Nick PSeptember 27, 2014 10:57 AM

re secure cloud storage scheme

Secure online storage schemes are actually numerous in academia. It's one of those situations where there's no lack of methods that might work: just a lack of effort turning it into a product or FOSS release. Anyone that wants to see examples should put into Google the words "secure" "storage" with one of these project names: OceanStore, ObliviStore, POTSHARDS, SecureDropbox, FadeVersion, Resilient Cloud Storage Services, Depot, and Fabric. That's just a few from a search on my PC (dated 2012) so I'm sure there's more by now.

Nick PSeptember 27, 2014 11:55 AM

@ Thoth

It's not necessary to have separate modules. This is the kind of job best served by our trusty old construct: the guard. The guard mediates read and write access. The host and storage device are connected to it, separation enforced by hardware or software. It has a trusted path to the user. The guard enforces an append-only storage rule by default, only overwriting or deleting backups with admin permission. The system logs backups, recoveries, etc onto append-only storage as well. The system can optionally encrypt backups for confidentiality, but will always hash them for integrity. The device can also be an embedded board inside a desktop.

Hell, the device can even be an interface to the primary storage system with the backups being a separate partition and it enforces separation. There was an Australian product, certified by their DSD, that similarly put a reference monitor in the hard disk enforcing per-partition and per-user policies. It was for laptops. So, I'm sure my desktop, server, or network-attached appliance version would be easier given the variety of hardware available.

JustinSeptember 27, 2014 3:44 PM

I generally agree with Bruce, but he really dropped the ball on this one by presenting the false dichotomy that you somehow have to choose either the off-site protection and convince of cloud based storage OR security.

Huh????

Last time I looked Bruce, there was something called encryption available that if applied correctly would eliminate the requirement to make this false choice by insuring that your remote cloud storage data remains secure from both data loss due to mishap and data theft.

I'm pretty sure that this is true, because I read it a long time ago in this cool book called 'Applied Cryptography' which was written by this really smart guy who seemed to know what he was talking about.

In the case of cloud storage, applying encryption correctly means not trusting blindly in the 'helpful' but essentially useless security measures provide by the server, and simply adopting the common sense measure of pre-encrypting any sensitive data you plan to store on the cloud before uploading it.

You can either use a compression utility like winzip or 7-zip to archive the files, then bulk encrypt them with a tool like PGP or Openssl, then upload them to the cloud as encrypted archives, or if you want the convenience of an encrypted cloud storage drive, you can use the default cloud drive driver provided by Google, Dropbox etc, to host the file container for an encrypted Truecrypt or dmcrypt drive.

When choosing an encryption mode, I would favor dual encryption modes like AES->Twofish when possible over simple modes like AES Counter.

When command line encrypting with Openssl, there is no built in support for multiple encryption modes, and Twofish isn't usually available as an option, but it's fairly easy to create a RC4 | AES-CBC | RC4 super-encryption pipeline by piping your data throug multiple instances of Openssl with a simple stdout to stdin pipe operator '|' in a shell script or batch file.

Sancho_PSeptember 27, 2014 6:01 PM

@ Justin: "Huh????"

+1
I had a similar feeling. But how do we know it’s the same man ?

Or what convinced him to cheer that essay, together with calling it a “security trade-off”?

I’ve heard that some “lobby” could be very convincing :-(
Or his mom could be the reason (Bruce, my iPad is broken, can you help?) ;-)

Or was it the simple fact that this unencrypted mistake, the serious issue known since May [1],
was engineered by the world’s leading technology manufacturer?

A factory built in automated backup even for “mom” _is_ superb: Only IF …

Yet we have to acknowledge that it was a long way from the first bicycle to what you can buy today.

And it still sucks when you fall down.

[1] http://www.dailydot.com/technology/apple-icloud-brute-force-attack-march/

Nick PSeptember 27, 2014 6:27 PM

Justin busts Bruce out as a cryptographer. He then recommends a multicipher design relying heavily on RC4: the weakest, most beaten down of available stream ciphers. Funny stuff.

MiksaSeptember 27, 2014 6:46 PM

@ Justin

Your missing the point. This article wasn't talking about whether it is possible to store data in the cloud securely. The articles message is that it is better to backup your data to the cloud even if it's not completely secure, than not backup the data at all.

All the schemes you suggested are just stuff the normal people can't be bothered to do. But luckily the DropBox client on their cellphones will automatically upload their pictures to the cloud, so at least those are safe.

JustinSeptember 27, 2014 8:53 PM

@Nick P

The cipher I suggested, RC4-> AES-CBC -> RC4, may be slight overkill - a single encryption of AES-CBC, followed by a single layer of RC4 would probably suffice, but RC4-> AES-CBC-> RC4 is still faster than Triple DES and quite practical - and quite strong cryptographically.

So far as your comments about RC4 being one of the most 'weak' and 'beaten down' ciphers go...

RC4 has been subject to cryptanalysis for two decades, it's strengths and weaknesses are well understood.

The implementations where RC4 were 'beaten down' as you so quaintly put it were poorly designed from the start.

For example in the WEP RC4 protocol, the designers stupidly opted for a concatenated IV||Key format that is inherently vulnerable to key recovery attacks, and then compounded this stupidity by not heeding the advice by RC4's author that the first cycle or two of RC4's keystream should be discarded.

Please note that, absent EITHER of these stupid mistakes, RC4 would have remained secure in WEP.

In the case of the theoretical break against RC4 as used in TLS - again, the designers of the RC4 TLS protocol did not heed the advice to discard the first round or two of RC4's keystream - and then compounded this stupidity by configuring the protocol such that it allows millions of identical plain text messages to be encrypted repeatedly with RC4, which allows the attacker to exploit the small biases in randomness shown by RC4 in the first few rounds.

Had the designers of the RC4 TLS implementation simply discarded a round or two of keystream output as recommended - or alternately, had the brains to set up an intrusion detection trap against massive retries on the same encrypted content (a good idea from a denial-of-service attack perspective anyway) then,

Once again, absent either one of these errors RC4 would still be secure in TLS.

So, if RC4 is 'weak' and 'beaten down' because it has been found vulnerable in these badly engineered protocols, then I guess that AES must also be considered 'weak' and 'beaten down' as well since it has been attacked successfully in both the BEAST attack, and numerous side channel attacks that are implementation specific.

Interestingly, even given the weakness of the flawed RC4 TLS implementation, when AES (as well as other block ciphers) were found vulnerable to the BEAST attack, most web sites fell back once again to good ol' RC4.

I suggested RC4 -> AES-CBC -> RC4 composite for use with Openssl where the RC4 implementation uses a hashed key that is NOT vulnerable to a WEP style key recovery attack, so that attack mode is off the table.

- and the RC4 -> AES-CBC -> RC4 triple encryption stack I recommended, uses the excellent statistical properties of AES to 'whiten' RC4, which would render any statistical attack on the composite cipher impossible, even with a trillion trillion TLS style encryptions - so that attack is also off the table.

So, RC4 is quite strong in the composite cipher I recommended, but given it's current bad rap, and admittedly temperamental nature, why use this cipher at all? What does RC4 contribute?

First, RC4 contributes the fact that, absent some really stupid implementation errors, it has remained amazingly resistant to cryptanalysis for more than 20 years, and it's HUGE internal state (256! ~ 10^506 or about 1700 bits equivalent) offsets AES's inherent weakness of a small state and simple algebraic structure.

So in the composite lash up cipher I suggested, each ciphers strengths complement each other, while their weaknesses quite nicely cancel out, which is EXACTLY what you want in a composite super-encryption cipher chain.

I think that NSA has been doing every thing they can to quietly make RC4 'just go away', not because of security concerns, they LOVE ciphers that they can break, but rather because they are afraid that someone will eventually get around to suggesting that one possible simple 'fix' for security concerns surrounding TLS would be to super-encrypt RC4->AES (just as security concerns about DES lead to Triple DES).

I'm pretty sure that the NSA can break either AES or RC4, as currently implemented as individual ciphers, but probably NOT the composite.

We can't have some silly little 20 plus year old cipher screwing up the NSA's plans for world surveillance domination - so RC4 has to go.

JustinSeptember 27, 2014 10:10 PM

@Miksa

You are absolutely correct.

When Bruce was talking about cloud backup and the risk of loss of data, I was thinking in terms of something critical in terms of both loss and security, like the customer credit card billing information of a small home business.

I was most emphatically NOT thinking of some scenario like:

"Whohh dewd you were sooooo drunk - no seriously, dewd you were WASTED - Check it out - I have a pic here on my iPhone - oh CRAP I accidentally wiped it - wait! - I thik I got it on iCloud - yeh there it is, I'll send it to U"

Sorry if that seems, sarcastic, apparently in our world, you can either have simplicity, or security, but not both, and I hate to see the 'smart phones for dumb people' crowd controlling the dialog, because apparently they lack the technical sophistication to understand what is possible, what is not possible, or even what the stakes are (outside the context of some brainless super model's nasty selfies getting stolen and posted to the Internet).

The sad thing is that, if the current generation really cared, they could have BOTH simplicity AND security, by simply forcing their will at the ballot box.

Believe it or not, it's not the technology, that can quite easily be solved, it's the political will, to GET IT DONE.

The solution? Simple, just pass a law forcing providers to offer secure encryption of all uploaded user data, with encryption at the source (on your device) with the user in sole control of the password - and full discretion about what gets shared and what does not - with NO back doors.

Then make it a class one felony for any entity public or private to willfully attempt to bypass that security.

Help ANYONE (even the government) steal anyone's private data, by ANY means - ever - anything - and everyone involved goes to jail, no excuses, no exceptions - period.

Heinous hacker, or Head of the NSA, and the same rule applies, you go to jail, no excuses, no exceptions - period.

Problem solved - but nobody in our current 'Tech Savvy' generation of 'smart'-phone users even seems to care...

... not as long as 'Angry Birds' and 'Candy Crush' still run, and they can follow every mindlessly stupid 'tweet' uttered by their favorite celebs.

ThothSeptember 27, 2014 11:08 PM

The two sides of security is convenience and security. On one hand, you have the security where you encrypt files and send them to the network. On the other hand you don't encrypt files and send them to the network.

For the average people or less educated people (in technology), the option would be to just send them to the network plainly without security. The common reason is the cumbersome security when they need access to secured files. In the sense, what if you are trying to retrieve a file from another machine that does not have the crypto programs installed and the machine happens to belong to someone's machine. One good example is sending photos to a friend and your friend is not those security minded. He/she may not like or understand the idea of crypto-security and simply ignores/delete off the secured file. What if you need to retrieve Dropbox files over a less capable device or a machine that does not have the binaries or capabilities to do your crypt-security on the receiving end ? There are times you happily encrypt your files and send them to Dropbox and you are somewhere off traveling and you happen to need that file accessible on your mobile device and realize that the decryption program only works for certain platforms.

Your receiving environment can also dictate how and what files you receive. One example is that you are working from home and you want to send files to your office network and if it does not allow you to install the crypto-security program, it is as good as wasted effort.

There are of course certain programs that can run off mobile platforms or web based platforms due to their portable nature (Javascript-based crypto) but if your office network is configured to defeat certain network traffic, it can be messy especially if the files you are trying to receive are critical (daily meetings and so on).

Security have to be designed with conditions involved. I think Bruce is approaching from the angle that if security is unnecessary at certain point (family photos you share over Dropbox and so on), you have to consider the scenarios. If you are trying to send photos to people, locations or environment that may not be suitable for certain actions, then no matter how much security you invest, the efforts might not be well invested.

What Bruce might have meant in simple is ... watch the circumstances before doing something ...

Of course security is much better if it can be trivially done but as we have seen, platform issues, vendor lock in, work environment... it is something not easy to simply fix a standard to encompass everything.

Nick PSeptember 27, 2014 11:49 PM

@ Justin

Thorough and interesting reply. Before it got so risky, I had posted here that I used RC4 then AES. I later modified each with a random increase in the counter mode value, number of rounds, and number of iterations on the counter. That obfuscated & diversified it enough to equal multiple rounds of encryption in practice. I later ditched RC4 for Salsa20. I also had my "polymorphic" encryption* that did the same thing, but with multiple block ciphers in counter mode. Each block cipher is internally different, all known strong, and the shared secret for each session determines which ones are used in which order. The secret is always the same size & the ciphers were made to have similar to same timing to prevent knowledge of the scheme. But, the part of your comment I liked the most was:

"We can't have some silly little 20 plus year old cipher screwing up the NSA's plans for world surveillance domination - so RC4 has to go."

The reason is that I said the same thing about IDEA. The NSA, academia, and even Bruce Schneier took stabs at it. Especially due to PGP using it. The algorithm worked for a long time before they broke it in 2012... theoretically. It's still safe for practical use. One of my first designs was Triple-IDEA with another using it first followed by AES candidates. Getting weaker all the time but still safe for now. Currently awaiting more cryptanalysis of eSTREAM ciphers and hash functions for encryption schemes.

* A company Bruce "doghoused" once claimed to have polymorphic encryption that created a new algorithm for each use. I linked to them and posted my polymorphic block cipher algorithm. I pointed out that doing it right (minimal version) was actually easier than what they did. Checked on them in recent years & they had a new one that used strong ciphers as a base primitive. So, I had to decide whether I felt good about improving the security claims of snake oil crypto company. Lol... I guess at least their customers are safer.

FigureitoutSeptember 28, 2014 12:57 AM

Justin
--On your scheme, I agree. You could send plaintext to an arbiter, then post ciphertext to the blog, and if no one can crack it w/ a week or 2; probably too much work for most.

I'm interested in older ciphers for running on my older/slower machines I'm building. By never touching the internet, at least until encrypted at least twice, doubt most will be able to crack besides knowing who I am, my schedule; and physical attacks.

But as Miksa pointed out, this article isn't about crypto; but about practical implementations of backups. I say it's almost already done "on client side", it's the host that's more worrisome. Can be mitigated w/ a one-way guard w/ a separate monitoring firewall; to a pretty high security degree, fairly easily.

An unnacceptable flaw in your scheme includes ignoring side channel attacks, not just math ones, physical/wireless/timing...Where is the encryption happening, how does the data actually get "from A to B"?

RE: your political complaints
--I remember my early 20's. If you think it's so easy to do what you say; then umm...quit posting on a blog and do it. Otherwise please take my word and don't waste your life...focus on crypto or something related to science.

Your bit on preventing *ALL* backdoors as being as easy as passing a law...Please reconsider what you just said, you're smarter than that.

JustinSeptember 28, 2014 1:38 PM

@Nick P

While we are drifting a little off topic, I thought I would take a moment to respond to your comments about IDEA and Polymorphic encryption.

I also like IDEA as a cipher. I can still remember tweaking Colin Plumbs original C code to compile on my machine almost 20 years ago.

So far as the 2012 Bicliques attack by Khovratovich, Leurent, and Rechberger which claims to 'break' full 8.5 round IDEA goes- this attack only shaves 2 or 3 bits off of the 128 bit key's strength, and requires something like 2^56 data to do that, which may be interesting from an academic perspective, but is pretty useless from any practical point of view.

On the subject of 'Polymorphic' encryption, there was a reason Bruce was skeptical.

Running lots of ciphers in parallel, as they were proposing with their silly Polymorphic Encryption is SNAKE-OIL pure and simple, because it means that your encryption is only as strong as the WEAKEST cipher in the bundle (not as strong as the STRONGEST as it is with proper one-after-the-other serial super-encryption).

This is because with parallel ciphers, as soon as one cipher is broken you start leaking plain-text, and the ridiculous argument that "then the attacker still can only get a fraction of your data" is just idiotic.

Also, from a purely mathematical perspective, the idea that just interleaving cipher blocks from different ciphers and making the attacker have to guess which cipher was used for each block adds significantly to the cryptographic strength is ludicrous - let's see, the attacker is willing to brute force your 56 bit DES key with trillions of operations, but when faced with the extra effort of then trying each key against 8 whole different blocks to find out which was encrypted with DES they throw up their hands and give up - yeh right. Snake oil.

In fact, as described, their 'Polymorphic Encryption' had pretty much ALL the hallmarks of pure unadulterated Snake Oil Cryptography . . .

1) First grandiose claims of "super-security" that no one else has.

2) Followed by the 'maximum buzzword' kitchen sink approach of throwing around the names of as many ciphers as possible (They must know practically EVERYTHING about crypto, just look at all the ciphers and buzz words they know!)

3) And finally, design principles that demonstrate a fundamental lack of understanding about basic cryptographic principles and mathematics.

Nick PSeptember 28, 2014 4:23 PM

@ Justin

Yeah IDEA seems safe. Your points on the snake oil company are right on. The claims were hilarious & even their knockoff of my polymorphic cipher is crap.

Far as my cipher, I agree that it *mostly* reduces to security of weakest algorithm (and that's intentional). I think there's additional security benefit from the fact that some attacks look for patterns in the ciphertext and the attacker can't see one or more ciphers' output in a multiple encryption scheme. Finally, my polymorphic scheme modified the order of sound algorithms (eg IDEA, AES), the values of nonces, the starting point of counters, iterations of hashes, and so on. Certain constructions I thought were risky were forbidden and it would check for those.

No valid combination had a provable negative impact on security. That the enemy needed the shared secret to even know what construction to use provably makes their job incredibly difficult if they're targeting crypto. I've found evidence in the field that obfuscation combined with sound security techniques & internal controls is the best combination against TLA opponents. Just one example.

JustinSeptember 29, 2014 2:06 AM

@ Figureitout

I'm interested in older ciphers for running on my older/slower machines I'm building...

Good strong crypto, even on older hardware is indeed possible.

Anyone interested in a simple file encryption utility that can be used to encrypt files before archiving them locally or on the web using cloud storage may want to check out the openssl command line utility.

(please excuse the long reply, as simple instructions for openssl, especially on on MS hardware, are not always easy to find on the web, so I hope some of you will find this useful).

If you are running any MS based OS from DOS forward to Win8, one of the simplest and most flexible solutions for simple file encryption and hashing is to grab a copy of the Openssl package from:

GnuWin Utils Openssl

The package you will want to download is openssl-0.9.8h-1-bin.zip

This is a small 5.9MB package with many crypto libraries, test programs, etc which most folks won't need, but also including something that is really really handy, a MS compatible 1.7MB standalone version of the openssl.exe command line tool which is very simple to use from a DOS prompt or batch file and which can support most of the ciphers and hashes you are likely to want to use:

Hashes: MD5, SHA, SHA1, SHA256, SHA512

Ciphers AES128, AES256, Blowfish, IDEA, RC4

No need to install anything, just download and open the above zip file and open the "bin" folder and find "openssl.exe" and put it in some folder that is in the executable path for your CMD command prompt.

Here are the MD5 and SHA1 hashes for the openssl.exe file so you can double check the integrity of the version you download.

File name: openssl.exe
File size: 1802436
MD5 hash: f604c26ddaa13680a3278620c485212c
SHA1 hash: 7f3461882cfc8d40d2991131fda025a3bfa900f1

If you are wondering about the trustworthiness of this implementation, Sourceforge is generally a fairly safe reliable source, and this particular project is hosted by the GNU project, the same folks who provide the GNU utils for Linux, as well as GCC which is used to compile basically the entire Linux kernel and operating system. Since Linux is used for literally millions of e-commerce servers and desktop systems around the world, if you can't trust GNU utils, you pretty much can't trust anything.

Speaking of Linux, if you are running Linux the above .exe will not work except under wine, and there is no need to fiddle with that in most cases, since a native Linux openssl version will always be provided. One possible exception where Linux users might want to run the openssl.exe version provide in this package under wine would be if you need access to the IDEA cipher, as that IS provide in this package but is NOT provided in most Linux openssl implementations due to past licensing concerns.

To test openssl, you can simply open a terminal and type:

openssl version

It should respond with the version info (0.98)

Then create a quick test file with:

echo "this is a test" > file.in

Then to test encrypt that file type:

openssl enc -aes-128-cbc -e -in file.in -out file.out -k "my password"

Later, you can just replace file.in, file.out and "my password" as appropriate with the actual file names and pass phrase you want to use.

To decrypt just replace -e with -d and make sure that you list the encrypted file as the -in file.

So to decrypt the file.out created above:

openssl enc -aes-128-cbc -d -in file.out -out file.txt -k "my password"

If you now open 'file.txt' with a text editor it should be the same as the original file.in

Only a few cautions:
Openssl tries to open both it's input and output files at the same time, so if you accidentally REVERSE the -in (which exists) and -out (which does not yet exist) Openssl will try to open the not-yet-existing file for input, and FAIL, but NOT BEFORE it opens the other file, your actual input file, FOR OUTPUT AND TRUNCATES IT TO ZERO LENGTH DESTROYING YOUR INPUT DATA. So either work with backup files or be VERY careful to get the -in and -out file names correct.

Another caution is that, absent the above accidental deletion mistake, openssl never deletes your input file, YOU HAVE TO DO THAT, and obviously, you will want to use some kind of secure shredder tool, but note that if your hard drive is not fully encrypted you will probably still be left vulnerable in any XP or later Windows version due to their used of a journaled NTFS file system.

With DOS and Win95/Win98 FAT and FAT32 file systems there is no journaling, so shredder programs work more reliably, but hard drives and thumb drives can also leave copies of your original plain text files accessible, due to automatic wear leveling and error control algorithms, over which you have no control. So ideally, if you really are concerned about security, sensitive data should never reside, even temporarily, on a drive that is not full-disk encrypted.

Also, when selecting passwords or passphrases, note that though Openssl does salt and hash your supplied -k password (which is good), it doesn't iterate it (which is bad), so with only one simple MD5 hash cycle of 'work' associated with your password, it is susceptible to dictionary attacks if the pass-phrase is short or predictable. Bruce has some good advice about picking good non-dictionary-attackable passwords or pass phrases.

Fortunately, because openssl hashes the pass phrase, you can use arbitrarily long pass phrases (limited only by the command line buffer) so in general, if you use some easily memorable nonsense phrase, with goofy spelling and punctuation, at lest 30 characters long, you should be quite secure.

You may find alternate syntax examples on the web. This is because, to shorten the command line, openssl accepts some shortcut command syntax:

As a shortcut for the longer 'enc' syntax:

openssl enc -aes-128-cbc -e

You can use:

openssl aes-128-cbc -e

(note the missing enc command and '-' before the cipher definition)

You can also use this with the hash function commands:

openssl md5 file.in

will work as a shortcut for:

openssl dgst -md5 file.in

Sadly, this does NOT work for all modes, so to run a SHA512 hash you still must use:

openssl dgst -sha512 file.in

(also note the slight inconsistency in syntax, here since there is only ever one file for a hash, we don't use -in before the file.in as we do with the 'enc' command)

Once you get past some minor quirks in syntax, openssl is a simple to use command line cryptographic tool that has strong, well vetted, technically correct cipher and hash implementations that you can utilize with just a few simple keystrokes.

In Windows OS's from Win95 forward, openssl.exe should run perfectly as a standalone file right out of the box in any command prompt session, but for command line use in DOS it will require a 32 bit extender that it can recognize so it can use extended memory.

Wesley ParishSeptember 30, 2014 5:14 AM

Just a comment on the original topic: does anyone remember what happened to Kim DotCom's servers?

There were quite legitimate users of MegaUpload with quite legitimate uses thereof, and Kim DotCom can't get his servers back, nor can these legitimate users of MegaUpload get their works either.

That's in the cards as soon as the US Feral govt decides that Apple, Google, Microsoft, etc, are "pirates" or working in their favour and cause ...

So the best policy be far would be to back up on as many Cloud servers as possible and economic, in as many jurisdictions as possible.

JesseOctober 1, 2014 4:35 AM

Easiest thing in the world: install Cloudfogger (free) which automatically encrypts all your info. before uploading it to the cloud. It uses AES 256, so nobody's gonna be reading any of your files.

Wesley ParishOctober 2, 2014 7:19 PM

Oh the bitter irony!

A few days after I mention Google (see above re Kim DotCom) as a likely target of legal action after someone decides they're aiding and abetting the enemy, ie the ordinary sharing digital artifacts:

Google threatened with $100M lawsuit over nude celebrity photos

and

Celebrities Threaten Google With $100 Million Lawsuit for "Facilitating" Hacked Nude Photos

That's the public Cloud for you: it's damp, it's misty, and is stuffed with rocks. Lots of fun for low-flying aircraft ...

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.