Want to use encrypted root without luks but need UUID?

[tholin]

I've started thinking about finally encrypting my system. I have 7 data disks and one root ssd.

I've decided that luks is not for me. It's stores the keys in a small header before the data and if there is a bad block in that header all data is lost. That is not acceptable. The header can be backed up but I still think it's a bad idea. Too much things that can go wrong. I value data security much more than cryptographic security. But not using luks leads to another problem. Raw dmcrypt partitions don't have any uuid so I have no good way of uniquely identifying the disks. Going by /dev/sd** device is not possible because they change around too often. So how should I identify the partitions in the init script?

I have two ideas and they both sux. I could create a filesystem header with an uuid at the beginning of the partition and encrypt the data after the header. A swap partition header is 4096B so I could call cryptsetup with --offset 8 too make it ignore the swap header. This is a bad idea because the kernel, livecds and everything else will assume they are real swap partitions and might try to use them as such.
The second idea is to use some complicated grep in hdparm for serial number and match that with a list of serial numbers and partitions.
Anyone have any better idea?

I don't want to enter 8 passwords at boot so I need some way go get around that. I could use the same password on all disks and use pam_mount to mount then automatically on boot with the login password. By doing so I would have to enter two passwords at boot. It's acceptable but I've used pam_mount before and I often had problems with it. Another way would be to mount everything in the initramfs and then use autologin. That way I would only have to enter a single password. I could read in the password with read and then do something like echo $password | cryptsetup -d - create root $dev or maybe echo $password | hashalot ripemd160 | cryptsetup -d - create root $dev. I haven't tested that yet.
Other ideas?

[Hu]

Use LUKS and archive the relevant header blocks. Usually, if you get to the point of disk blocks being so corrupt as to be unreadable, you are in big trouble and need to go to your backups anyway. You could just as easily have the dentries for / get corrupted and then you would not be able to find any files on the filesystem.

[tholin]

[mp342]

[tholin]

I found the /dev/disk/by-id folder and it contains WWN ids for the disks (MAC for hard drives). I can use them instead of UUID. Just hope busybox's udev replacement create those files.