I have following multiple times the README_CRYPT.TXT to install a fresh install of Slackware with full disk encryption with LVM or without.
In README_CRYPT.TXT suggest a key size of 256 bits with default cipher aes', with mode 'cbc-essiv:sha256'.
Some people recomends as best cipher: aes-xts-plain64 with --iter-time 5000 and key-size to 512.
Because i travel a lot and my laptop carries sensitive data i want to be safe as much as possible...
(i'm a little paranoid and always have time for dev/urandom before encrypt the partition )

Any suggestions?
Thanks in advance.

IIRC README_CRYPT.TXT was written pre xts, when cbc-essiv was the default. Either one is fine, with xts you'll probably get better theoretical performance (my CPU does 500 mb of cbc per second, and 1600mb/s with xts, both of which surpasses my SSD's write speed). There are sophisticated weaknesses of xts, that doesn't really apply to the "lost laptop at airport" scenario. (Wikipedia is a decent starting point if you're intrested.) Go with xts if you want new-and-fancy (and probably overall better), or cbc-essiv for tried-and-true. Nowadays xts is the default for LUKS in cryptsetup...
For --key-size, xts needs twice that of cbc, to account for the two keys used by xts. So xts-512 ≈ cbc-256, security-wise.
--iter-time is the amount of time spent hashing the passphrase, which will depend on the CPU used for the luksFormat (or luksAddKey). It has nothing to do with the encryption mode. How long are you willing to wait for password confirmation each time you unlock the disk, and how much more powerfull is the CPU used by the assailant trying to brute force you're stolen laptop?

2 members found this post helpful.

For almost all use cases, aes-cbc-essiv is "good enough". aes-xts-plain will not bring you more(*) in terms of confidentiality, but mostly a better performance (shorter time to read/write a sector), which is why it is the preferred mode.

(*) technically, cbc and xts modes offer the same protection against hostile access, but xts offers a better protection against modification -- In practice, it shouldn't make a difference in your use case, -- or you probably have many other things to worry about!

HTH

Phil

aes-cbc-essiv is "good" but not "enough".

http://www.jakoblell.com/blog/2013/1...ks-partitions/

Use XTS plain mode only for block-level disk encryption .Its default mode from 1.6 cryptsetup.
XTS is not good for filesystem encryption.For this better choice is CBC or CTR mode.

http://www.linuxquestions.org/questi...-essiv-727780/
http://sockpuppet.org/blog/2014/04/3...dont-want-xts/
https://en.wikipedia.org/wiki/Block_...e_of_operation

For cipher aes 128 is enough . 256 do not double security because has reduced amount of rounds. If you need 256 bits choose twofish or serpent. It's better choice IMO.

https://www.schneier.com/blog/archiv...r_new_aes.html

4 members found this post helpful.

I personally recommend and use:

However, you can use sha256 instead of whirlpool 256. You can also use AES instead of twofish. I don't use them, because I don't trust the NSA

CTR is both faster and safer than CBC. XTS is an option, but IMO it is a very complicated standard, so much so that it was initially misinterpreted in its implementation and it stuck from then on. It may also have weaknesses:
https://en.wikipedia.org/wiki/XEX-TC...ling_.28XTS.29

"CTR is both faster and safer than CBC."

Is faster but not safer in disk block-level encryption IMO.
CTR is a stream mode.

Two things:

1. Suppose you use the sector number times the number of AES blocks per sector as the initial value for CTR. If you successively store the content $M$ then $M'$ in the same sector $n$ then $E^{CTR}_n(M) \oplus E^{CTR}_n(M') = M \oplus M'$ (where $E^{CTR}_{n}$ is the encryption function with CTR mode and IV started for sector number $n$). CTR mode fails catastrophically when you reuse a counter value, because it's a pure xor stream cipher: xorring two ciphertext blocks that were produced with the same key and counter values cancels out the encryption. For example, if the block started out as all zeroes (which happens pretty often in practice) and an adversary manages to obtain both the initial ciphertext and the updated ciphertext, then the adversary has the confidential plaintext on a platter.

