I am so sorry, I hit send before I had finished writing, I was delayed trying to find an article that I thought would help you with more explanation but I could not remember where I read it. Finally I did locate it, it should provide some information on ESSIV for you: http://clemens.endorphin.org/LinuxHDEncSettings Also, based on the information I have posted, and assuming that you will not be using raid to break up the device, I would recommend: serpent-cbc-essiv:sha256 serpent because it is very strong cipher, even though it has not as much testing as AES, and cbc-essiv, because I have not seen any reports of inherent vulnerabilities on larger devices. -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
