Talk:DM-Crypt with LUKS

"Another problem came up because of the update to "userui" package - the user interface would not show up while hibernating. This is fixed by editing "/etc/hibernate/suspend2.conf" and changing: "ProcSetting user_interface/program /usr/sbin/suspend2ui_text" line to "ProcSetting user_interface/program /usr/sbin/tuxoniceui_text" (if you're using the fbsplash version the filenames will be different - "suspend2ui_fbsplash" becomes "tuxoniceui_fbsplash")."
 * outdated info on suspend2 (see https://bbs.archlinux.org/viewtopic.php?pid=275352 )


 * also links to waku.info are broken


 * DM-Crypt_with_LUKS whats the difference between having and not having it in the kernel?

Everything work fine as all the squashed dirs --usr:lib32:lib64:bin:sbin-- are mounted as expected, but logging in is broken when lib64 is mounted. The reason is also exposed int hat thread: openrc-0.8+baselayout2 introduce a tmpfs mount point in lib64--/lib64/rc/init.d--, splashutils introduce another--/lib64/splash/cache,-- and rc use that location for storing detailed info of services. So when lib64 is squashed something goes wrong. I don't really know where those mount point are defined but there's something like--: ${RC_SVCDIR:=/lib64/rc/init.d} in /lib/rc/sh/init-common-post.sh and similar asignment for /lib/splash/cache somewhere-- but changing them doesn't work. I'll post soon the updated script after running a few test for swap/resume file. lib64 is missing... however the system is really fast without it. Any info on the location of the definition f those two parameters are welcomed.
 * squashfs+aufs2: script updated to add a possibility to squash directories for system speed up or cutting away the disk bottleneck, see this thread in the forum, https://forums.gentoo.org/viewtopic-t-646289.html for more info. After many weird errors, I have something that can mount squashed dirs depending on an argument [well, you can squash several dirs the way you like, using or not default values for the squashed dirs and the location of the squashed dirs] on the cmdline.


 * swap file+TuxOnIce[+LVM2 on LUKS crypted PV] added on May 20, 2011.

{Question} What is the preferred initial script? The text one detailed in the wiki or the linked linuxrc at tuxonice?

piping gpg output to cryptsetup weakness?
While writing a | similar guide for arch linux I came across the following notice in the cryptsetup 1.1.2 release notes: Cryptsetup can accept passphrase on stdin (standard input). Handling of new line (\n) character is defined by input specification: if keyfile is specified as "-" (using --key-file=- or by positional argument in luksFormat and luksAddKey, like cat file | cryptsetup --key-file=- ), input is processed as normal binary file and no new line is interpreted. if there is no key file specification (with default input from stdin pipe like echo passphrase | cryptsetup ) input is processed as input from terminal, reading will stop after new line is detected.

If I understand this correctly, since the randomly generated key can contain a newline early on, piping the key into cryptsetup without specifying --key-file=- could result in a big part of the key to be ignored by cryptsetup. Example: if the random key was "foo\nandsomemorebaratheendofthekey", piping it directly into cryptsetup without --key-file=- would result in cryptsetup using only "foo" as key which would have big security implications. We should therefor ALWAYS pipe the key into cryptsetup using --key-file=- which ignores newlines.

Am I right? Should this be changed? If yes, then both the luksFormat passage and the original init script will have to use --key-file=-

-- See: https://bugs.gentoo.org/show_bug.cgi?id=409321 Not using --keyfile (or -d) will lead to nonworkign initramfs with dracut. I add a note about this on the page, but maybe its a good idea to rewrite the whole page to use this. ''26.Mar 2012

disk partitioning with LVM by default; ciphers
LVM is a de facto configuration these days.

aes appears to be mostly recommended (but my cryptography knowledge is very limited) maybe to make the document more straightforward use it as default with pointers to ciphers section?

(from http://en.gentoo-wiki.com/wiki/Booting_encrypted_system_from_USB_stick)

Better alternative to filling the disk with random data
The purpose of filling the disk with random data is to prevent an adversary from determining whether a part of the disk contains data. Unfortunately this step is very slow when using /dev/urandom (various sites online claims that this is because /dev/urandom was designed to provide a small amount of very good randomness).

However, another much faster approach, which should provide the same guarantees, is presented in |Full-disk Encryption: How to randomize a disk and the Secure Deletion article.

Essentially, fill the decrypted mapping of the encrypted disk with randomness after you setup the LUKS encryption on the disk:

Then, you can continue with formatting /dev/mapper/root, etc.

Assuming that the chosen cipher for LUKS is secure, adversaries should not be able to distinguish whether any part of the resulting disk is filled with encrypted data or encrypted zeros (if you can check whether the ciphertext decodes to a particular message (in this case, all zeros), then you've broken the encryption).

209.6.74.137 23:03, 16 January 2011 (GMT) (jchau)

Using /dev/random Over the Network
Current page suggests using netcat as a server for other machines on your network to help feed random numbers. However, the numbers will be sent in plaintext over the wire. If you're paranoid enough to use an encrypted drive and don't want to use /dev/urandom, then you should also be paranoid enough to not send those numbers in plaintext.

I happen to have one machine with a hardware random number generator, so I created an SSH tunnel to that machine:

[user@local]$ ssh -L 34096:remote_host:34096 remote_host

Then setup netcat as a server on that host, dumping data from /dev/random:

[user@remote]$ dd if=/dev/random | nc -l -p 34096

Finally, read the random numbers on local by connecting to localhost:34096:

[user@local]$ nc localhost 34096 | dd of=/dev/sda1

Frezik 15:20, 21 February 2011 (GMT)