Linux Mint's installer supports LUKS encryption of the entire disk or of individual partitions. The Linux Mint Installer is by far the easiest method of setting up an encrypted region of a disk, because it can be done completely in the GUI without need for any terminal commands, and much of the process is automated.

At this time, there are good tools available via Software Manager that can also create new encrypted volumes, such as Cryptkeeper, of which, notably, the latest stable version is offered by our Software Manager. It is possible to have Windows and multiple Linux operating systems installed on various partitions. The one thing to keep in mind is that Linux Mint's installer will not arrange such a complicated setup for you automatically, because it is not a mind-reader. The partitions must be set up manually, using a combination of Gparted (available on the Linux Mint install DVD) and the Linux Mint installer itself.

The Linux Mint installer is rather basic, designed to assist most users for most needs, rather than the specialized needs of those with multiple operating systems. Therefore, partitions should be set up using Gparted ideally, prior to running the installer. Trial and error has shown that the installer requires a single unencypted /BOOT partition, an absolute requirement, because otherwise nothing can be loaded at all on an otherwise encrypted disk. This partition need not be long. A gigabyte or less, possibly even as little as 100mb, is ample. Another requirement is for the /, or root, partition. This you may or may not want to encrypt. I suggest encrypting both root and /home to have a completely secure operating system, because I am not sure what is stored by the operating system under various scenarios and whether there may be things left behind that might compromise an encrypted volume.

Setting up the partitions with a combination of Gparted and the Linux Mint installer is fairly easy. The installer configures the encryption, while Gparted is useful to partition the drives. Partition the drives first, and then run the installer once you have everything arranged. The installer is user-friendly and will report an error if it does not have what it requires. If the installation gets botched, then you can always reinstall. Gparted in my experience is reliable and user-friendly, but there are certain conditions that can trigger a crash. It will confess if it encounters any kind of problem that requires rebooting. Patience is key. You should exit the installer prior to making any modification via Gparted, because the installer reads the partition information early in its process.

The one drawback to having an encrypted root and then an encrypted /home on another drive is that the user will be prompted to enter a password not once, but twice. This is a hassle, when only one password should be necessary.  There is probably not additional protection to be gained from a two-password arrangement, either. For convenience, I like to have one password rather than two. As usual with Linux, where there is a will, there is a way. To automount the /Home partition, I refered to this article on askubuntu, which I reproduce here, along with my notes and examples.

 Example:
sda8_crypt UUID=blah-de-blah none luks,discard
sdb5_crypt UUID=blah-de-blah /etc/crypto.key luks,discard

 Use gedit to modify this file, as in: sudo gedit /etc/crypttab

Be very careful.

The "luks,discard", above, is added by default during set-up. 
I do not recommend tinkering with these values! The only thing 
that needs to be changed is the location of the crypt key. 
It may be set to "none" if a passphrase is to be employed instead.
It may be possible to be locked out of a volume if there are syntax
errors in the crypttab.

---

Notes:

important! The location of the key file must be chosen with great care. The "secretkey" and "/etc/crypto.key", above, refer to the actual path and filename of the crypt-key. Any filename would work. The important thing is to store the key in an encrypted area, so that it cannot be accessed without first unencrypting the location. Storing the key in /Boot would completely defeat the purpose of encryption, because /Boot must be unencrypted and can be read by anyone.

I like to store the key file in /etc, assuming that the root partition is encrypted. Cryptsetup, with the above syntax, will prompt you for a valid passphrase. Then it will add the key file as one of the "keys" along with any passphrases you have stored. You can store many passwords and key files, not just one.

Our intent in this article is to avoid typing in a passphrase to access two encrypted volumes, when only one passphrase should be good enough. For this purpose, a crypt-key file is absolutely necessary. However, if for some reason you wish merely to have a passphrase, rather than a key file, then the syntax becomes:

cryptsetup luksAddKey /dev/sda2

Where, again, /dev/sda2 would be replaced by whichever /dev/sd? you wish to work with. Consult your partition managing program.

The program will prompt you for your existing passphrase and then allow you to enter another passphrase, which then become a second and equally viable means of unlocking the crypt.

To remove a passphrase, if, for instance, you wish to substitute a stronger passphrase for a weaker one, use this:

cryptsetup luksRemoveKey /dev/sda2

Be extremely careful with the above syntax. In fact, do not use it unless you have a recent, full backup of your data. There is no known way to recover a locked encrypted volume save by brute force. It is very easy to be locked out of your own data! The usual method to recover the hard drive space is by erasure and reinstallation, assuming a backup exists.

---

On a related subject:

Should you even bother with the command-line to create encrypted partitions?

My conclusion is no.

Eye explain why at the end of this article. If you are interested in my evaluations of the most popular command-line utilities, read on.

---

Cryptkeeper

