Re: 1,5 TB partition: use cbc-essiv or xts-plain?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Here is the report that NIST released comparing, MARS, RC6, Twofish, Serpent, and Rijndael(AES), skip to page 88 for the summary: http://csrc.nist.gov/archive/aes/round2/r2report.pdf

Benbi is a big-endian, narrow block algorithm using 64-bit, plain uses 32-bit. Here is a paper by NIST citing that XTS is not suitable for information in chunks larger than 1TB per key: http://csrc.nist.gov/groups/ST/.../XTS/revised_XTS_comments-Seagate.pdf

I am sorry but I do not have any additional information that was not already cited about ESSIV to add here.

As for devices larger than 1TB, when ever this is brought up and discussed the only solution I have ever seen is using multiple keys to break up larger devices into smaller chunks to avoid weaknesses. Then use RAID/LVM to bring them back together or change your disk management practices to split up your data.
This includes newer ciphers because the more data you encrypt with a single key, and right now dm-crypt only allows for single keys, the more susceptible your algorithm is regardless which one you use.

I hope this helps you,

-MJ

On Mon,  3 Aug 2009 14:53:42 +0200 (CEST)
theiling@xxxxxxxxxx (Henrik Theiling) wrote:

> Hi!
> 
> While trying to make a decision of how to encrypt a large disk, I
> found no good answer yet.  What I am searching for is a site that
> gives me a simple overview of pros and cons of the different choices
> to be made when selecting LUKS algorithms.  Yet, I found nothing like
> that.
> 
> In this particular case: for a 1,5 TB partition, should I use
> cbc-essiv or xts-plain?
> 
> It seems cbc-essiv is susceptible to watermarking (according to
> Wikipedia, which claims that no IV obfuscation algorithm protects
> against this except in the initial block.  Unfortunately, I cannot
> verify this, so it sounds bad to me.
> 
> And then, xts-plain is said to become weaker on large disks, and some
> crypto implementations warn about this weakness for disks as small as
> 500GB.  So what's the alternative?  (If I understand correctly, LUKS
> has no multi-key XTS option for large disks, right (in case that would
> overcome the problem)?)
> 
> I don't seem to be able to make a decision on my own, so I'd like to
> ask for help.  Which problem is worse?  Or are there ways to overcome
> both problems?  I could probably split the disk and re-assemble the
> xts-plain encrypted parts in a RAID, but that seems very complex.
> There don't need to be simple answers -- I am willing to evaluate my
> problem thoroughly, but so far I found no good comparison.
> 
> Bye,
>   Henrik
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@xxxxxxxx
> http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt

[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux