Replacement for Truecrypt?
I've recently made the switch from Ubuntu to Trisquel (at least on one of my two computers so far). I've been using Dropbox in combination with Truecrypt to safely sync some files between my two computers. However, while browsing this forum I found out that Truecrypt is not free at all (https://trisquel.info/en/forum/lastpass), but there was no suggestion of what to use instead. It seems that Syncany would basically replace my Truecrypt/Dropbox combo, but what if I just want to encrypt files locally? What should I use?
As I don't use truecrypt or dropbox how does that combination work? Meaning are the files encrypted on disk and then you upload them to dropbox?
You can use GNU Privacy Guard to encrypt folders or files.
I'm not really sure how to do this in a point and click friendly way although you could create a tar.gz file (probably a right click on the folder to create in nautilus or whatever archive program you use) and then use GPG to encrypt.
As far as whole disk encryption goes the consensus from free software privacy projects like Tails seems to be to go with LUKS and use the Gnome Disk Utility. Of course I'm not really sure how this works with Trisquel 5.5. I'm imagining the Gnome Disk Utility is not installed in Trisquel 5.5 and I don't know if you can get it separately in a sane way. I think this is also really applicable to Gnome 2...
Take a look here for some directions that you shouldn't be able to follow due to the changes in Trisquel's user interface although might still lead you in the right direction on finding it in Trisquel 5.5:
GNOME'S Palimpsest Disk Utility is installed by default in Trisquel 5.5. You can find it in Applications > System Settings or launch it directly from the executable "palimpsest".
Encrypt partitions with it is self-explanatory.
The only solution, as far as I see it, is using encfs with cryptkeeper(GUI), just "apt-get install cryptkeeper" and use either the GUI or the encfs (man encfs). You should place the encrypted folder in dropbox and the mount point elsewhere.
From cli should look like this:
encfs ~/Dropbox/.crypt ~/crypt #for mounting/creating fusermount -u ~/crypt #for unmounting
If uploading the whole container is ok for you (since you used truecrypt) you can try using a luks container; it would be something like:
$ dd if=/dev/zero of=/luksfile bs=1M count=2100 $ losetup /dev/loop0 /luksfile $ cryptsetup -c aes-xts-essiv:sha256 -y -s 512 luksFormat /dev/loop0 $ cryptsetup luksOpen /dev/loop0 crypt $ cryptsetup status crypt $ mkfs.xfs /dev/mapper/crypt $ mount -t xfs /dev/mapper/crypt /mnt $ chmod o=rwx /mnt $ umount /mnt $ cryptsetup luksClose crypt $ losetup -d /dev/loop0 # free the loopdevice $ mv /luksfile ~/Dropbox/luksfile # For mounting you would use something like: $ losetup /dev/loop0 ~/Dropbox/luksfile && cryptsetup luksOpen /dev/loop0 crypt && mount -t xfs /dev/mapper/crypt /your/desired/mountpoint # For closing you would use something like: $ umount /your/desired/mountpoint && cryptsetup luksClose crypt && losetup -d /dev/loop0
You might also want to try Tomb which is also used by dynebolic:
I use it to store data safely on my USB stick. It works fine under Xubuntu as well as under Linux Mint. So most Debian-based distris should do fine.
I forgot about Tomb.
I haven't use tomb and I'm curious what exactly is suppose to do, I suppose container encryption, right ?
Can you tell me to what extent the hidden filesystem claim from its homepage is true, does it have some kind of plausible deniability ?
True, tomb provides container encryption. You have a file which holds the encrypted data and one file which holds the key required to open the container (called tomb). You are able to burry the key file inside an image (which is called steganography). I think the "claim" at the cover page about hidding the tomb file inside a filesystem does not really mean you can actually hide the file itself. It is more that you can copy the tomb file somewhere to your directory tree and without the key file it will be pretty hard to figure out the purpose of the file.
I suggest you simply read the man page yourself and find out what tomb can do and what it can not do:
Thanks for responding Darksoul71,
I already checked the documentation from the site, including the man page.
I was hoping that I missed something and it has some plausible deniability for the container not just the key.
You are welcome ! For further questions I would simply contact jaromil over at dynebolic. I guess the part of hiding the container is a bit exegerating.
I think it's an excellent idea as if the container is not hidden you can be coerced by authorities around the world and by various criminal organizations as well to reveal passwords.
Not bulletproof, but acceptable, is:
cat file.jpg crypt.zip>out.jpg unizp out.jpg
I couldn't figure it out how to extract the second file if it's not in a zip container (not archived).
@lembas: I disagree !
A hidden encrypted container will not help in any scenario. Those with a serious interest in your data would torture you so long until you tell them that there is a hidden container. Those who steal your notebook or want to copy your data will make a full clone of your drive anyhow and most likely will be able to find out about hidden partitions since nothing can really be "hidden" if you need to retrive / open the container to work with it.
Persons who travel to the US for example should not port a notebook with date anyhow. They are best of with a clean HDD without any data / OS on it (dd if=/dev/zero of=/dev/your-drive). After they arrive they should access their data stored on an external server via secure connection and download their stuff. A live GNU/Linux distribution plus access to your data via sshfs or sftpfs will most likely work pretty transparent since your can use FUSE to access your remote data like a local drive.
IMO the same goes for people which sensitive data. No sensitive data should be stored on your local drives in case of a house search. Today it is pretty easy to store data at some server you can trust (e.g. running owncloud on a remote server outside your country / running an sftp server which keeps your tomb file).
Thanks for all the suggestions! I'll look into them and see what fits the bill for me.