Cryptkeeper, mentioned at the beginning of this article, seemed worth exploring, although its default configuration will seg fault in Linux Mint Cinnamon 17.3, which probably explains its less than five star rating in Software Manager. The problem appears to be one of permissions only, because it runs fine if granted root privileges via sudo or gksu. However, my success has been limited to Cinnamon only. I have not yet been able to get it to run in Linux Mint 17.3 XFCE, even with root privileges. Also, Cryptkeeper misbehaves even with root privileges. Sometimes it only runs from the terminal, and sometimes it does not seem to run at all. I think that if the user has a root session anywhere, it will not run. The root session must first be closed.

Cryptkeeper is a handy tool that can be placed in the panel and then activated to decrypt volumes "on the fly" on an as-needed basis. With this tool and some others (cryptsetup, I believe), it is possible to encrypt volumes without the Linux Mint installer. It may also be possible to decrypt on the fly "hidden" volumes. The Cryptkeeper author's web site is worth visiting for its various Linux-related and other curiosities.

As mentioned in the comment section below, the reason I like Cryptkeeper is because it offers a GUI and can live in Cinnamon's panel with some minor tweaking (i.e., gksu cryptkeeper as the command-line syntax). However, it is not necessary for the set-up described in this article, where we encrypt an entire operating system using Linux Mint's installer. I would only use it for cases where certain volume(s) are encrypted and only need to be accessed occasionally, not every time. If you do not plan to mount at boot, then Cryptkeeper (or cryptmount, as pointed out below in the Comments section) will be of service.

A good walkthrough of Cryptkeeper's functionality, with screenshots galore, can be found here.

The reason cryptkeeper doesn't work worth a flip in Linux Mint 17.3 can be viewed here. The last version was released in 2010, and there wasn't even that much done in 2010. It is basically unmaintained and no longer compatible. To use it, you may need an older version of Linux Mint, one that was around in 2010. Of course by using such an old version, you could become less secure for many reasons, such as known vulnerabilities that have since been patched. I would not recommend going the "old version route".

----

Cryptmount

Cryptkeeper, above, has proven to be unreliable in Linux Mint 17.3, working sometimes but not all the time for all people. I think certain software libraries or updates cause it problems due to incompatibility. It no longer works on my system for some unknown reason.

A good alternative to cryptkeeper is cryptmount, which however lacks a GUI. A good tutorial to cryptmount may be found in an article written by Carla Schroder in 2008. An important bit of info from that page follows:

Encrypted Filesystem Inside a File

You don't have to encrypt an entire partition, but can create an encrypted filesystem inside an ordinary file. Use the cryptmount-setup script to do this.

Ms. Schroder goes on to offer a helpful example that I referred to often in my experiments:

# cryptmount-setup
   Please enter a target name for your filesystem
   [opaque]: mystuff

   Which user should own the filesystem (leave blank for root)
   []: carla

   Please specify where "mystuff" should be mounted
  [/home/carla/crypt]:

  Enter the filesystem size (in MB)
   [64]: 1028

   Enter a filename for your encrypted container
   [/home/carla/crypto.fs]: /home/carla/mystuff.fs

   Enter a location for the keyfile
   [/etc/cryptmount/mystuff.key]:

  enter password for target "mystuff":

Your new encrypted filesystem is now ready for use.
To access, try:
   cryptmount mystuff
   cd /home/carla/crypt
After you have finished using the filesystem, try:
   cd
   cryptmount --unmount mystuff

One thing the article does not mention is that cryptmount-setup takes a long time to run if you select a very large size. It apparently treats every single byte in the allocated region. I tried to leave a comment on the article, offering the observations you may read here, but on my browser the text fields for username, subject and text body had a white font on a white background, making it very difficult to type a message, and in addition to that an illegible captcha was required, so I concluded the site does not want any comments. In the eight years since the article was posted, there have been zero comments.

A problem with crypt-setup unmentioned by the article is that, when encrypting a large file, the sudo (root privilege) will eventually timeout, and then cryptmount-setup will be unable to write to cmtab. Cryptmount and cryptmount-setup both store information about encrypted volumes in a file named cmtab located at /etc/cryptmount. Cryptmount-setup must be permitted to write to this file at the end of its encryption procedure, but if sudo has timed out, it will not be able to do so. To overcome this pitfall, we may want to extend the sudo lease prior to running cryptmount-setup:

Run sudo visudo and add this line: Defaults timestamp_timeout=-1 See man 5 sudoers. -1 causes the password to never timeout. You may change the number to whatever you like in minutes. The man page for sudo says that sudo -v "extends the sudo timeout for another 5 minutes". Running 'sudo visudo' instead of editing the file directly causes the system to validate the sudoers file before it commits the changes. For instance, if you leave a stray character somwhere, when you save and exit, it will say "there is an error in the sudoers file, what would you like to do?" ... hence giving you a chance to go back in and edit. This actually just happened to me 10 minutes ago.

The above is taken from here. There are potential security downsides to extending or (as above) eliminating sudo's timeout, but for a single user system, perhaps the risks are less. A more conservative approach would be to extend the timeout to, say, five hours, which would accomodate most tasks that require root access.

