ENCRYPTION

Updated 12-3-2013

Encryption lets you save data without your enemies being able to read it. Do not rely on it for shit that could send someone to jail, though, as we never know when new codebreaking tools may be invented.

PGP FOR EMAIL:

Get PGP (or for Linux GPG), and use it whenever you need to send a semi-sensitive email somewhere. Do NOT use it for anything that could send someone to jail, because you don’t know how secure the recipient’s computer is. Reading it from an unencrypted desktop not on RAM is quite enough to leave recoverable traces. Either encrypt your disk (see below) or use a firefox-on-ram or home-on-ram script (from the main computer security page) to prevent this-on BOTH ends!

Hushmail offers PGP encryption, but as they store the private key they can open it with a search warrant from a Canadian court. If you use GPG/PGP on your own computer, YOU have the key and no email provider, not even Gmail, can open it no matter what any court says.

DISK AND FLASH DRIVE ENCRYPTION FOR YOUR COMPUTER

Public computers:

If you are administering one

If a machine must be left on, don’t store encrypted data on it!
If a machine must be left on (public access, for instance) and also handle encrypted email, etc, use a live disk or (for better performance) the “home on ram” script from the computer security page with a normal install of Linux. You can include Truecrypt or Cryptsetup(for DM-crypt) to use encrypted flash drives for external storage without fear of temporary files if swap space is either disabled or encrypted.

If you are using one

Assume a keylogger may exist on any unknown public computer, do not trust it with encryption. They are commonly installed on public computers by malicious third parties after email and Facebook logins and/or online banking information. Even if you think common criminals won’t care about your work, remember that some of them are also paid snitches.

If you must bring information to an unknown public computer encrypted, encrypt a cheap flash drive with a one-time passphrase to protect your data prior to use, then destroy the flash drive immediately if the information is important. For things that can’t put anyone in jail you can fill the flash drive with random numbers (whole device) with dd after you get home, then make another encrypted filesystem on it. Never use the same passphrase again, it may have been logged and still be on that computer.

In some cases you may be able to run a live Linux distro disk (LinuxMint with MATE suggested) on a public computer elsewhere, thus taking the entire operating sytem with you when you leave. Nothing to encrypt as all data is in RAM. Power the computer down and reboot to erase everything. Obviously you have to be able to reboot to run a live disk, rebooting again back to the normal OS removes all traces of your work. You can keep anything you want to save on an encrypted flash drive, in this case with good security unless a HARDWARE keylogger has been installed. Check the cables at the back of the computer, look for any “adapters” between the keyboard and the computer. In some cases a USB keyboard might be on an adapter to a PS2 port,remove the adapter and plug the keyboard right into a USB port. It is EASY to get a keylogger disguised as a USB to PS2 adapter, treat all such adapters as keyloggers unless they are your own!

ALL OTHER COMPUTERS:

DO NOT RELY ON BITLOCKER in Windows Vista-it may have back doors for law enforcement, etc.

If you must use Windows, the only way to securely encrypt it is to install the entire operating system on a hard drive encrypted with truecrypt. This works in Windows, Linux, even Mac OS X.
http://www.truecrypt.org/

In most recent distros of Linux, you have DM-crypt
http://en.wikipedia.org/wiki/Dm-crypt
installed by default or on the install disk for disk encryption.

DM-Crypt supports the same ciphers as Truecrypt except that “chain ciphers” of multiple encryption modes are not supported. AES, Twofish, Blowfish, etc. With cryptsetup, always use theLUKS key management system. With it,you can have multiple passphrases for multiple users, can shitcan and replace a compromised key, and dictionary attacks are slowed by a factor or more than 1,000.

INSTALLING ENCRYPTION ON LINUX COMPUTERS:

If you don’t know what you are doing, get a Mint 15 or later installer and select “Encrypt the new Linux Mint installation for security” in “installation type.” This will install the entire OS as a totally encrypted disk similar to Windows(or Linux) on Truecrypt. Only the /boot partition and bootloader are not encrypted, everything else will be in LVM volumes(sub-partitions) on a single encrypted partition opened early in the boot process with your passphrase.

