Disk encryption key: can the kernel be recompiled for a 2,048 bit key?

[alphacrasher]

Three questions:

1. Fedora 14 has a user friendly disk encryption setup. However, there doesn't seem to be an option to change the encryption parameters during setup.
Since I can handle the overhead, I would like to change the encryption algorithm and the key length for the default install. Is there any way to do this?

2. I have created an additional encrypted drive (the entire HD) which claims to have its own encryption functionality (Seagate Constellation 1TB). Does Fedora use the built-in encryption mechanism by default? Is there any way to tell?

3. I can't seem to find any utility to tell me what the actual key size is for different HD's I have encrypted. "cryptsetup --help" seems to print out only the information for the default encrypted O/S which is the default 256 bit.

My problem is whether the -s option work when set to a 2,048 bit key length? Or, does it fall back to a 256 bit key length if it fails to do so? Or, does it automatically use the built-in encryption of the hardware?

If the -s option doesn't work with a 2,048 bit key setting, can the kernel be recompiled to do so? If so, is there a how-to?

[kurtdriver]

What you setup with Fedora is, I'm guessing the LUKS filesystem. This encrypts the filesystem and can not be messed with. You could overwrite it, that's it, but I guess you don't want to do that.

Try to access the encrypted drive and you'll get your answer. Perhaps it Fedora will ask you for the password. It does so when I try to mount encrypted USB keys, but those were encrypted with LUKS.

I don't know the answer to your third question, sorry.

[Ziplock]

My understanding is that cryptsetup will default to a keysize of 256 bits. I have tried to increase this size via the --key-size option in the past to 1024 without success.

You can use the following commands to check what cryptsetup has done:

cryptsetup isLuks <device>

will give you a yes/no answer as to whether LUKS was used.

cryptsetup luksDump <device>

will output the LUKS information on a partition/device if it exists.

Not sure about the HDD onboard encryption, sorry.

[alphacrasher]

I went through the Fedora 14 setup menus but can't seem to find any options for altering the encryption settings. Might this be achieved via a command line install? I don't suppose there would be a How-To?

Kurtdriver: yes Fedora 14 asks me for the system drive encryption password on bootup. The configuration is an unencrypted boot partition and an encrypted LV containing root, swap and home partitions. All the preceeding are on /dev/sda. When I try to access the encrytped /dev/sdb it asks for the encryption password for that drive.

Is there any advantage to configuring a drive as a LV before encrypting it? (In this particular case I am using sdb as one large partition)

Ziplock: yes, both are LUKS. The output of the luksDump command for /dev/sdb is below. It appears to have used the default key length.

Output of luksDump command:

[root ~]# cryptsetup luksDump /dev/sdb
LUKS header information for /dev/sdb

Version:       	1
Cipher name:   	aes
Cipher mode:   	cbc-essiv:sha256
Hash spec:     	sha1
<deleted>
MK bits:       	256
<deleted>
Key Slot 0: ENABLED
<deleted>
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
[root@ ~]#

[Ziplock]

alphacrasher:

I am not sure about the 'command line install' of Fedora, but you can set up encryption of drives post OS installation for your data partitions fairly easily. The OS partitions are harder as you will need to move files around.

The process on the command line is as follows:

cryptsetup luksFormat --key-size=<size in bits> <device/partition>
cryptsetup luksOpen <device/partition> <tag>
mkfs.ext4 -L <label> /dev/mapper/<tag>
mount /dev/mapper/<tag> <directory to access files through>

As an example:

cryptsetup luksFormat --key-size=2048 /dev/sda1
cryptsetup luksOpen /dev/sda1 private-data
mkfs.ext4 -L /private-data /dev/mapper/private-data
mount /dev/mapper/private-data /private-data

Note: Alter the partitions to your needs - sda1 will probably overwrite your Operating System Partition.

You will also need to update /etc/crypttab and /etc/fstab to add /dev/mapper/private-data. Man pages will help here.

[alphacrasher]

Ziplock, thank you.

