In most scenarios, one of the following three schemes works well.
You only want to encrypt a few particularly confidential files.
Use encfs:
mkdir ~/.encrypted.d ~/encrypted
encfs ~/.encrypted.d ~/encrypted
editor ~/encrypted/confidential-file
Pros: no overhead to access non-confidential files; you can have different hierarchies with different passwords; you can easily copy a whole hierarchy of encrypted files to another machine; you don't need any special permissions to use encfs.
Cons: only encrypts files that are explicitly placed in the encrypted area; a little slower than disk-level encryption if you're going to encrypt a lot of files anyway.
You want your whole home directory to be encrypted.
Use ecryptfs.
Pros and cons. In a nutshell, ecryptfs works especially well when you want to encrypt your home directory using your login password; this is what Ubuntu uses if you tell the installer to encrypt your home directory. One con is that it's more difficult to ssh into your account, because if you're using key authentication for ssh, your public key must be placed outside the encrypted area and you'll need to type your password after ssh'ing in.
Whole disk encryption.
Use dm-crypt to encrypt everything except /boot.
Pros: everything is encrypted, so you don't have to worry about accidentally putting a file in the wrong place; block-level encryption provides better speed, especially if your processor has a hardware accelerator for AES (AES-NI on x86).
Cons: you need to provide the password at boot time, so you can't do an unattended boot; everything is encrypted, which can be slow if your processor is slow.
General notes
If you don't go for full disk encryption, remember that some temporary copies of your data may end up outside your home directory. The most obvious example is swap space, so if you're going to use encryption to prevent from a thief from reading your data, make sure to encrypt it (with dm-crypt). Since swap space is reinitialized at each boot, you can use a random key for it, and this way you can do an unattended boot (however, this makes hibernation impossible).
Put /tmp under tmpfs (it's a good idea anyway). See How to (safely) move /tmp to a different volume? for how to migrate /tmp to tmpfs.
Other at-risk areas are the mail drop (/var/mail) and the print spooler (/var/spool/cups).
Best Answer
The “filesystem type” in a PC partition is actually a volume type, or more precisely a usage type: it's really supposed to indicate which operating system the partition belongs to (e.g. Windows vs Solaris vs FreeBSD), and what it's supposed to do with it (e.g. nested partition of some kind vs filesystem vs swap). In practice, different OS vendors have made different choices and it's a bit of a mess.
For example, 83 is not “ext[234]” but “filesystem for Linux”. For anything using the
dmlayer, the convention is fd (“Linux raid”). This covers not only RAID but also dmcrypt, regardless of what filesystem or nested container (e.g. LVM) is on the encrypted volume.But this is just a convention — Linux itself doesn't care about the type field except to mark unused partitions and extended partitions.