Boxcryptor/Truecrypt interactions - suggestion

elf

Like many people, I use Truecrypt to create an encrypted drive from a file container. Boxcryptor, on the other hand, encrypts each file separately - a feature which is necessary for interactions with DropBox (etc.)

Having the files separate, and also encrypted filenames, means that any boxcryptor folder is going to be very obvious to any unsuspecting snooper if ever your harddrive is inspected. So there is neither plausible deniability from an obscure large file, or extortion-survival techniques such as Hidden Volume which allow you under duress to give a password which will reveal an encrypted drive, but not the one with your confidential data.

To combat this risk, I have placed my boxcryptor folder inside a truecrypt container, so that when all drives are mounted I get the best of both worlds.

Functionally, this works - however, I understand that encrypting the data twice (once with boxcryptor, and again with truecrypt), is probably incurring a significant performance hit. Moreover, I expect that some hardware based speedups just do not work.

My suggestion is that Boxcryptor should allow the ability to create a truecrypt-style single-file container that is mountable into another drive where I can place my standard boxcryptor folder with file-by-file encryption. The advantage would be that the encryption is done only once, and if one application is managing the whole thing, presumably it is much more efficient.

Would welcome any suggestions if there are alternate ways of getting around the concerns listed above.

ehab

I only moved to boxcryptor because my 2GB Truecrypt file needs to be unmounted and i have to wait for the delta to be synced, i didn't find Shutdown PC when sync done, yes i tried looking up poweroff tools and one did work for some time but not enough.

Do you think the idea of Boxcryptor container and file by file encryption would help performance? already there is payload. Even if true only 60% performance gain would be acceptable otherwise so much overhead needs to be taken care of let alone the .Net part that communicates with CBF slowdowns.

On the cloud i only keep files that won't hurt if technology fails.

CC

@elf
you wrote:

" Functionally, this works - however, I understand that encrypting the data twice (once with boxcryptor, and again with truecrypt), is probably incurring a significant performance hit. "

No, encryption is very fast (well, it should be), including AES.

Therefore, my suggestion is to keep BoxCryptor like it is ... ;-)

ehab

@CC

on what base you suggested :
No, encryption is very fast (well, it should be), including AES.

CC

The most important aspect is that users don't experience any delays because of (AES) encryption when working on files and encryption is of course negligible compared to file I/O and remote internet storage access.

(*) Even when we copy for example a 700 MB directory tree to another directory (same hardisk) , that doesn't hardly differ from a copy to a TC (TrueCrypt) volume on that same harddisk.

Other experiments left as an exercise.

Apart from this, our guess is that several considerations about "plausible deniability" and "extortion-survival techniques" of the original poster are somewhat theoretical in nature. If that's not the case many forum users may like to hear some adventure like stories from the original poster ;-) Until now some sort of integration is not a reason to complicate a software implementation like BC, we think, as an end-user, when using existing TC + BC implementations hardly result in any additional overhead.

There may be other performance improvements from which BC may benefit more.

To the original poster: why do you think an integration of concepts is worthwhile, what are your benchmark results, are your results different from the above-mentioned (*) or similar experiments ?

elf

My main reason for asking is that I've noticed slow operation of apps/utilities which access files in my Boxcryptor Mount (inside the Truecrypt mount). Process Explorer shows me Boxcryptor using IO but very slow rates (e.g. a few KB/s). I'd assumed this would be because of the virtual drive within a virtual drive set-up not being optimal. But if you're suggesting that you do not think that a TC+BC set-up should be slow, then perhaps it is other issues that I am experiencing.

Is there a standard way to track the I/O performance of Boxcryptor? e.g. if I am experiencing what I believe to be BC slowdowns, is there a way I can verify this rigorously?

CC

Hello, you wrote:

>> Is there a standard way to track the I/O performance of Boxcryptor? e.g. if I am experiencing what I believe to be BC slowdowns, is there a way I can verify this rigorously?

You need BC's source code to factor out several performance contributions much more easily than using particular monitors as an end-user.

By the way, you're now talking about I/O, but mentioned encryption in your first post, these two issues have different aspects / characteristics. My "should be" remark was regarding encryption.

A TC <=> BC issue is already mentioned in another post, so let's hope these issues will be addressed in due time.

elf

Please forgive my ignorance if I am mixing up concepts. This is how I understand it:

From an end-point user point of view, the cost of I/O operations on the boxcryptor drive is the only performance impact that would be noticeable beyond standard physical drive.

So, the time taken to complete, (e.g.) a fread() call would be
(1) cost of reading some data from physical disk and place into memory
(2) cost of decrypting that data in memory

For the BC-TC solution, I assume there's one more step:
(1) cost of reading some data from physical disk and place into memory [drive/IO bound]
(2) cost of decrypting that data in memory (truecrypt) [cpu/memory bound]
(3) cost of decrypting that data in memory (boxcryptor) [cpu/memory bound]

I'll track the other issue as suggested. Many thanks.

CC

@elf
From a benchmark point of view, your model needs a refinement regarding processor cache hits / misses ( computational aspect ) and filesystem cache hits / misses ( I/O aspect ). If possible, you want to eliminate these aspects.

Because your impression was that encryption / decryption is relatively expensive (see your 1st post), I would like to suggest you to do the following experiment. Moreover, because ehab wrote:

@ehab
"on what base you suggested :
No, encryption is very fast (well, it should be), including AES "

I also would like to invite him to do the same experiment :

Since you're both truecrypt users, start Truecrypt => Tools => Benchmark...

And let us know the AES results, please specify your processor type, GHz, #cores, etc.

I already mentioned a 190 MB / s TC result, 2.4 GHz duo core, somewhere in another discussion ( this forum ). In case my "should be" remark doesn't hold for BC somehow, that's of course easy to solve.

I still think a number of other BC benchmarks / changes may be more useful.

If you disagree, let me know ;-)

Joe0815

Benchmark 1.7 / 2.6 GB/s here :)
BTW: Already back in the days of Pentium IV a full disk encryption was not much slower than an unencrypted disk. Even Serpent-Twofish-AES gives 145 MB/s (on my machine). Many disks do not deliver that througput.
Always keep in mind: The disk itself is the bottleneck! Or the software (in case of Boxcryptor) if it makes unnecessary IOs.

CC

Exactly, even on a low-end mobile device I used for the 190 MB/s benchmark I mentioned, encryption / decryption has hardly any impact compared to other performance aspects.

Therefore, a sort of TC / BC "merge" as mentioned in the first post isn't really necessary.

Frosty_4th

Either I'm missing something or I think your misguided as to the advantages of BoxCryptor (BC).

BC is designed for cloud storage to speed up the sync time when editing a files. Since BC encrypts at the file level, only that one file needs to be synced to the cloud. If you store all your encrypted BC files inside a Truecrypt (TC) volume then the whole TC volume must be synced when you change a file. for example if I have a 300kb file inside a 1GB TC volume and the volume resides in my dropbox folder, then changing that 300kb file forces a sync of the 1GB volume. If I just use BC, only 300kb need to sync.

Frosty