This is absolutely the easiest way to get a secure encrypted setup, and the only way to go for a beginner. If you are not FULLY comfortable working with UINX/linux commands from the command line, this is the only way to go for a fully encrypted disk. Both LinuxMint and Ubuntu also offer later in installation an option to encrypt just your home directory using the login password but you then must use your good encryption passprase for login and all system admin tasks! In addition, a hash of that passphrase will be in /etc/shadow and can speed up dictionary attacks tremendously. Do not use this method when using encryption to keep anyone out of jail.

If the machine will ever be left unattended, even turned off and cold, against opposition that knows computers, the entire operating system must be encrypted. A totally encrypted disk limits keyloggers to online attacks while running or to an “evil maid” remake of the boot initial filesystem (initramfs), which cannot be encrypted but is far smaller and FAR easier to check than a whole unencrypted root partition.

ENCRYPTING AN EXISTING INSTALL:

You need to really know your way around Linux to do this, if you are an expert wanting to save a finely-tuned and customized operating system this is how you do it. There are lots of ways people do this, here’s what I do:

First, install Cryptsetup, and if you are encrypting the whole system also install LVM

Since you will need encrypted backups later, I suggest making your encrypted backup now and ensuring that you can close and reopen it. Once you are confident you can get back into your encrypted backup disk, delete everything in your old home directory. You must now fill the partition with random numbers-all of it-to securely erase your old data. When that is done, delete that file. Do the same for the /root partition if it was a separate partition from /home so as to overwrite any “deleted” file in /tmp.

If only encrypting /home

Resize the root partition to somewhat larger than just the OS if you were not already using a separate /home partition, 7-10GB is about right. Now make your new /home partition (if not reusing a separate /home partition), make your encrypted device on it, make a filesystem on it and mount it.

Copy your data back from backup, add an entry for the /home volume’s name, which will be /dev/mapper/(what you named it) to /etc/crypttab and /etc/fstab, and put /tmp on a RAM filesystem(tmpfs). dd 2 GB of zeros for a swap file onto the encrypted /home if you need swap, mkswap on it, and add an entry for it to /etc/fstab, update-initramfs -u and you are done if nothing went wrong. Test and fix. Cryptsetup will detect your entries in /etc/fstab and etc/crypttab and prompt you for the passphrase to unlock /home so it can be mounted.

If Encrypting the whole disk

If you encrypt everything but /boot (strongly recommended!),you will eventually put /home on one partition, swap on another, and everything else (root) except /boot on a third partition. These will be three partitions on an underlying encrypted partition set up for LVM .This way you only have to unlock one disk with a password.

If /home was in the same partition as the root filesystem, a few extra steps are needed. If it was separate, you are in luck as you can use dd to copy your filesystem out before rebooting. Just dd the entire root filesystem to an image file anywhere in /home, then loopback mount it and check it with fsck. When you get a copy that passes fsck, compress it to a tarball and check that the tarball opens and extracts properly. Next, copy the tarball to a flash drive, you will use it for an installer. If /home is on the root partition, you cannot dd the partition without also copying that huge /home directory, and it won’t fit! In that case you will need to reboot from a flash drive/live disk, shrink the root partition to accomodate just the root filesystem, then make and compress your dd image. In either case you end up with a dd image stored on a flash drive, and you will need a live disk or flash drive OS with cryptsetup and LVM installed in its OS

Reboot from a flash drive or a live disk containing any Linux OS of the same architecture you are encrypting (32 or 64 bit, etc).

Delete all partitions and make two new ones: The first one is /boot, it should be about 250MB. The second one is all the rest of the disk. Close the partitioner, make a filesystem (ext2, ext3, ext 4 all work) on partition 1, and make an encrypted LUKS device on partition 2. Make sure to use key-size 256 and specify–use-random for high quality key generation and the toughest encryption to break. You will now need that long passphrase, entering it twice to verify it in encrpted device formation. Now “cryptsetup-luksOpen” your encrypted partition, and use the LVM tools to make three LVM volumes or sub-partitions on it. The first should be 7-10GB, for the operating sytem. The next, 2GB or however much you want for swap. All the rest, /home.

It is strongly advisable to fill all three encrypted partitions with random numbers (dd if=/dev/urandom of=(the mounted filesystem/shredder)) before copying any filesystems to them or to hdparm –security-erase-enhanced the entire disk before partitioning if the disk is not one that finishes this with zeroes. At the very least, fill them up after you finish if they have ever held unencrypted information you are worried about! When this is done, make ext 4 filesystems (or whatever FS type you use) on the first and last LVM volumes, and mkswap on the small one. Mount both filesystem partitions somewhere, I use /media/root for all target root filesytems, use any extra mountpoint for the future /home partition for now. Next, copy your tarball containing the image of the old filesystem into that new /home filesystem and uncompress it. Loopback mount it somewhere, I use /media/loop. Mount the FIRST partition on /media/root/boot so it will pick up all the /boot files!

