Red Hat Bugzilla – Bug 600295
Better use aes-xts-plain64 instead of aes-xts-plain for LUKS devices
Last modified: 2013-02-28 23:09:05 EST
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.
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
With snapshot #7:
# cryptsetup luksDump /dev/vda2 | grep Cipher
Cipher name: aes
Cipher mode: xts-plain64
Moving to VERIFIED.
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.