Strength of encryption & security

techno.kid

Hi there,

I´m quite new in using BoxCryptor so I have some questions in mind which I didn´t find a answer for in the forum at first sight.

As far as I understood from all the sources I could find, all files are encrypted with the same symetric key (AES-256) that is stored "somehow" in the file .encfs6.xml.
"Somehow" means it is secured by some algorithm which uses the password for encryption... though there is some other kind of "key" used, the weakest point is the password.
If there is "more" on security I´d be glad to get a hint where I can read/understand that kind of sec used.

Another point that bothers me is that the key which is used to encrypt my files is/has to be stored in the same place e.g. DropBox as the the files. So if somebody get´s hold on my account (yeah... it´s just an example :-) he can grab the encrypted files *and* the (encrypted) key and run a bruteforce attack against my "password" - which I already asumed is the weakest part in this kind of "crypto-chain".

From the little I know about cryptography the encryption key is always kept safe/away from the encrypted documents... what part is it that I´m missing with BoxCryptor that will make me more confident in it´s security design?

Boris

Hello techno.kid

In general from our Knowledgebase:
"BoxCryptor uses two keys for file encryption: a master key which is derived from a user supplied password and a volume key. All files are encrypted with a volume key which is generated when a new encrypted directory is created. The volume key is stored encrypted by the master key in a configuration file (.encfs6.xml) at the top level of the source directory. When BoxCryptor mounts an encrypted directory you have to enter the password. The password is used to derive the master key and the master key is used to decrypt the volume key which is then used for file encryption."

Concerning your questions:
"Somehow" means your files are encrypted by the volume key which is stored encrypted (with the AES-256 algorithm) in the .encfs6.xml file. To decrypt the volume key you have to enter your password which is then used to derive the master key which decrypts the volume key. To derive the master key BoxCryptor uses the PBKDF2 function: http://en.wikipedia.org/wiki/PBKDF2.

So you are right that the password is the weakest part in the security chain. But for the password the user is self-responsible and it is highly recommended to use a long password with numbers, big and small letters and special characters. This will highly increase the effort to run a brute-force attack:
http://en.wikipedia.org/wiki/Brute-force_search
http://en.wikipedia.org/wiki/Brute-force_attack

As mentioned above a brute force attack on your password is (theoretical) possible but practically not relevant if you use a secure password. The encrypted volume key is stored together with the encrypted files, because you need both on each device in order to decrypt a file. So the key and the files have to be transferred to your other devices (mobile devices, laptop etc.) which are connected to the cloud where your encrypted files are stored. If you use a secure password the security level is definitely high enough to be safe.

Nevertheless, if you don't feel comfortable with this solution, it is possible to separate the .encfs6.xml file from the encrypted files using the /config command line option. But if you use this method you have to transfer the .encfs6.xml file to your other devices by yourself and the Android and iOS versions of BoxCryptor are no longer compatible with this setup.

I hope I could help you and you are now confident with the current BoxCryptor security design.

Best regards
Boris

neoshivan

Hi - I also had the same concern as techno.kid (with the key being stored with the encrypted files). I'm running off of Win XP SP3. When I tried using the "boxcryptor.exe /config" option I get the following error: "Index was outside the bounds of the array." I get this from both windows and directly in the command line. Any feedback would be greatly appreciated. Thanks

Robert

Can you please post the exact command you're trying to use?

An example for a correct command is:

boxcryptor.exe /config C:\path\to\config.xml

neoshivan

Hi Robert - Ok I think I got it I needed to enter the new path of the config file after /config. Thanks

bhugger

I have a follow up on this...

Say I use a really bad password (ie. "password"), then realize my mistake and change it to a *really* secure one.

Then I would like to think that any new files that I add will be super safe.

But, if someone managed to get a hold of my .encfs6.xml before I changed the password, they would be able to crack it and decrypt all files; past, present and future ones. No matter how many times I change the password.

I guess the only way to *truly* change the password, is to start from scratch - create new encrypted folder, copy files to new folder, delete old folder???

Robert

Yes, your assumptions are correct. The volume key which is used to encrypt the files is only generated once when you create a new encrypted folder and is never changed later on. If you change the password, you're only changing how the volume key is secured in the .encfs6.xml file.

This has several advantages over encrypting the files directly with your password (e.g. a password change does not require to re-encrypt and re-upload all files again). But it also has the slight disadvantage you mentioned.

Another Example:
Alice and Bob have access to the encrypted folder and know the password. Alice changes the password and the .encfs6.xml file is changed. Bob can no longer access the encrypted files. But if Bob has a backup of the .encfs6.xml file before the password change, he can replace the new .encfs6.xml file with the backup and still access the encrypted files with the old password.

Andrew

This is magnified by the fact that Dropbox keeps old versions of files, so if someone is able to access your Dropbox account, they'll be able to retrieve all previous versions of .encfs6.xml

Mitigation: Either keep the file outside of Dropbox, or manually purge the revisions by shutting down BoxCryptor, temporarily moving .encfs6.xml outside of Dropbox, going to the Dropbox web site and showing deleted files/permanently delete .encfs6.xml, and then move the newest version back in. (this will prevent anyone with access to your Dropbox account from getting the previous version, although it doesn't prevent Dropbox staff from getting at them)

meinusername

Or simply dont use a weak password from start on, so all problems solved ;)

Supaviser

I just can't get one thing. I can mount any disc and doesn't matter how strong the password is, the only one thing I've to do is to replace config file with my one and my password will perfectly pass to it (tested).

FrankGfromW

@Supaviser: It's the old tradeoff of security for convenience. Do not store your password and you're safe to go. It just sucks to enter a pretty complex password any other day, especially in smartphones tiny keyboards.
So it's completely up to you how safe you are.

Supaviser

But I'm not safe storing encrypted data on my PC. Any user on my PC can replace my config with another one and decrypt my data. That what I'm talkin about...

FrankGfromW

Supaviser, it was a shame if /your/ password would not match /your/ config file, wasn't it? :D
"Unfortunately", right after you mounted that 'foreign disk' using your own config and password and traversed its directory structure to any random file you will be unable to actually read its clear-text content, you'll see just garbage.
If you do not like anyone to see the directory structure you needed to use filename encryption. Just test it :D
In case I got you wrong please just explain your test setup so in case you were right I could circumvent that risk.

kaja69

Hi
I am new to encryption. Does the above still apply to version 2.0?
What is the recommend way to change password?

nms

yes its obvious that Boxcryptor is a weak security setup, the master key is derived easily from the main account login password using a simple algorithm so that if anyone knows your BC login password they can easily run the BC app on their machine and decrypt your files. just because an algo is used to derived a separate master key it doesn't make it safe, just adds a simple step in the decrypt process that anyone can bypass (which is why you can simply install BC on a new machine and decrypt your previous files using the same login user/pass)