Live data from Hacker News

Finally Bitcasa CEO Explains How The Encryption Works

techcrunch.com

31–40 of 42 posts

Re: Finally Bitcasa CEO Explains How The Encryption Works

#32
post #29
post #21

My biggest issue (beside the initial TC article being a complete shocker) was the claim of 60% saving on de-duplication and that each user only had 25GB of unique data. This research paper from Microsoft on Farsite[2] claims 'up to 50%' saving on de-dupe with a convergent file system - but that was tested against 500 computers in a corporate environment and it was done back in 2002. Users now store a lot more photos,…

any content that is DRM'd is also unique. In most cases this isn't true. The computation involved in keying media on the fly while it's being downloaded is not insignificant when considered in volume. The added pain of storing everyone's unique keys also discourages this behavior. At worst you'll see different keys being used by region or datacenter, or perhaps key rotation on a weeks-months scale. Some media (both D…

I tested it on iTunes. bought the same television episode on two different accounts on two different laptops and compared them to find that they had 4-5 bytes in common.

Not sure how it works in WMP. It would be common in blu-ray rips, though.

Re: Finally Bitcasa CEO Explains How The Encryption Works

#33
post #7

Something is twitching in the back of my mind about this. Sure, they can't look at the data based solely on the encrypted copy, but if they have a plaintext copy of a document of interest, they are able to determine which of their customers has that document, right? Doesn't that diminish some of the privacy claims?

Sure, but known-plaintext attacks are not the worst part. Consider this [found via http://www.mail-archive.com/cryptography@metzdowd.com/msg089... ]: I take the standard Wordpress config.php [for your host], fill in your site and account name, fill in the one million most common database passwords, and ask the cloud provider whether any of these hashes exist. Or: I create a form (say .doc) with a single field, CC#, a…

Eh. OK let's say instead of just SHA-256'ing the plaintext data to derive a key you do 50,000 bcrypt rounds. Then the client encrypts the plaintext, hashes the ciphertext, and sends the hash to the server. If it takes 0.5 s to generate a single bcrypt key, it would take about 1,500 years to find a single credit card number.

Re: Finally Bitcasa CEO Explains How The Encryption Works

#35
post #10

Academic paper on convergent encryption: http://www.ssrc.ucsc.edu/Papers/storer-storagess08.pdf TL;DR version: take a chunk of data, encrypt it with its own sha1 hash as the key. Now you have an encrypted version that you can dedup. You can only decrypt if you already know the hash. Info about who owns any particular chunk is not kept on the server, so even if you break in to the server, all you can tell is which chu…

How would I know the hash? I'd have to save the individual key(hash) for every file I upload?

Also, if I wanted to know if you had a specific file (and I had access to all your encrypted files) this would be trivial, correct?

Re: Finally Bitcasa CEO Explains How The Encryption Works

#36
post #34

So I can encrypt a file, upload it, and if someone else encrypts the exact same file... they can decrypt my uploaded file? I'm having a hard time wrapping my head around this.

I believe that the encryption will encrypt to the same signature everytime. So, if someone else uploads the same encryption file, they just point your file to someone else's same encrypted file.

Re: Finally Bitcasa CEO Explains How The Encryption Works

#37
post #17

Nothing new here. Same technique has been used by Wuala for years now.

Huh, I was going to cry foul, but apparently you're right and that is exactly what they are doing. For reference see e.g. http://wualablog.blogspot.com/2011/04/wualas-encryption-for-...

Re: Finally Bitcasa CEO Explains How The Encryption Works

#38

Earlier quoted context omitted.

Sure, but known-plaintext attacks are not the worst part. Consider this [found via http://www.mail-archive.com/cryptography@metzdowd.com/msg089... ]: I take the standard Wordpress config.php [for your host], fill in your site and account name, fill in the one million most common database passwords, and ask the cloud provider whether any of these hashes exist. Or: I create a form (say .doc) with a single field, CC#, a…

Eh. OK let's say instead of just SHA-256'ing the plaintext data to derive a key you do 50,000 bcrypt rounds. Then the client encrypts the plaintext, hashes the ciphertext, and sends the hash to the server. If it takes 0.5 s to generate a single bcrypt key, it would take about 1,500 years to find a single credit card number.

Sure, but then it takes 0.5s per file to check whether the server and client are in sync, too.

Re: Finally Bitcasa CEO Explains How The Encryption Works

#39
post #13

Why is dedupe so important? I have to imagine this mostly helps with OS files that are standard across man machines. Can't we ship a list of hashed client-side?

Cross account deduplication has nothing to do with making improvement client side, it's all about keeping storage costs down for the provider. The only type of deduplication that matters to consumers is account specific deduplication, and that saves no data for the provider unless you charge for non deduplicated storage.

Cross-account deduplication does have a client-side benefit: duplicate files don't need to be uploaded. E.g. your 300 GB iTunes library might sync to the server in a couple of minutes, rather than days.

Re: Finally Bitcasa CEO Explains How The Encryption Works

#40
I would argue that you can either have data de-duping or encryption, but not both.

If encryption is defined as: Transforming data so that only people with special knowledge can read it.

Then if you can compare a chunk of encrypted data against another chunk to determine the source data...

Well now you have very weak encryption because you could brute force it if you have a large enough repository of user files.

Post reply on HN