Next, cd to the directory containing the former root filesystem, then cp -ax * the whole directory to the encrypted but unlocked and mounted destination filesystem. That will copy every file physically on that device to the new location, and (very important) preserve all file permissions, owners, etc.

Now we make the new OS bootable. Open /etc/fstab and /etc/cryptab for editing. In /etc/crypttab you need an entry with the source device, a name, key file “none” option “luks” to open the single encrypted partition. You need entries for your encrypted / and /home in /etc/fstab, and the boot menu needs to reflect root=/dev/mapper/(name of first LVM volume). For later updates, fstab can mount your boot partition on /boot, or it can be left out to allow “hash checking” /boot for tampering followed by manual mounting for any upgrades.

BE SURE to create a directory with your username in the empty /home on the new root filesystem, and chown it to your username, in case /home ever fails to mount. Make sure that everything in the old /boot directory was copied directly to the new /boot partition, so that the whole partition always mounts on /boot later

Then comes the hard part that seems to create the most errors. You must remake your boot files to boot into the encrypted filesystem. To do this, bind mount /dev, /proc, /sys, and /run in the OS you booted from into the destination OS directory and chroot into it. This chroot is why your installer and target OS need to be the same architecture. From there run update-initramfs -u , grub-install (to the target disk) and update-grub. This will make the files you need to boot.

Test boot, do not be surprised if you screwed something up and cannot boot just yet. I’ve installed this way many, many times from saved disk images, yet rarely get a trouble-free first boot. Worst is if GRUB cannot find the GRUB menu, otherwise you can enter parameters by hand to get the kernel to load. If the initramfs didn’t work, changing the command line options to end with “ro break” instead of “ro quiet splash” will load the kernel, then stop the boot process, spawn a “busybox” shell and let you run cryptsetup by hand to unlock the disks. Then just type “exit” and boot resumes. Once booted, update-grub and update-initramfs -u if the GRUB menu was working. If it was not found and you had to “cross-boot” from another disk, also redo “grub-install.” When everything boots smoothly, you got three things left to do:

COPY YOUR DATA BACK FROM THE BACKUP

CHECK TO SEE THE DISK IS REALLY ENCRYPTED! Yes, I once saw Ubuntu ignore a request to encrypt a /home partition, was able to mount it without decryption from another operating system. However you encrypted your system, boot from a live disk, flash drive, or whatever and attempt to mount your hard drive. You should NOT be able to read ANYTHING except the /boot partition if you did a whole disk encryption, nor /home if that was all you encrypted. With many live disks and any flash drive with Cryptsetup installed, you may be prompted for a passprhase to decrypt the volume. If you get this, your encryption worked. If the filesystem cannot be recognized and looks like random data, your encryption worked. The one time I ever saw it fail (that bad Ubuntu installer), I got a readable filesystem WITHOUT being prompted for a passphrase, on a volume I had not previously decrypted and saved the passphrase in a “gnome-keyring.” Do not “keep passphrase forever,” on disk in the keyring, in any unencrypted system, BTW.

MAKE AN ENCRYPTED BACKUP HARD DRIVE if your backup was not encrypted! This can be a flash drive, and old hard drive, whatever will hold your files. You need backups, but if they are not encrypted too anyone finding them has all your files. Since a disk failure that kills the LUKS header kills the internal disk key, data recovery is impossible as well as untrusted if you ever lose those blocks. Never, ever trust a single, non-backed up disk with anything you want to keep, and this goes double with encryption. Again, fill up all empty space with random numbers unless it is new to overwrite old, non-encrypted data, as just making the LUKS header, etc does NOT do this!

Once you have an encrypted system disk and encrypted backups, your date is well enough protected that most cops never even SEE something like this, but never bet a court case on it-never write to a disk anything that could send someone to prison, as you never know when someone will build a “quantum computer” that does to encryption today what computers did to pre-computer ciphers other than the one-time pad. We all know what happened to those Nazi scum in WWII, who so relied on their “enigma” cipher machines that the ability of Britain to crack it cost them the war.

