Hi,

I've scoured the net, but I can't seem to find a definitive answer. I'm no cryptographer, so some of the texts that could potentially answer my question are currently beyond me.

Am I correct in assuming that XTS does not require ESSIV? The internet is littered with posts saying things like, "I use aes-xts-essiv and it's no slower than aes-xts-plain." To my mind, this means it probably isn't using it.

Some insight would be appreciated. I'm sure I'm not the only non-cryptographer left scratching his head.

Thanks for your time and consideration,
Phoenix

From http://wiki.archlinux.org/index.php/...ncrypted_Root:
In cryptography, you typically want to avoid "new" things.

Things that have been around for a longer time, hopefully, have had more eyes on it to discover any vulnerabilities that may exist.

XTS is new and "experimental" which means there might be problems that could unknowingly leak hints at the plaintext.

CBC-ESSIV is more established and, unless you can find articles detailing an exploit, probably more secure.

Thanks for your reply, Admiral Beotch.

You are of course correct about 'tried and trusted' vs 'shiny and new'. I'll probably take your advice and use cbc-essiv.

However, my question still stands. Does xts require essiv or no? Any crypto-geeks out there think they can explain it without resorting to calculus? It would be good to have at least one place on the internet where endusers can find a definitive answer.

Thanks,
Phoenix.

I realize this thread has been dead for a while, but it's one of the first results from Googling "luks xts", so I thought I should take a stab at answering the question.

Short answer: XTS does not require essiv.

Long answer: An encryption algorithm is not secure if it outputs the same result each time the same message is encrypted. Otherwise, an attacker knows when a message is repeated, and, depending on the context, this could be a security risk. Therefore SOMETHING has to change on a per-message basis, and that something is typically an initialization vector (IV).

But different encryption algorithms use IVs in different ways. In CBC, altering an IV alters the first "block" of a decrypted message in a very predictable way: changing the first bit of the IV changes the first bit of the decrypted message. Therefore if the IV changes in a predictable way, certain attacks are possible. In particular, if there's a reasonable chance the last few bits of an consecutive IVs go from 001 to 0010 to 0011 as different segments of a file are encrypted, I can begin consecutive segments (extents) of a file with 001, 0010, 0011, and each of these extents, when encrypted, will start with the same ciphertext block, which will be repeated at regular intervals. I can use this "watermark" a file, and then check your encrypted harddrive for this watermark.

For this reason, CBC should have a RANDOM IV with each new message. EESIV doesn't meet this ideal, and theoretically this could lead to weaknesses; however, it's far better than having completely predictable IVs. (In fact, one can prove that as long as the underlying blockcihper, typically AES, is secure and each IV is random, there is no way for an attacker to distinguish CBC ciphertexts from random bits, even if the attacker can launch chosen-plaintext attacks. But I digress.)

XTS, on the otherhand, uses IVs in a completely different way. It uses a new-fangled crypto gadget (more on this in a bit) called a Tweakable Blockcipher. The idea here is that a TBC takes an extra input, the tweak, and it looks like a completely new random permutation each time the tweak changes. Crucially, this is true even if an attacker CONTROLS when and how the tweak changes. Therefore it looks like a completely new random permutation with each tweak change to an even weaker attacker: one who merely KNOWS what tweak is being used.

In XTS, the IV is used as a tweak, and gets incremented with every block encrypted. The fact that the attacker might KNOW what tweak is being used doesn't help him distinguish XTS outputs from random gibberish.

So why should you trust a shiny new-fangled crypto gadget? Well, because there's a mathematical proof showing that any algorithm that can "break" the XTS's tweakable blockcipher (called XEX) can be used to make an algorithm that can "break" AES (or whatever blockcipher is being used). So you can trust XEX as much as you can trust AES, and you can trust XTS as much as you can trust XEX. Of course, there are always gaps between math land and the real world. The point here is that you have a much better foundation for your trust than "well, no one seems to have broken it yet."

3 members found this post helpful.

I just registered to say, thank you sir! That was exactly the kind of answer I was googling for.

Although this question/post is old, it still holds relevance.
Thank you Sappho, for posting a response!

By default, luks in Ubuntu uses xtx-plain-64 now a days. cbc appears to have been abandoned. There are other OSs that are abandoning it as well. Debian, and few BSDs come to mind.

Yes, the CBC part stands for Chain-Based-Cipher. CBC stuff looked good at first but people discovered vulnerabilities via "filler blocks" at the end of a message. BTW: this was how ssl2 got broken by some folks at google, iirc (don't take my word as gospel).

There's an outstanding course offered online from Stanford at https://class.coursera.org/crypto-preview/lecture . I'm half-way through it. Its college senior level. I learned a lot. And there's a follow-on Part 2 as well. They even give you a certificate of accomplishment if you get through it all.

I guess I'm off-topic. But I hope this is useful to someone anyway.

CBC with ESSIV is secure when not used over a network. The main issue with CBC right now is:
https://en.wikipedia.org/wiki/Padding_oracle_attack

CTR mode is secure, so this is a good alternative.

I personally don't trust XTS, it is new, it is complicated, and it has potential vulnerabilities. P.S. Ubuntu and security and definitely not synonymous, so I could care less what Ubuntu uses by default or M$ for that matter.

I am currently using CBC with ESSIV, but CTR mode may be my next choice when I re-encrypt.

Well, ubuntu is not the only OS dropping cbc, there are others as I stated, including Apple's filevault and most UNIX and UNIX like operating systems (BSD). Go ahead and continue using cbc, you will probably have no issues. The fact is, certain vulnerabilities have been discovered in cbc.

The fact is that when used locally, CBC with ESSIV is secure. If you say otherwise, provide an example of a vulnerability that affects CBC with ESSIV (don't forget the ESSIV part because this prevents watermarking attack).

I agree that CBC mode should be phased out, as such I am now using CTR mode and recommend it. You don't actually need ESSIV for modes other than CBC, but it doesn't slow anything down so you can safely use it.

xts-plain64 is more secure than cbc-essiv. You should go with xts-plain64. Also the experimental feature tag in kernel has been removed. Also essiv is not needed with xts.

I second this. Go with aes-xts-plain64, that's what I use on most hardware.