# EAX vs CTR vs XTS + cascade ciphers in disk encryption hell

Often when I stumble across something interesting, I lose myself in the most overkill ways of implementing it. Today it was full disk encryption: I'm about to move to QubesOS, and I want to secure my data as much as possible, to a point where unauthorized viewing or even touching of the data becomes overly hard/nearly impossible. I don't care if it takes me minutes to decrypt my system on boot as long as it benefits my security.
As outlined in this answer I read (yes, I base my research mostly on StackExchange and wikipedia), there are three fundamental components of disk encryption I will have to decide on. These are the choices I've narrowed it down to:
Block cipher primitive: Serpent-256 (considered unbreached by Wikipedia), Twofish-256 (considered unbreached by Wikipedia, but is potentially more vulnerable to side-channel attacks) and AES-256 (considered theoretically breached by Wikipedia, but more mature). Seeing advantages in all three of these ciphers, I'm considering using them in a Cascading fashion like VeraCrypt offers. This would allow my system to stay secure even if one of these ciphers has been broken, right?
Mode of Operation: XTS seems pretty compelling (fixing issues from CBC->LRW and XEX), but is vulnerable to tampering (I'm using btrfs, so I'll at least be able to detect data manipulation) and traffic analysis. CTR also looks interesting, but yet again it is missing community support. To prevent tampering, I would have to use a diffuser. However, yet again, apart from Microsofts proprietary BitLocker diffuser (Elephant) there aren't any resources on this. Then there's EAX, assuring confidentiality and authenticity of the data. If so, EAX is arguably better than XTS, isn't it? Why is it so unpopular? Are there maturity issues?
Initialization vector: Anti-watermarking ESSIV for CBC-based modes, plain64 for XTS
As to be seen above, I'm especially insecure concerning the most secure Mode of Operation. Additionally, I'm not sure if there even is a disk encryption tool that provides f.e. cascade-serpent-twofish-aes-eax-plain64 (VeraCrypt supports the cascading part, but only allows for XTS). Also, most people use sha512 for hashing with a high iteration count. Is it possible to use a more sophisticated hashing algorithm like bcrypt instead?

This would allow my system to stay secure even if one of these ciphers has been broken, right?

Most likely, however one can construct situations where the cascade is only as strong as the first cipher.

If so, EAX is arguably better than XTS, isn't it?

It is.

Are there maturity issues?

No, it actually has a security proof for the strongest notion for a symmetric encrytion scheme, namely as an authenticated encryption scheme assuming the used block cipher is secure.

Why is it so unpopular?

In general because AES-GCM / ChaCha-Poly1305 is faster with similar security properties. In this specific case of disk encryption because it incurs 16 bytes of overhead per authenticated message. These 16 bytes are really annoying in disk encryption. They mean that either the disk encryption software has to offer a smaller, non-standard sector size which may not be supported by the OS or it has to remove a linear amount of storage from your disk as well as completely break most performance assumptions by requiring two sector accesses by logical sector access.

Most people are not willing to sacrifice ~1% of their disk space and take the high performance stemming from the extra sector accesses for a defense against a rare attack scenario of manipulation attacks.

Is it possible to use a more sophisticated hashing algorithm like bcrypt instead?

Theoretically? Absolutely. Practically? Your disk encryption software simply has to support it.