Bug 600295

Summary: Better use aes-xts-plain64 instead of aes-xts-plain for LUKS devices
Product: Red Hat Enterprise Linux 6 Reporter: Milan Broz <mbroz>
Component: anacondaAssignee: David Lehman <dlehman>
Status: CLOSED CURRENTRELEASE QA Contact: Release Test Team <release-test-team-automation>
Severity: medium Docs Contact:
Priority: low    
Version: 6.0CC: agk, atodorov, jstodola, pvrabec
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: anaconda-13.21.51-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-11-10 19:47:05 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:

Description Milan Broz 2010-06-04 11:40:36 UTC 
Description of problem:

Anaconda for some reason decided to not use default (aes-cbc-essiv:sha256) encryption mode pro LUKS devices but have compiled in default of using aes-xts-plain.

There are two problems with that in RHEL6:

- it is incompatible with RHEL5 (there is no XTS mode implementation in kernel yet, it was not backported)

- using plain IV generator for dm-crypt is problematic for large devices - plain is only 32 bits, so for large devices (>2TB) the plain IV restarts and opens device to watermarking attack (two sectors shares the same IV, you can manipulate with the second if you know content of the first).

Since 2.6.32-3.el6 (2.6.33 upstream, see bug 547563) we have plain64 dm-crypt IV generator available, you can safely switch to using this IV generator, which is fully 64bit.

IOW use "aes-xts-plain64" instead of "aes-xts-plain".
(For the device <2TB it gives exactly the same binary output.)

(BTW XTS mode is not generaly suggested for devices >1TB anyway. But it is probably better us XTS, ESSIV generator is not official standard.)

Version-Release number of selected component (if applicable):
All versions using XTS mode for LUKS devices.
Comment 2 RHEL Program Management 2010-06-04 12:03:35 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 3 RHEL Program Management 2010-06-04 12:23:19 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 6 Alexander Todorov 2010-07-06 12:54:43 UTC 
With snapshot #7:

# cryptsetup luksDump /dev/vda2 | grep Cipher
Cipher name:    aes
Cipher mode:    xts-plain64

Moving to VERIFIED.
Comment 7 releng-rhel@redhat.com 2010-11-10 19:47:05 UTC 
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.