Regarding tzs's system - it fails in two particular aspects: Web-based upload of files and adding a new hash/key to the database encrypted with your password.
Well, fails in that the current operation of Dropbox was a clue that they were not employing anything like tzs's system.
Web-based upload would have required three time/CPU intensive steps: Hashing the contents of the file to create the related encryption key, encrypting the file with said key, then re-hashing the file to get the new "fingerprint" of the encrypted version.
The reason this would all be required is that Dropbox is not only worried about deduplication for storage - they're worried about it for bandwidth saving. When you upload a file to Dropbox that they've "seen", they give you instant upload credit for it and skip the entire process (which users enjoy for the speed and they enjoy for the pocketbook in bandwidth savings).
With an appropriate hash and a block ciper choice, yes, they could do this without creating a client-side duplicate/encrypted file. They could do it as they go (hash the entire file, start encrypting it into a short buffer, then start hashing the buffer) - but if they're not storing a duplicate/encrypted copy locally, they're going to have to re-encrypt it as they go (again) during the upload phase.
So that's: One hash for the key, one encrypt + rehash for the fingerprint, then one more re-encrypt for the upload.
... and then you would run into the other problem I mentioned - where you also have to download the remote database, decrypt it locally, add your new entry to it, then re-upload the encrypted version. All from the web client.
Considering how quickly the upload starts - it's pretty obvious they're doing nothing even remotely like this.
(I understand that we know for a fact Dropbox has access to the files on their servers - I just wanted to expand on the proof that, based on how they were operating, that they couldn't possibly not have access. But then, I've been saying this all along.)
Well, fails in that the current operation of Dropbox was a clue that they were not employing anything like tzs's system.
Web-based upload would have required three time/CPU intensive steps: Hashing the contents of the file to create the related encryption key, encrypting the file with said key, then re-hashing the file to get the new "fingerprint" of the encrypted version.
The reason this would all be required is that Dropbox is not only worried about deduplication for storage - they're worried about it for bandwidth saving. When you upload a file to Dropbox that they've "seen", they give you instant upload credit for it and skip the entire process (which users enjoy for the speed and they enjoy for the pocketbook in bandwidth savings).
With an appropriate hash and a block ciper choice, yes, they could do this without creating a client-side duplicate/encrypted file. They could do it as they go (hash the entire file, start encrypting it into a short buffer, then start hashing the buffer) - but if they're not storing a duplicate/encrypted copy locally, they're going to have to re-encrypt it as they go (again) during the upload phase.
So that's: One hash for the key, one encrypt + rehash for the fingerprint, then one more re-encrypt for the upload.
... and then you would run into the other problem I mentioned - where you also have to download the remote database, decrypt it locally, add your new entry to it, then re-upload the encrypted version. All from the web client.
Considering how quickly the upload starts - it's pretty obvious they're doing nothing even remotely like this.
(I understand that we know for a fact Dropbox has access to the files on their servers - I just wanted to expand on the proof that, based on how they were operating, that they couldn't possibly not have access. But then, I've been saying this all along.)