5 ms·

If the client (your browser in this case) sends a hash of file chunks before it encrypts and uploads the data you could do deduplication without having the actu

by tlack 14y ago

If the client (your browser in this case) sends a hash of file chunks before it encrypts and uploads the data you could do deduplication without having the actual decrypted data.

wmf 14y ago
I'm not sure that would work either. If Alice encrypts a block with key A and uploads it, then Bob encrypts the same block with key B and uploads it and Mega only stores Alice's copy then Bob won't be able to decrypt his own data. (Edit: I'm talking about the proposal from previous threads of encrypting with a random key, not encrypting with the hash.)
- daeken 14y ago
  That's not how it works, though. Rough steps for how a system like this can work (bearing in mind that Mega might be doing it entirely differently): 1) Alice takes file P and hashes it to produce key K 2) Alice encrypts file P with key K to produce file C 3) Alice encrypts key K with key U (her user key) to produce key X 4) Alice sends key X and file C to Mega for storage When Bob does the same steps on a matching file, the only things that differ are key U and key X -- these are his user key, and his user key for the data. That means that Mega can deduplicate file C freely, because they're identical. Note that Mega never knows the hash of the original file -- key K -- or it'd be able to decrypt the files.
  - jiggy2011 14y ago
    "Each file and each folder node uses its own randomly generated 128 bit key. File nodes use the same key for the attribute block and the file data, plus a 64 bit random counter start value and a 64 bit meta MAC to verify the file's integrity." This implies that it is not convergent, unless dedup is somehow done with the "Meta MAC".
loeg 14y ago
But both clients still need to be able to decrypt it with their separate keys... even if the cleartext hash matches, the stored data is ciphertext and can only be encrypted with one user's key.
- B-Con 14y ago
  It's possible: http://crypto.stackexchange.com/questions/729/is-convergent-encryption-really-secure http://crypto.stackexchange.com/questions/729/is-convergent-... . The trick lies in ensuring the key used for encryption is linked to the file, not the user. You then have to store a separate key for each encrypted file (and that encryption key is probably going to need to be wrapped by your actual user key for storage).
  - loeg 14y ago
    True.
  - loeg 14y ago
    But, how does the second user to upload the same file know the file's encryption key (since presumably the server only knows ENCRYPT(FILE_KEY with USER1_KEY))? It seems like either the server must know the file's encryption key, or the key must be derivable from the contents... which is no good.

by tlack 14y ago

If the client (your browser in this case) sends a hash of file chunks before it encrypts and uploads the data you could do deduplication without having the actual decrypted data.

wmf 14y ago

I'm not sure that would work either. If Alice encrypts a block with key A and uploads it, then Bob encrypts the same block with key B and uploads it and Mega only stores Alice's copy then Bob won't be able to decrypt his own data. (Edit: I'm talking about the proposal from previous threads of encrypting with a random key, not encrypting with the hash.)

daeken 14y ago
That's not how it works, though. Rough steps for how a system like this can work (bearing in mind that Mega might be doing it entirely differently): 1) Alice takes file P and hashes it to produce key K 2) Alice encrypts file P with key K to produce file C 3) Alice encrypts key K with key U (her user key) to produce key X 4) Alice sends key X and file C to Mega for storage When Bob does the same steps on a matching file, the only things that differ are key U and key X -- these are his user key, and his user key for the data. That means that Mega can deduplicate file C freely, because they're identical. Note that Mega never knows the hash of the original file -- key K -- or it'd be able to decrypt the files.
- jiggy2011 14y ago
  "Each file and each folder node uses its own randomly generated 128 bit key. File nodes use the same key for the attribute block and the file data, plus a 64 bit random counter start value and a 64 bit meta MAC to verify the file's integrity." This implies that it is not convergent, unless dedup is somehow done with the "Meta MAC".

loeg 14y ago

But both clients still need to be able to decrypt it with their separate keys... even if the cleartext hash matches, the stored data is ciphertext and can only be encrypted with one user's key.

B-Con 14y ago
It's possible: http://crypto.stackexchange.com/questions/729/is-convergent-encryption-really-secure http://crypto.stackexchange.com/questions/729/is-convergent-... . The trick lies in ensuring the key used for encryption is linked to the file, not the user. You then have to store a separate key for each encrypted file (and that encryption key is probably going to need to be wrapped by your actual user key for storage).
- loeg 14y ago
  True.
- loeg 14y ago
  But, how does the second user to upload the same file know the file's encryption key (since presumably the server only knows ENCRYPT(FILE_KEY with USER1_KEY))? It seems like either the server must know the file's encryption key, or the key must be derivable from the contents... which is no good.