Bug 461697

Summary:	Add support for XTS (and possibly other algorithms) encryption
Product:	Red Hat Enterprise Linux 5	Reporter:	David Lehman <dlehman>
Component:	anaconda	Assignee:	David Lehman <dlehman>
Status:	CLOSED CANTFIX	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	5.3	CC:	borgan
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-09-25 18:48:56 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	455063
Bug Blocks:

Description David Lehman 2008-09-09 23:05:27 UTC

+++ This bug was initially created as a clone of Bug #455063 +++

Fedora 9 introduced ability to encrypt partitions in installer - AFAIR it's
lrw-benbi encryption. It also asks for password if currently encrypted partition
is detected, as to continue installation with it available. 

Now, I have an LVM setup with my PV encrypted using xts-benbi. Partition gets
detected, I'm asked for my passphrase and then an error occurs. I guess that
installer environment simply lacks needed module(s).

Support for algorithms other than lrw-benbi should be added, then users could
install Fedora on their already-set partitions.

I have no idea if initramfs supports anything other than lrw-benbi, but it
should also be found out and (if there's no support) resolved.

--- Additional comment from dlehman on 2008-08-26 13:53:40 EDT ---

We should probably handle preexisting devices with these other ciphers, and I think the mkinitrd support should not be a problem, but for device creation we will, for the time being, keep it simple and stick with aes-cbc-essiv:sha256.

--- Additional comment from piotr.krawi on 2008-08-26 14:44:56 EDT ---

I've successfully deployed Fedora 9 on mentioned LVM-PV-xts-benbi partition setup using Fedora 9 Live CD, so it seems Anaconda and mkinitrd already support custom schemes. That make me pretty sure it's only about including various crypt modules in standard installer environment.

--- Additional comment from dlehman on 2008-08-26 14:52:35 EDT ---

That's right -- the cipher mode is stored in the LUKS header, so cryptsetup can determine it without any trouble. All we need to do is include the modules in the installer's runtime environment and make sure they get loaded.

--- Additional comment from dlehman on 2008-08-26 18:25:41 EDT ---

The lrw and xts modules should be in trees composed with anaconda-11.4.1.30-1 and later.

Please reopen if this is not resolved in the aforementioned tree.

Comment 1 David Lehman 2008-09-09 23:17:20 UTC

Since we've shipped cryptsetup-luks since RHEL5 GA we should be able to make use of LUKS block devices using any of the supported cipher modes.

To the best of my knowledge, the supported modes are CBC (default, already included), XTS, and LRW.

Comment 2 RHEL Program Management 2008-09-16 00:11:40 UTC

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 4 David Lehman 2008-09-23 21:10:41 UTC

Note: neither XTS nor LRW modules are present in our RHEL5 kernel.

This bug may still make sense if there are other cipher modes we should be including for RHEL5. Stay tuned...

Comment 5 David Lehman 2008-09-25 18:48:56 UTC

Since neither module is in the RHEL5 kernel we should close this.

If we get requests for other modes during beta we can handle them as they come.