Syncing encrypted stuff - best practices!

[Raccoon]

From what I read the last couple of days around the forum Sync uses AES 128 encryption for the transfers which should be more than enough for most users.

But since it's closed source and most security concerned people prefer to have the control in their own hands I believe a lot of people will be syncing AES 256 TrueCrypt containers.

Here is what I have learned so far, please correct/add things so we can make one stop, best practices thread for syncing encrypted stuff.

- Sync works well with fixed size encrypted containers. It splits the files in 4mb chunks and will only re-transfer the chunks that have been changed.

- If the container is not fixed size and even one byte is added or removed it will re-ransfer the whole container because it can't track shifted data.

- On some OS you will have to set TrueCrypt to update the last modified date, so Sync can understand the file is modified and sync it. (By default TryeCrypt doesn't change the container date) On other OS that is not needed (some clarification from people in the known why the behavior is different will be appreciated)

- No matter how much data you've changed in your container you will have to dismount it, in order for Sync to be able to sync, since it doesn't sync files in use. (Right?)

Please note, this is information I found around the forum, i'm just about to start testing that myself.

So, if there are people with actual experience, it will be really useful if they can confirm that and add their own observations and advises.

I'm also very interested if someone managed to corrupt a container already by syncing it? In that case does the trash folder helps?

Generally lets make this a thread that would be enough for everyone to read and start syncing encrypted stuff safely right away in an optimal way.

[dswd]

Lets not get into the discussion of AES 128 vs. AES 256 again, both are secure enough.

The main point of this solution is that the files are encrypted on disk nad not only over the network.

Your point about shifted data is correct but I doubt TrueCrypt uses that a lot as it is a very uncommon operation that triggers worst-case behavior also in most of the filesystems.

I am currently using encfs and synchronize the encrypted directory over btsync. That works well and I did not find any problems so far.

[Raccoon]

Lets not get into the discussion of AES 128 vs. AES 256 again, both are secure enough.

The main point of this solution is that the files are encrypted on disk nad not only over the network.

Your point about shifted data is correct but I doubt TrueCrypt uses that a lot as it is a very uncommon operation that triggers worst-case behavior also in most of the filesystems.

I am currently using encfs and synchronize the encrypted directory over btsync. That works well and I did not find any problems so far.

I didn't mean that AES 128 isn't secure enough, but that leaving your encryption to 3rd party, especially in the era of PRISM is not considered serious solution for any at least half privacy concerned individual. Not implying anything about the BT guys in particular but just talking in general. (I love all their projects, keep up the great work!)

Also you can have them encrypted on the HDD but if you set a folder in the mounted container to be synced you will be syncing unencrypted files and relying only on the 3rd party solution encryption.

That's why I'm talking about syncing dismounted containers in particular and the tricks around them.

[goli]

Hey there.

As I just wrote here, I go for EncFS too and I like it pretty much.

Using TrueCrypt has the great disadvantage that you can only rely on consistent synchronization for dismounted containers. Think about leaving the office at night. You need to dismount the TrueCrypt container first and wait for synchronization. Depending on the amount of stuff you did during the day, this can take several minutes. EncFS only provides virtual decrypted views on files, so changes on files go directly to the encrypted file and trigger btsync to synchronize immediately.

And the shift problem with EncFS even more unimportant as it is with TrueCrypt.

Think about several small files with a view KB each. Add them to TrueCrypt, wich likely makes TrueCrypt spread them (I don't know about the ballancing algorithm of TrueCrypt in Detail, but that's basically what goes on here) turough the container. It tries to avoid fragmentation and it tries to keep as much as concurrent space as possible. Several small files being magitudes smaller than $btsyncBlockSize added to TrueCrypt creates almost as much single changed fragments inside of the TrueCrypt container as you added files. Say, 10 files with 4KB each (create empty files just to have placeholders for something) might create 10*$btsyncBlockSize to be synchronized.

Add 10 little files to EncFS and you will get 10 encrypted files that are alomst as little as the original ones, which is far away from 10*$btsyncBlockSize.

If you don't add several small files but simply change existing ones that are smaller thatn $btsyncBlockSize require you to synchronize those $numberOfFIles*$btsyncBlockSize when using TrueCrypt, but only require you to synchronize $numberOfFiles*$individuallAverageFileSize.

If your manipulated files are bigger than $btsyncBlockSize, then TrueCrypt and EncFS require you to synchronize pretty much the same amount of data.

So, EncFS comes in pretty handy if your modified files are usually smaller than the $btsyncBlockSize. If your modified files are usually bigger, it should be pretty much the same.

I know that the math is a little bit more difficult, since both have kind of independent block cyphers with a defined block size and I know that EncFS for small files (smaller thatn $EncFSBlockSize) behaves almost like stream cypher. But that's nothing to worry about here, since it doesn't influence the math in an noticable way.

And, as Written in the other thread, it works pretty well on all the platforms I use.

Kind regards,

Stephan.

[jaithn]

hey guys,

do you know https://www.boxcryptor.com/en/boxcryptor-classic? Does anybody of you have experience with this software?

Greetings,

jaithn

[eldadh]

Hey,

I have tried several methods, and so far i m sticking with Boxcryptor.

It basically encfs for windows which mounts your encrypted folder as a virtual drive.

So far its doing the job good, I don't recall many hick-ups except user error.

I m using Boxcryptor on my windows machines and encfs for linux or android.

Eldadh

Editted 31/7/13 - i do need to point out that i m using boxcryptor classic and not the new version which is NOT EncFS compatible.

[Raccoon]

bump for more input

[goli]

As far as I know, boxcryptor (version 1) is "just" encfs.

Regarding to some online receptions, it's a little faster than e.g. encfs4win. Since encfs4win relies on Dokan, which seems to have stopped development, I think using boxcryptor for the long therm is a nice thing.

Since boxcryptor version 2 has a couple of changes that make it incompatible with encfs, I would only use it if I needed the improved multi user features in business environments. That's the main deal of boxcryptor 2, imho: Not a single locally stored password but a provided privilege system. On the one side this makes you depend on the boxcryptor company. On the other hand you can have shared encrypted stuff with partial access.

I would go for boxcryptor 1.

Regards,

Stephan.

[LazyWolf]

I think that syncing a TC volume would defeate one of TrueCrypts core security features. You know when you have to wait a long time when creating a new volume or encrypted partition in TC, it is filling that space with "random" data. This makes it hard to guess where data is located(if any at all) in the space. One of the ways BTSync deals with large files is to split up the file into chunks of 4MB to see if it needs to be updated if an attacker could watch the data from a TC volume being backed up to a service like backupsy they would be able to eliminate a large section of the volume and know exactly where the real data is located.

[Raccoon]

I think that syncing a TC volume would defeate one of TrueCrypts core security features. You know when you have to wait a long time when creating a new volume or encrypted partition in TC, it is filling that space with "random" data. This makes it hard to guess where data is located(if any at all) in the space. One of the ways BTSync deals with large files is to split up the file into chunks of 4MB to see if it needs to be updated if an attacker could watch the data from a TC volume being backed up to a service like backupsy they would be able to eliminate a large section of the volume and know exactly where the real data is located.

ok, but knowing where the data is, doesn't make the decryption any easier at all i believe?

[LazyWolf]

ok, but knowing where the data is, doesn't make the decryption any easier at all i believe?

True but knowing how much data has changed from a forensics point of view can give you quite a bit of information...

Say a person went to TPB and searched non https, found a movie that was 752227840 bytes. They download said movie and move it to their encrypted tc volume which is later synced across a network.

If someone was watching and had control of the backup computer they would not be able to access the data but if they also had access to your net history (LEO) they would be able to show you searched on TPB and one of the links you went to had a 752227840 byte movie then an hour later the person moves the movie to the tc volume and it slowly syncs only the new data 752227840 bytes added to the filesystem. They now can show that the person more than likely moved an illegally downloaded movie from their main partition to an encrytped one.

Also if using a hidden volume an adversary would be able to see that you are writing data to one part of the volume that the normal outter volume password will not have access to. Then they could "prove" there was a hidden volume and you lose the Plausible Deniability TC gives.

[Raccoon]

great point, thank you!

[dswd]

To be fair: Encfs has the same problem

[LazyWolf]

To be fair: Encfs has the same problem

Encfs is not build with Plausible Deniability in mind, encfs is easy to detect because of its .encfs6.xml file format. Where if you were to compare a TC volume that wasn't made with --quick and a file of the same size made from

dd if=/dev/urandom of=randFile.dd

you would be unable to tell which if either of them were TC volumes.

[liefde]

Here's what I've been doing for about 2 years now;

Use cryptsync and have the truecrypt mounted volume drive-letter as the unencrypted side, and a btsync folder or subfolder as the encrypted side. CryptSync syncs, btsync sees updated files and syncs them on network in turn.

 

By the way, for Windows users with SSD it might be a better idea to use DiskCryptor instead of TC. I've been quite happy with it, and it's even lower on resources in Windows 7 x64..