Re: [RFC] LUKS

Am Samstag, 13. Mai 2006 21:24 schrieb Stefan Fiedler:
> Am Freitag, 12. Mai 2006 11:42 schrieb Benjamin Schieder:
> > Hi list.
> >
> > I just had a talk with th on IRC and he pointed me to
> >
> > 	http://luks.endorphin.org/
> >
> > which seems to be the "de facto" standard for software harddisk
> > encryption on Linux systems these days.
> > LUKS works like this:
> >
> > Consider this your partition you want to encrypt:
> > 	|-----------------------------------------------|
> >
> > Now LUKS puts itself into the first 1032 blocks of the partition:
> > 	|LUKS|------------------------------------------|
> >
> > 1032 equals to 0.5 Megabyte.
>
> Hi,
>
> following the LUKS specification from
> http://luks.endorphin.org/LUKS-on-disk-format.pdf , the LUKS partition
> header is exactly 592 bytes in size (see Figure 1: PHDR layout), including
> all eight key slots, each 44 bytes in size. The header starts at sector 0
> of the partition. Since sector 0 of each partition is already reserved as a
> "boot sector" (I think this goes back to IBM/PC compatibles), this does not
> seem to pose special problems with respect to post-install en-/decryption.
>
> A sector is the smallest independently accessible block of data on block
> devices (512 bytes on most PC HD drives?). If key slots 7 and 8 are not
> used, the LUKS partition header and the data area should not overlap.
>
> Hope that helps,
> 	Stefan Fiedler
>

Sorry, I missed an important part of the spec:

	The overall disk layout depends on the length of the key material section 
	following the phdr. While the phdr is always constant in size, the key 
	material section size depends on the length of the master key and the number 
	of stripes used by the anti-forensic information splitter.

So converting non-empty partitions to and from the encrypted state is indeed 
tricky. 

> > In there it stores up to eight actual encryption keys which can be
> > unlocked using a passphrase.
> > This means that it isn't possible to go to and back from an encrypted
> > filesystem which IMO is a big drawback and one I personally do not want
> > to take.
> >
> > I propose the following:
> >
> > All filesystems we create should be passed through dmsetup which
> > configures them to not use those first 1032 blocks. This enables the user
> > to use dd to encrypt or decrypt a filesystem should the need arise to do
> > so.
> >
> >
> > My question:
> > - Do we stay with the way we are now, using our own system to setup
> > 	encryption?
> > - Do we use my proposal to be able to encrypt/decrypt our filesystems
> > 	post-install?
> > - Or should we just use cryptsetup-luks and lose that ability, forcing
> > 	us to reinstall when we decide that we want an encrypted fs?

I like your proposal, the varying size of LUKS data per partition has to be 
considered, though. So there would be non-encryptable filesystems, 
encryptables (handled by dmsetup) and encrypted (handled by luks). Since we'd 
have to support all three types anyway, users should be able to choose if a 
new filesystem is encryptable, and en-/decrypt filesystems in a separate 
step.

Greetings,
	Stefan Fiedler

> >
> >
> > Greetings,
> > 	Benjamin
> > --
> > Benjamin 'blindCoder' Schieder
> > Registered Linux User #289529: http://counter.li.org
> > finger blindcoder-1k+CIuW/[email protected] | gpg --import
>
> _______________________________________________
> rock-devel mailing list
> [email protected]
> http://www.rocklinux.net/mailman/listinfo/rock-devel