Preface
When you are using LUKS encrypted volumes you can use key files to unlock them. Those files can be be saved in a flash drive, but I did not liked the idea of having a key file just sitting there waiting to be erased by mistake, or being read by others. There is a way of hiding your key files inside the empty space that exists between your MBR and your partitions of the flash drive. When you create a DOS partition on your flash drive you will see that the first sector always starts at 2048 this means that a number of KBs are held on reserve for the MBR, the partition entries and boot loaders. How much of that free space you have available depends on your layout and it is there where we will be storing the encryption keys. The flash drive will then used to provide passwordless unlocking of the LUKS volumes at boot time. This is useful if you are using an encrypted root partition and swap partition without a random key (something that disables hibernation). Just plug the flash drive and it opens them automatically.

Dissecting The Flash DriveIMPORTANT: PLEASE Do not just copy and paste, we will use dd and it can destroy your partition table if not applied correctly. Also the data on your flash drive WILL BE ERASED irrecoverably. Also DO NOT use it if you do not know what you are doing you WILL NOT be able to boot after following the guide with errors.

With the above said lets start. First of all we are going to wipe the flash drive with zeros so we can have an understanding of the free space. You can either wipe it entirely or just some of the first MBs that are of interest. Lets see the device that our flash drive is set by the kernel:

Code:

Spileo-Desktop luks-test #fdisk -l

Disk /dev/sdd: 977.6 MiB, 1025024000 bytes, 2002000 sectors

As you can see my flash drive is listed as /dev/sdd.
Next fill it up with zeroes (note that I am erasing just the first 4 MBs you can remove the count to erase it entirely and ajust the bs but it may take a long time to complete.):

As you can see everything is zero. The partition table has been erased and the partitions does not exist anymore. So we will create the partition table without a partition to see how much space it is going to occupy in the MBR. There are lots of tools that can do that from cfdisk to gparted, I use cfdisk:

Meaning that the partition we created start at 00100000 (1048576 bytes) so the space before that until 00000200 is still zeros. This is the dead space that we will use for storing the keys as long as the partition table remains unaltered the keys shall be intact.
Before we continue to make the keys and insert them I want to cover another possibility.Some people may want to use the flash drive as a boot device and install grub on it this will change the free space available:

So the free space with grub installed is from 0000c200 to 00100000, about 1 MB.

Creating the Keys
To create the key files we can use the /dev/random or /dev/urandom. The first is too slow but it provides output when the entropy pool is sufficient thus better keys. The next segment will create a file with random data from which we will extract our keys and randomize the zeros that exist in the free space. Note that if you use /dev/random it will take a loooonnngggg time.

Now that our keys have been generated and are not a subset of our random data we can embed the random data in the free space to make it harder to detect the keys. The space in question is 00100000 - 0000c200 = 1048576 - 49664 = 998.912 bytes. In dd using the seek=x lets us skip the number of bytes we want from the beginning of the target device, I left 4 bytes on zero on purpose (2 at the start and two at the end of the free space) just to be sure the would not be any overwriting:

Embedding the keys is done by the same procedure,I left intentionally some random data between the keys so that they would not be side by side. The root.key will be placed 1024 bytes after the start of the free space and the swap.key 128 bytes after the root.key (root key=49668+1024=50692 , swap key=50692+512+128=51332):

Using the Key Drive
Before Gentoo I used Arch Linux, their initramfs had the ability to extract a key like those above from a block device. I wanted to have that in Gentoo so I modified genkernel's initscripts to do it. I have been using it and testing it for a a month now with no problems.

OR manual edit:
edit /usr/share/genkernel/defaults/initrd.scripts
removing the functions openLUKS() and startLUKS() (only those two!) replacing them with the following: http://pastebin.com/TtWEUTeP

Now that this is done we need to edit the grub command line so it includes our crypt devices and key devices. The arguments work like that:
crypt_dev=LUKS_Device:LUKS_Map:cryptsetup_arguments
LUKS_Device can be, a kernel device (/dev/sda2 or lvm etc.), a UUID, or a LABEL
LUKS_Map is the desired mapping for the device when it is unlocked
cryptsetup_arguments are used when unlocking the device so far I have only used --allow-discards for TRIM support
Caution: DO NOT use UUID for an LVM device that you will create snapshots, the snapshot will have the same UUID and you will end up loading the snapshot instead of the real device

crypt_key=LUKS_Map:Key_Device:Key_Type:Key_Location
LUKS_Map is the mapping of the LUKS device that the key will unlock
Key_Device is the device containing the key (kernel device, UUID or LABEL)
Key_Type is the type of the key, PASS to not use a key but password, BLK to extract from a block device, FILE for file
Key_Location can be empty when using PASS, startByte-KeySize (50692-512) when using BLK, absolute path when using FILE (/luks/root.key)

You can have as many device-key pairs you want as long you set them correctly they will get opened. If the device is not present the boot process will wait for 10s for it to get connected, otherwise it will ask for password.

Last thing to do is generate the initramfs and update grub (note that I am using LVM and excluding zfs for my system):

All done now you can use your digital key! But you must be carefull when you update the genkernel package the edited sections may be changed if you chose to do it manually, so you will have to edit them once again.