I’m looking for a veracrypt/truecrypt equivalent but at the folder-level and dynamic sizing
Something like a tool which could encrypt folders in real-time and then be able to lock it up. Truecrypt expects me to provide a size for it, I’d like something more dynamically sizeable based on the files I store in it.
Even just a tool that encrypts files written into it and converts them to other files works with me
You must log in or register to comment.
CryFS does what you want, it’s the default used by the KDE Vaults feature.
there’s also a comparison page on the site, comparing it to other solutions.
Yeah, I was going to suggest KDE vaults as well.
I’m assuming you don’t want a full disk encryption solution, but you can also use LUKS to just create an encrypted mount of any supported filesystem. You don’t need any type of standalone program to encrypt your things for you.
Makes sense
Here’s a table with multiple solutions and comparisons: https://www.cryfs.org/comparison
Just be aware that some solutions like gocryptfs are provided on a user-space filesystem (Fuse). This has a very low performance and most importantly if you require inotify on the decrypted data for some application then it won’t be available. In short inotify is what allows apps to watch a filesystem for changes and act accordingly in real time.
Tables like this suck. They are made by one of the projects in the comparison and they include no data.
Better than nothing. :)
I use gocryptfs with a GUI wrapper called Vaults. It’s very neat.
Sounds like you’re looking for EncFS.
It’ll leak the size and structure of whatever you have there. Filenames and content are encrypted.
Tomb might fit your needs
Thanks I will look into it. But tomb also seems to not have dynamic sizing
You can increase the size of a tomb, but IIRC it’s an offline process.
Yeah, I think as of now I will go for it
tomb looks like a nice wrapper around LUKS but it doesn’t appear to support creating a sparse file, so, it will immediately use however much space you allocate to it.
(I think it doesn’t support a sparse backing file because I searched the word “sparse” on their github, and for the word “seek” (which is the
ddargument for creating a sparse file) in the tomb bash script, and both searches yielded no results.)
You have a few options.
My preferred way is to create an encrypted disk image using LUKS, backed by a sparse file. Sparse means that, while you’ll still need to specify a size for the encrypted volume, it won’t actually use the space on the underlying disk until you use the space on the encrypted volume. You could even make the encrypted volume bigger than your physical disk (though of course you’d get an error if you tried to actually use that extra space).
There are a few ways to setup a LUKS container; if you want to learn how to do it manually, this howto i just found looks like a good overview of the steps (though I wouldn’t recommend doing its final Setup auto mount section).
These days, you can also create a LUKS volume on a sparse file entirely using a GUI such as the GNOME Disks program. Using it, just click the hamburger menu and select “New Disk Image” and then with your new disk image selected click the gears menu and “Format Partition” and there should be a checkbox for LUKS on that screen. If you leave “Erase” turned off (which is the default), then the backing file will be sparse.
One downside to the sparse disk image approach is that when you delete files from the encrypted volume you will not regain that space on the outer disk automatically. It is possible to, but requires work to do so which I won’t try to document here.
Another approach which doesn’t have that downside is to use eCryptfs instead of LUKS. It stores each encrypted file separately (with an encrypted name) and thus doesn’t hide the directory structure or file sizes - only directory and file names and file contents are encrypted. It also appears to have not been updated since 2016, but, it is still included in various distributions so it is also an option. You can read about how to use it (and other caveats about it) on the arch wiki.
I use Cryptomator. Does exactly what you describe.
Just be aware you can lose your data. It is really bad with long file names and folders with a large number of files, there are multiple reports online about people losing their data. I personally have experienced this with large file names and once an entire vault that suddenly couldn’t be open.
I’m pretty sure most of the reports online is rooted back to user error.
That doesn’t help the people who lost data.
And the reports are common enough that it suggests cryptomator should consider making some interface changes.
I’m just saying it’s not going to randomly brick your data. Just be cautious when performing tasks.
That’s fair. But I’d still be really wary of something with a reputation for eating data just because a user looked at it funny.
I have used gocryptfs (https://github.com/rfjakob/gocryptfs) in the past, it creates an overlay mount that encrypts each dir and file separately, so no need to precreate a container. There are some security downsides to this approach though so be aware of that. https://nuetzlich.net/gocryptfs/threat_model/
EncFS, CryptoFS, eCryptFS…
that creates encrypted archives, but doesn’t provide a mountable filesystem (which is what OP means by “real-time”).
Ah ok, well LUKS in that case I guess
Ext4 encryption
