User verification of encryption system robustness

badwater

I am very delighted with Boxcryptor and use it daily. As an intellectual exercise I've been considering potential attack modes.

Two points come to my mind, one fairly esoteric and the other something that is more real world.

Taking them in reverse order

1) It appears to me that it is vital the user installs the software themselves. If it is installed for them (by a supplier, advisor, etc) then using the change password facility will never offer full security as the installer will always be able to decode files if they know the install password and have the associated .encfs6.xml file (which may be available from Dropbox history for some time),

If I'm right maybe this should be made more apparent to new users?

2) Because of your openness I'm able to asses and ensure the actual security of my installation with one major exception. (Other than accepting the robustness of AES-256)

As I understand it, the Volume key is generated by the random number generators you have described and PBKDF2. Theoretically this gives a very strong key. It needs to be strong as it is never changing and many files are encrypted with it.

However this one vital element is not something I am able to verify for myself.

I'm sure you will appreciate that I'm not questioning Boxcryptor's integrity on this but wondered if this hypothetical loophole could be removed if, after a clean installation, I were to replace the encodedKeyData field in .encfs6.xml with my own random string before I start to encrypt any files?

Would this work and are there are issues I need to consider when editing the file?

Thanks for a great piece of software.

stu

As to q.1: oh. I see the encfs6 file is indeed available on my Dropbox. If that was obtained, could the person decrypt my data?

badwater

Only if they also have the password associated with that version of the file.

However, as the Volume Key can never change, old versions of the file will always work with their associated password. As a result, changing your password may not fully secure your implementation should your password have been compromised.

Robert

(Just a short notice: I'll try to answer these questions as soon as possible but I'll have to ask for some patience)

badwater

If it is impossible for the user to verify the Volume key is random (or replace it with our own) we will have to assume it is compromised and that someone, somewhere can decode all our files.

JackReacher

Badwater, thank you for articulating this subject and asking the question. For me this is also a very important piece of the puzzle. I hope it is answered soon.

Robert

Hello again and sorry for the late response. Let's try to answer the questions (regarding Boxcryptor Classic):

1) It is correct that the volume key is never changed after the initial generation - even if you change the password. Changing the password rather re-encrypts the volume key with the new password and updates the encodedKeyData value in the .encfs6.xml file.

2) If somebody else created the Boxcryptor Classic Folder for you, you can never be sure that this person won't be able to decrypt your files later. If the person has a backup of the .encfs6.xml file when the initial password was used, he/she may use the combination of the initial password and the .encfs6.xml backup at any time to decrypt your files - even if you changed the initial password. The same applies for old versions of the .encfs6.xml which might be stored at Dropbox (or another provider). If you have had a weak password in the past and an attacker is able to get the .encfs6.xml from the time this weak password was used, it is enough to brute force the weak password.

3) Of course, you can manually replace the encodedKeyData value in the .encfs6.xml after the initial setup - but you have to be sure that the format is correct. We don't have any public documentation on it, but you could have a look at the EncFS project. (Or even easier: You can also use EncFS to create the .encfs6.xml file)

Best regards,
Robert