wow, those are a lot of questions… Let me try to answer them concisely :)
1) We don’t host any files - Boxcryptor mirrors your cloud storage provider folder in a new drive, with which you work. When you encrypt a file there, the file gets encrypted in the provider folder, and the provider itself is responsible for synchronisation.
2) No, since we don’t host files.
3) The password salt is static. This is necessary to calculate a deterministic login hash. The key salt is random for each user and stored on our server, and can only be retrieved for your own user after a successful login. But even if an attacker (or we) can read the salt: Salt values are *not* secret, and the security of the system is constructed in a way that the salt value could even be publicly available knowledge.
5) If a user saves the key of a file that is shared with him, and his access is revoked afterwards, he could use this key to still decrypt the file, that’s true. However:
- This requires a lot of reverse engineering. Unless this user is an experienced hacker, this will be out of scope.
- We assume that you share your files with trusted persons. When this person does already have access to the file and is trustworthy, he does have no reason to copy the file key.
- Finally, if you want to be sure, just download and upload the file in question again - it will then be encrypted with a new file key, and the old users key will be worthless.
6) We provide integrity for the file header. Integrity for the file content is currently not implemented, but we’re already working on that. The reason why we didn’t implement integrity checks for the body are two: First, there were technical reasons specific to the situation of encryption for cloud storage providers. Second, our focus is lying on confidentiality, i.e. preventing information leakage, which (unless you construct a very exotic use case) does not rely on integrity checks in the case of file encryption for the cloud.
Regarding audits: We agree that audits are useful. However, they are not practical for software that is updated frequently. For every small change, we would have to audit the software again, which is time consuming and costly. Therefore, we decided to concentrate our resources on developing new features and a short response time to bugs and problems instead.
7) This is actually too much to explain here in technical detail - please refer to https://www.boxcryptor.com/en/technical-overview for a detailed answer. The short version:
- We are a zero knowledge provider. Without holding the user and groups public keys, there would either be no sharing at all, or we would be required to hold some private or AES keys ourselves.
- This sharing technique is a well known approach in the cryptographic community. It has been well analysed, and it makes sense to use it with as little modification as possible.
8) I’m not sure what you mean there… The file key is unique for each file, and you need the key to decrypt the file.