Am I correct in my understanding that the "cryptsetup luksFormat --key-size=2048 /dev/sda1" would trash any existing data on /dev/sda1? (as opposed to reincrypting the existing data on it with the new key)

The manual pages for cryptsetup direct me to see /proc/crypto for available modules, the contents of /proc/crypto for my standard install of Fedora 14 x86_64 are shown below.

I am a little confused about the --key-size option. The source of my confusion is the output of the /proc/crypto file below which shows, for the aes modules, that "max keysize : 32".

I am probably reading it wrong, but is that the actual max keysize in bits? If not, what about bytes (16*8=128bits and 32*8=256bits)?

Do I need to recompile or get a different kernel to use a 2,048 bit key size? If so, might anyone know which one and where do I find it?

[root ~]# more /proc/crypto
name         : sha256
driver       : sha256-generic
module       : sha256_generic
priority     : 0
refcnt       : 3
selftest     : passed
type         : shash
blocksize    : 64
digestsize   : 32

name         : sha224
driver       : sha224-generic
module       : sha256_generic
priority     : 0
refcnt       : 1
selftest     : passed
type         : shash
blocksize    : 64
digestsize   : 28

name         : cbc(aes)
driver       : cbc(aes-asm)
module       : kernel
priority     : 200
refcnt       : 2
selftest     : passed
type         : givcipher
async        : no
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : eseqiv

name         : cbc(aes)
driver       : cbc(aes-asm)
module       : cbc
priority     : 200
refcnt       : 2
selftest     : passed
type         : blkcipher
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : <default>

name         : xts(aes)
driver       : xts(aes-asm)
module       : kernel
priority     : 200
refcnt       : 2
selftest     : passed
type         : givcipher
async        : no
blocksize    : 16
min keysize  : 32
max keysize  : 64
ivsize       : 16
geniv        : eseqiv

name         : xts(aes)
driver       : xts(aes-asm)
module       : xts
priority     : 200
refcnt       : 2
selftest     : passed
type         : blkcipher
blocksize    : 16
min keysize  : 32
max keysize  : 64
ivsize       : 16
geniv        : <default>

name         : aes
driver       : aes-asm
module       : aes_x86_64
priority     : 200
refcnt       : 5
selftest     : passed
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : aes
driver       : aes-generic
module       : aes_generic
priority     : 100
refcnt       : 1
selftest     : passed
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : stdrng
driver       : krng
module       : kernel
priority     : 200
refcnt       : 2
selftest     : passed
type         : rng
seedsize     : 0

name         : crc32c
driver       : crc32c-generic
module       : kernel
priority     : 100
refcnt       : 1
selftest     : passed
type         : shash
blocksize    : 1
digestsize   : 4

name         : sha1
driver       : sha1-generic
module       : kernel
priority     : 0
refcnt       : 1
selftest     : passed
type         : shash
blocksize    : 64
digestsize   : 20

name         : md5
driver       : md5-generic
module       : kernel
priority     : 0
refcnt       : 1
selftest     : passed
type         : shash
blocksize    : 64
digestsize   : 16

[kurtdriver]

If that doesn't trash your data, mkfs will. Maybe you should back everything up and prepare to start over. Ziplock's post is confirming what I wrote above, that first you encrypt a partition and then make a filesystem. Sorry to bring bad news.

[Ziplock]

I second kurtdriver's backup advice.

Just for clarity - I'm 99% certain the luksFormat command would render your previous data unusable as it would have been encrypted with an old key that no longer exists.

Not sure about the key-size or kernel compilation options - sorry.

[alphacrasher]

Kurtdriver and Ziplock, thank you very much.

It is strange that such a low upper limit would have been hard coded as opposed to leaving it variable, at least to a much higher value.

I am back to where I started it seems in terms of trying to obtain or compile a kernel and crypto modules that can handle key sizes larger than 32 bits (maybe 256 bits if the /proc/crypto key size parameter is in bytes).

Can anyone give advice on this or direct me to some place that has more specific information?