Cloud usage: Store a volume like a file by unencripted file

Topics: Feature Requests
Apr 11, 2015 at 8:54 AM
Currently, veracrypt/truecrypt is not cloud-friendly: If we wish to store a volume in a cloud, this force to sync all volume with the cloud although only one of the encrypted file has been modified. For example, if we have a encrypted volume of 2gb with 1000 files and we modify a 1kb file, we must synchronize the 2gb.

I suggest create a new volume type to store a physical file per encrypted file, similar like to encfs does.

I sorry by my bad english.
Apr 12, 2015 at 12:02 PM
I don't know why so many people think so complicated or need one software doing everything for them. And EncFS isn't the safest way.
Just encrypt every file you want to store in the cloud using GPG. And if you want to speed things up, use good old batch-files.
Apr 13, 2015 at 5:50 PM
I know that encfs is not the safest way, this is the reason by I don't use it. But its design is interesting: Mount a common directory that contains a metadata file (equivalent to the first 65536 bytes of a tc volume) plus a encrypted file by each plain file.

The use a script + GPG is not the same, because isn't a encrypted volume. To open this files first must be unencrypt, and when you finish, encrypt again.

My suggestion is allow to store a veracrypt volume like a directory of files instead of a single file.
Apr 14, 2015 at 6:19 AM
I think the best way to handle Cloud Encryption is to do a Sparse based container just like the one that can be created in Mac OS X with Disk Utility. A container of X size could be created but the container is split in sectors, splits of around 8Mbs. So whenever a file is modified within the container, the only container files that are really modified are the ones which represent the sector where the modified file is stored.
May 23, 2015 at 6:02 AM
But no matter of you go sparse or not, most of the cloud providers don't really do a block by block assessment of a file to see what changed. They just update it IF it has changed (most of the times just going by the "modified" flag of the file system, because obviously a change could also result in 1kb taken and 1kb added for a different file with th exact same size. So sometimes you will just open a container, copy something out of it, close it again and the provider will resynch.

The only provider I kow of in the mainstream is Dropbox, they do active deduplication and block by block comparisons.

And I have to be honest, I also have missd a feature like "Create Container from this file/folder" often. It would so awesome if it was a shell extension where you could initiate the container creation process from within the file browser. Of course you can go the long way round, figure out the size of the folder/files, start the creation process, mount and open the new container, copy the files over, etc.

It would just be easier. I am ot sure how much of a PITA it would to implement this, but to my non developer head it looks like almost all components are already there.

And I have to admit I also second the idea of a multifile container, basically something like a multipart RAR archive. But I am not sure how much security, deniability etc one would have to give up with this approach.
May 24, 2015 at 8:40 AM
See the issue #132