1. Introduction
Welcome astute reader.
The IT industry has a continual balance between security and usability. Within this balance, performance usually affects usability. In the realm of protecting "Data at Rest" (i.e. encryption) one may find three factors affecting performance, and therefore usabilty: The harddrive, CPU and RAM. Of these, the harddrive will always prove to be a bottleneck (yes, even with an Solid State Drive, SSD).
Free Software has a rather elegant solution for protecting Data at Rest, called Linux Unified Key Setup (LUKS). In the spirit of "Freedom 0: The freedom to run the program for any purpose." please enjoy my contribution to our collective knowledgebase of a solution to the fascinating problem of "how can we speed up encyption"?
(C) 2014 Justin Mitchell Bennett. Licenced under the GNU FDL.
2. Definitions and Baselines
I used an Acer Aspire V5-171 as the platform for creating a hybrid RAID 1 (RAM drive & SATA HDD). I noted, after about a year of use, that Fedora 19 rarely used over 1 GB of RAM, with the exception of running a Windows 7 virtual machine through Virtual Machine Manager (libvirt/QEMU). As the system allowed for a max of 16GB DDR3, when I upgraded the modules, I factored I could comfortably utilize about 10GB of RAM for a RAM drive to run Fedora in.
I did find limitation however, in how much hard drive space Fedora uses for root /. I tend to partition / (root), /home, and swap on the systems I build. However, with this setup, root (/) tended to run 11-16GB, with squid, ndjbdns, LibreOffice, Android Development Tool, Eclipse, etc. With Fedora, /usr tends to be the largest directory under root. For reasons I won't go into, /usr cannot currently be mounted as a separate partition in Fedora 20; which actually proves useful, as it houses both /bin and /sbin, as well as Xorg. Unless you've already got a somewhat streamlined Fedora installation, creating separate /opt & /var partitions is *highly* recommended.
2A. Partitions
This guide presumes a prerequisite knowledge of partitions, (i.e. creating them and the benefit of multiple partitions). Additionally, some familiarity with EUFI and GPT, as they affect a Fedora 20 installation, (i.e. creating a /boot/efi & /boot partition). If working with BIOS and/or MBR please adjust your partition strategy accordingly. Additionally, as shrinking/growing partitions can be a huge pain, this guide has been written from the perspective of a fresh Fedora installation or re-installation.
2B. Logical Volume Management (LVM)
This guide also presumes a familiarity with Logical Volume Management. As a minimum, you must have an understanding of Physical Volumes (pv), Volume Groups (vg) & Logical Volumes (lv) as they pertain to LVM. Further reading: RHEL Logical Volume Manager Administration
2C. RAID 1
As used in this guide the reference to RAID 1 (mirror) should be understood as RAID 1 being implemented through LVM2. Development of RAID continues at Red Hat, and of interest specific to this guide, we'll utilize lvchange --writemostly. For reference:
Fedora 20 LVM 2 changelog:
2.02.99-1 Peter Rajnoha
25 Jul 2013
- Add lvcreate/lvchange --[raid]{min|max}recoveryrate for raid LVs.
- Add lvchange --[raid]writemostly/writebehind support for RAID1
- Add lvchange --[raid]syncaction for scrubbing of RAID LVs.
2D. Linux Unified Key Setup (LUKS)
In the simpliest terms, LUKS extends cryptsetup functionality with an aim to conform to TKS1. TKS1 uses a hashed key for performing data de/encryption through an encryption algorithm. In this guide, specifically, AES encryption. If it's good enough to secure US Secret classification of material, it should be secure enough to secure your Data At Rest. Further reading at Cryptsetup
2E. Fedora Live USB image
I utilized two USB sticks for this setup. At a minimum, create a Fedora USB media. As I prefer MATE Desktop to Gnome, I additionally created a net-install image. Additionally, once booted from the Fedora USB media, install gparted.
2F. CPU (AES-NI), RAM, and HDD benchmarks:
(Note, for these tests, I booted off the Fedora USB media)
Newer Intel(R) processors include the AES-NI instruction set. To test whether your processor has such instructions type
cat /proc/cpuinfo | grep aesFor brevity, I've skipped posting the output here.
Next, test the CPU throughput of various encryption algorithms. Type
cryptsetup benchmarkMy output yields:
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 386073 iterations per second
PBKDF2-sha256 209380 iterations per second
PBKDF2-sha512 140034 iterations per second
PBKDF2-ripemd160 308404 iterations per second
PBKDF2-whirlpool 164870 iterations per second
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 434.6 MiB/s 1528.2 MiB/s
serpent-cbc 128b 63.3 MiB/s 212.4 MiB/s
twofish-cbc 128b 133.2 MiB/s 250.6 MiB/s
aes-cbc 256b 316.0 MiB/s 1140.8 MiB/s
serpent-cbc 256b 63.7 MiB/s 213.1 MiB/s
twofish-cbc 256b 132.8 MiB/s 250.2 MiB/s
aes-xts 256b 1264.3 MiB/s 1266.8 MiB/s
serpent-xts 256b 218.7 MiB/s 207.4 MiB/s
twofish-xts 256b 241.3 MiB/s 247.5 MiB/s
aes-xts 512b 994.2 MiB/s 986.7 MiB/s
serpent-xts 512b 218.8 MiB/s 208.9 MiB/s
twofish-xts 512b 243.7 MiB/s 247.7 MiB/s
Of note, AES-XTS with a 256bit key shows the highest throughput. By default, Fedora (through Anaconda) will install an AES-XTS 512 bit key LUKS partition using a SHA1 hash. I chose to reduce the AES key size from 512 to 256 for gaining throughput (~1000MiB/s vs ~1260MiB/s), and increased the key hash to SHA512, SHA1 having documented weakness.
On my system, I have 16GB DDR3L 1600MHz PC3 12800 memory. To display the current memory, type
type sudo dmidecode --type 17 | less
From that, look for the following:
Size: 8192 MB Form Factor: SODIMM Type: DDR3 Speed: 1600 MHz Configured Clock Speed: 1600 MHz
(Sidenote - From the factory, ACER shipped 6GB of RAM, however, the 2GB stick had been DDR3 1333MHz, slowing the other stick, a 4GB 1600MHz to 1333Mhz)
Presuming you have enough RAM, create a RAM disk of 1GB for testing throughput with:
sudo modprobe brd rd_nr=1 rd_size-1048576 max_part=0
Now test its read speed through hdparm:
sudo hdparm -t /dev/ram0
/dev/ram0: Timing buffered disk reads: 5050 MB in 3.00 seconds = 1683.23 MB/sec
After such testing, the RAM disk can be removed with
sudo rmmod brd
For comparison, do a test against the hard drive. In this case, an upgraded Travelstar 0J42251, /dev/sda3 has been fully partitioned as a LVM2 Physical Partition (sda1=/boot/efi @ 256MiB, sda2=/boot @ 512 MiB):
(Sidenote - Though a SATA 3 6GB/s drive, For unknown reasons, Acer released a BIOS update that capped the motherboard at SATA 2, though the chipset specifies SATA 3 capability)
sudo hdparm -t /dev/sda3
/dev/sda3: Timing buffered disk reads: 302 MB in 3.00 seconds = 100.51 MB/sec
In creating a RAID 1 mirror, we're trying to push our encryption throughput for Fedora (OS) from 100.51 MB/sec (HDD speed) to 1260 Mib/~1321 MB/s placing the encryption bottleneck at the CPU.
3. LVM or Creating the PV, VG & LGs
3A. Physical Volume (pv)
I'm not entirely sure why Fedora no longer maintains an LVM GUI. Given some of the added complexity of the underlying LVM, I do understand how the GUI falls very short on harnessing some of the advanced features of LVM, namely on the fly RAID 1 creation.
I chose the following partition scheme: sda1 /boot/efi 256 MiB, sda2 /boot 512 MiB, sda3 LVM2 all remaining space (~930.76 MiB)
pvcreate /dev/sda3
3B. Volume Group (vg)
Next I created the Volume Group. Fedora (anaconda) names their vg Fedora_[Hostname]. My hostname being gintonbo (Japanese for silver dragonfly):
vgcreate fedora_gintonbo /dev/sda3
3C. Logical Volumes
The remaining partitions in the system (/, /opt, /var, with a different command for /home):