GENERAL ENCRYPTION SECURITY:

A secure DM-crypt encrypted volume MUST use the “LUKS” key management system
http://en.wikipedia.org/wiki/LUKS
to provide protection against dictionary attacks
http://en.wikipedia.org/wiki/Dictionary_attack

The passphrase is, in fact, the weakest part of any encryption system. It MUST be at least 25 characters long, preferably more, to resist a brute-force attack trying all possible combinations of letters, numbers, and symbols, even if it is totally random characters. These make the strongest possible passphrase, but few can remember them so words and phrases are common. This bring in the “dictionary attack” where all the words in a dictionary are tried one after the other, plus permutations of them. This is very quick (as in less than a SECOND) to break most one-word passwords.

If a word-based passphrase is used, the number of words should be enough (I suggest more than 10) to make dictionary attacks by combination of words too time consuming. Assume a 20,000 word dictionary times 3(capitalized, smalls, all caps, plus 10% for permutations) or about a 63,000 word dictionary if you capitalize and/or modify some of the words, This raised to the power of the number of words, and needs to be significant relative to 2 raised to the 128 power-a 128 bit binary key being the smallest you should use, with a 256 bit key believed to be more secure.

WARNING: a sentence that could ever have been written in any book or crossed any electronic network is far less secure, so much so as to reduce security to only about 1 bit per character! Same if it follows any common or guessable pattern. At the other extreme, the randomness or “entropy” (that is to say the security) of a random character passphrase is 4-6 bits per character, depending on the character set used.

Due to this, experts now advise that it takes 60+ characters in a word/sentence based passphrase to be secure against a 3-letter agency (NSA, etc). In the absence of something like LUKS or the passphrase armoring used in PGP/GPG, this rises to 80+ bits, thus 80+ characters. That level of security will defeat any government agency on the planet.

The mode of attack that can reduce character entropy to the 0.6-1.3 bit level in a sentence is probably the attack based on trying all possible sentences or fractions of sentences from a concatenation of books as the words in a dictionary-type attack. This is much, mush faster than a brute-force attack, in which all possible combinations must be tried. The attack fails if the dictionary does not contain the words or phrases used. For sentences or phrases this “dictionary” should be presumed to potentially be the combined total of all books, papers, articles, and Internet posts ever written. All possible sentences and phrases could then be computed from it and overlapping possibilities eliminated, thus yielding a far shorter attack than straight brute-force. This still leaves the time required to compute each hash though, making the process tens of thousands of times slower than getting the passphrase for which you already have the hash (like login password recovery).

Although 60+ bit disk encryption keys have been brute-forced sucessfully, it’s much faster to try a key directly than to compute the key from the passphrase in a LUKS based system due to the 1 second or so time to compute each possible key. The LUKS key management system seems to provide about 20 bits worth of added security.

NEVER use your encryption passphrase for anything else, and never write it down. Of course, if you forget it, you lose your data so pick a good one and memorize it before setting up your good encrypted machine. In Linux with DM-crypt and LUKS, you can change your passphrase as long as you have the old one, and then delete the old one, so you can start with a simple one, add a second “key slot” with a good one, get it memorized, then delete the first “key slot” with the weak passphrase.

NEVER leave an encrypted machine turned on when you leave the building, and PULL THE PLUG if trouble comes. On a laptop, shut down fast (maybe by removing the battery) if you smell trouble. Otherwise, the binary encryption key(made from the passphrase) can be recovered from memory by rebooting from a special disk after freezing the memory with freon if a running machine is captured. It’s not in your ram at all, though, if the machine is off. It takes maybe a minute for the memory to forget it when you shut down-bur over ten minutes if someone freezes it with Freon before rebooting.

In Bitlocker, Microsoft provides the cops with a special program to extract the binary key without even rebooting-and how do we know this can’t be done remotely over the Internet in Bitlocker? Any other system, they have to freeze the RAM and reboot, which cannot be done over the network.

One last thing: this is an ever-changing arms race: don’t commit anything to computer that could send someone to jail unless your intended operation cannot otherwise be done. When you are finished, destroy that data by random character overwrite. If serious jail time is possible, destroy all hard drives, flash drives, etc that ever contained it. You can buy a pair of 4TB disk drives and a cheap flash drive for the cost of just one hour of a top line lawyer’s billable time.