On Mon, Aug 3, 2009 at 18:46, Moji<lordmoji@xxxxxxxxx> wrote: > 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 I really liked this one, using aes-cbs-essiv:sha256 [keysize=256] i was able to get only 0.89MB/s reading via NFS from my ARM 266Mhz. Using serpent-cbc-essiv:sha256[keysize=256] i can get 2,66MB/s, which is really good. > > 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 > -- []'s Salatiel "O maior prazer do inteligente é bancar o idiota diante de um idiota que banca o inteligente". _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