If you use the sector number as the initial counter, it's even worse since the second block of a sector shares a counter with the first block of the next sector and so on. That would enable an adversary to reconstruct a lot of content with even a single snapshot of the disk.

To use CTR safely, you need to generate a fresh counter value each time. You can use the sector number as part of the initial counter value, but there's little value in doing so, because you'll need to store the rest of the counter (some kind of per-block update count, a global counter value, a random value, or any other scheme) anyway.

2.CTR like other stream ciphers is extremely malleable: the attacker can flip plaintext bits by simply flipping the corresponding ciphertext like in CBC attack in this link:

http://www.jakoblell.com/blog/2013/1...ks-partitions/

XTS in not a bullet proof but for now seems the best option for disk encryption.
Is suffers for
its normally named "malleable" too. You can change a ciphertext block and the corresponding plaintext block will change too, but the result of this change is not predictable by the attacker without knowing the key and leads only to data corruption.

1. Yes, as with stream cyphers, in CTR mode you cannot use the same keystream twice. This is not really an issue for the amount of data that you usually encrypt.

Any encryption mode can be implemented incorrectly leading to catastrophic failure.

2. Encryption in general makes no guarantee of data integrity. CBC has malleability only for every other block, but that does not help much. Add a MAC to prevent this.

I don't think XTS is the best, too new, too complicated, I'm sticking with CTR.

I don't think XTS is the best too but introduced it because of weekness and due to adaptive chosen ciphertext practical attacks on CBC and CTR mode .Specialy in disk encryption .

Hence tweakable ciphers/XTS/ as a workaround the problem.

The trivial malleability of CTR is apparently why NIST rejected it.
If an attacker get access to the disk once CTR or CBC is sufficient. Otherwise not.

MAc is OK but running it for every sector is extremly slow.

For me question is not which mode is better, but is still full disk encryption secure without checking data integrity as it seemed earlier?
Now I doubt it.
Maybe time to apologize to the file level encryption with HMAC.

You have a point here. Maybe we need authenticated encryption.

But to offer transparent file encryption, the files must be encrypted page per page (to support not only sequential but also direct access) and so a HMAC must be computed for each file page. Therefore there shouldn't be a lot of performance difference between file and block authenticated encryption...

Then, another issue is the storage of these HMAC. Admittedly, this would be easier for file encryption.

For non FDE /Full Disc Encryption/ the safest option is GMC mode but CBC is OK too.

That's why we should not use XTS for anything elese than FDE.
Practical example.

1. Original Tux picture

http://www.hostmat.eu/images/56274172069395136692.jpg

2. ECB mode enc. Tux

http://www.hostmat.eu/images/43503767835108077159.jpg

3. XTS mode

http://www.hostmat.eu/images/82938431083638451066.jpg

4. CBC mode

http://www.hostmat.eu/images/50790081436704287635.jpg

XTS suffer the same issue like ECB to a much smaller scale. This randomness is acceptable only for disk encryption .
CBC has the most random /secure/ crypto pattern but for the fact that chaining gives attackers a forward bit-flipping capability and practical malleability and for CTR trivial malleability,There is proved that modes are more unsafe now for FDE than not 100% random pattern from XTS mode IMO.

2 members found this post helpful.

My answer was only related to your question "is still full disk encryption secure without checking data integrity as it seemed earlier?"

But anyways, thanks for the fun/visual comparison between modes! Indeed, I was surprised to see how XTS is visually bad (relatively speaking)...

Seems... Rhetorical question.
Safe but not in the sense as safe as we thought until recently
People used to believe you could divorce confidentiality from integrity, back in the 1990s, but that turned out not true now, due to practical adaptive chosen ciphertext attacks.

BTW.I forget mention that for examples above I used AES 256 cipher.

What are the commands you used to generate those ? Can you do CTR mode, it's probably the same as CBC.