| Thank you for your kind words! The technical difference is that in cryptomove data are broken apart so that the parts travel around the store -- either on the same or between different servers. there is no assumption that the store is in any dedicated location. In fact, Cryptomove is not a service -- it is software that anyone can employ to build either private store within one server, or spread out between several servers as long as they can connect via TCP/IP and have access to mounted disks with directories. I do not know internal implementation of backblaze or other storages. But Cryptomove architecture allows for the saved data to be broken apart, and for encryption and movement and of the resulting data parts. When one forces the access to a disk through which the parts move, or even to a memory of the server through which the part moves, there is practically no way to know which part belongs to which original file. This way, even if the attacker gets a hold on the data, there is no easy way to find where the data of interest is. The idea is for Cryptomove to be the last line of defense -- even if the data is stolen there is no way to know which data is which. Even if one freezes all servers involved (one actually needs to know which servers are involved which is again a very hard task), the sheer amount of parts with encrypted names makes identification task very hard. I have chosen pbkdf2_hmac_sha256 for key derivation because it is described as a hash generation function with very low probability of collisions and reversing. Cryptomove had chosen Nettle because it is free open source low level cryptographic library. When the file is saved, the client daemon encrypts data parts using user the keys generated from the user supplied password. After these parts are mutually XOR-ed and bit-scattered, they are directed to the servers. Then these parts get encrypted with the server password on each server during its forward movement -- each server encrypts the part on top of the previous server encryption. Actually, after the part is encrypted, it immediately moves onto another server, so that getting the part on a server knowing that server password is useless -- the part has been encrypted on a different server. ON the way back, the part gets first decrypted, then re-encrypted again. When the part is restored from the store back to client following the 'get' command, it gets decrypted on the way back by each server, and finally all parts get decrypted by the client, which reassembles them back into the original file.
Hope hte above helps at least in PART:-) |