Replacement for Truecrypt?

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:

https://tails.boum.org/doc/encryption_and_privacy/encrypted_volumes/index.en.html#index1h1

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:
http://tomb.dyne.org/

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.

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:
http://tomb.dyne.org/manual.html

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.

@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.