Cryptmount requires patience to learn how to use. Its ways seem foreign to those unversed in the ways of encryption, but above that, it requires planning and foresight to use. In the first place, cryptmount-setup requires root privileges, i.e. running with sudo. Also, it will not function in Linux Mint 17.3 without modification prior to its first use. It is just a script, however, and can be easily modified.

Enter: which cryptmount-setup to learn where it is stored, and then sudo gedit [full path to cryptmount-setup] to modify.

At the beginning of the script is a global variable, @ETCDIR@, or some razzamatazz to that effect. Replace it with the proper path. To be precise, line 11 in the file must read :

CM_CFGDIR="/etc/cryptmount"

in order for the script to function properly. Otherwise, expect an error toward the end of the script.

Another must-do for cryptmount is to make certain an entry exists in fstab for the location you wish to store an encrypted file upon. This is not an issue if you are storing your file in the home directory, but if you store it on, say, a USB drive, then cryptmount will work only if that drive is properly mounted. There is probably a nifty mount command to do this on the fly, but I only achieved success after adding an entry in fstab to this effect:

UUID=blah-de-blah       /media/sde3     ext4    nobootwait,noatime    0 0

And this has the added advantage of being a permanent fix, because your system will always mount the drive if it is available and not worry you about it if it is not (due to "nobootwait"). Remember, the UUID is easily determined by running our wonderful old friend, GPARTED, which is useful to gather information, format partitions, make and resize partitions, and serve bagels with butter and Marmite.

Now, say that you want to create a crypt that takes up the majority of a partition's space. You would be only logical to specify a size matching or near the free space on that partition, and you would be courting disaster, because cryptmount is going to create a file just a bit bigger than your specification, until there is no free space left on the partition. A vague error message ("device is busy") will be your only warning that something is not right, besides Linux Mint 17.3 Cinnamon's alert of no free disk space. The workaround to this is to specify about 5% less than the total free space available.

I suggest creating several very small crypts for testing purposes prior to embarking on any large project, because the foibles and potential pitfalls are many, error messages are not always fully elucidating if at all present, and it is not always obvious that a mistake has been made preventing proper function. That said, this may be the best free tool available at this time for the purpose...

---CONCLUSION---

I have been unsuccessful in all attempts at getting dm-crypt, cryptmounter or cryptkeeper to work in the expected manner. There may be issues with bugs and incompatibility, and there may also be issues with insufficient tutorials and documentation. At any rate, after many hours of research and experimentation, I conclude it is not possible for me to use these utilities on my machine at this time. I think cryptkeeper is completely hopeless, but cryptmount and dm-crypt give the poor user very cryptic error messages and offer little guidance. I do not understand what they are saying, and research on Google has not explained the error messages. They are both of them not at all intuitive or user-friendly. You have to basically become an expert on encryption before you can use these things.

A friendly fellow Linux Mint user, MagicMint, offered the following advice to me:

Actually, I didn’t use cryptmount manually at all, I had just installed it (long ago in LM 14, but it survived the upgrade to LM 17, and it’s still working), and I used the Disks utility to setup the (external) disk. You have to choose More Actions› Format…, where you must set “Encrypted, compatible with Linux systems (LUKS + ext4) as its type, give it a name and a passphrase — that’s it.

In case of an external drive, Nemo will automatically ask for the password, but for an internal one, you’d have to click on it. I don’t see any point in auto-mounting such an internal encrypted disk, because it would be protected by the much weaker login password then. It should be possible to do it, though, but I’ve never tried. It’s certainly not easy to do it manually, I guess ;-)

As far as cryptmount is concerned, credit goes to @hatteras for his post on the forums: Encriptar un pendrive ;-)

I had once fallen within the same trap with command-line utilities like you, when I wanted to use TrueCrypt. IMHO, all these utilities are poorly documented, and they will fail inevitably with the smallest change in the crypt architecture. Since then, I prefer graphical utilities by large — not that they were more stable, but they are undoubtedly easier to set up, thus they can be checked very fast whether they will work or not.

In this mindset, beside (the invisible) cryptmount for external drives, I’m also using ecryptfs for my “Private” folder (in the ArchWiki setup for Ubuntu tools; it’s a single click encrypt or decrypt the whole directory), and gnome-encfs-manager for everything else (e.g. for network storages).

MagicMint refers to the Disks utility, which has a GUI that really works, thank all the gods and godesses. See Menu -> Preferences -> Disks. Click on the desired partition, then choose the symbol that looks like gears (Settings). The Format option, as pointed out above, is the one that supports encryption.

This is one of those rare, unexpected situations in Linux where a GUI can actually do a lot more than the command-line and do it faster and better.

The Disks utility actually looks about fifty flavors of Awesome, and I see a lot of other capabilities that it has as well. Its web page is here. This is more like it. I don't want to learn the art of cryptography, I just want to encrypt a drive or two for people who need it.