Hi, I have some questions to indicate I think the exclusive flag (and --shared) question should be indicated in FAQ, since it's a significative change in cryptsetup default behaviour and a potential day by day question made. Would be fine too to indicate where should be used --shared and where not (to avoid data corruption.) > > * 5.11 What about iteration count with plain dm-crypt? > > Simple: There is none. There is also no salting. If you use plain > dm-crypt, the only way to be secure is to use a high entropy > passphrase. If in doubt, use LUKS instead. > > > > * 5.13 Why was the default aes-cbc-plain replaced with aes-cbc-essiv? > > The problem is that cbc-plain has a fingerprint vulnerability, where > a specially crafted file placed into the crypto-container can be > recognized from the outside. The issue here is that for cbc-plain > the initialization vector (IV) is the sector number. The IV gets > XORed to the first data chunk of the sector to be encrypted. If you > make sure that the first data block to be stored in a sector > contains the sector number as well, the first data block to be > encrypted is all zeros and always encrypted to the same ciphertext. > This also works if the first data chunk just has a constant XOR > with the sector number. By having several shifted patterns you can > take care of the case of a non-power-of-two start sector number of > the file. > > This mechanism allows you to create a pattern of sectors that have > the same first ciphertext block and signal one bit per sector to the > outside, allowing you to e.g. mark media files that way for > recognition without decryption. For large files this is a > practical attack. For small ones, you do not have enough blocks to > signal and take care of different file starting offsets. > > In order to prevent this attack, the default was changed to > cbc-essiv. ESSIV uses a keyed hash of the sector number, with the > encryption key as key. This makes the IV unpredictable without > knowing the encryption key and the watermarking attack fails. One question here, does this applies just only to LUKS container or to dmcrypt plain too. At first sight looks like that it applies just only to LUKS containers since dmcrypt does not stores nothing, the first time I read it I interpreted this but I remember I get realized of this situation when the default cipher value was changed to aes-cbc-essiv and the plain dmcrypt container was unrecognized unless aes-cbc-plain was indicated. So I would point here that this get applied to both since is a trouble in the way ciphering is done and not how does metadata get stored. > * 5.15 What about XTS mode? > > XTS mode is potentially even more secure than cbc-essiv (but only if > cbc-essiv is insecure in your scenario). It is a NIST standard and > used, e.g. in Truecrypt. At the moment, if you want to use it, you > have to specify it manually as "aes-xts-plain", i.e. > > cryptsetup -c aes-xts-plain luksFormat <device> > > For volumes >2TiB and kernels >= 2.6.33 use "plain64" (see FAQ > item on "plain" and "plain64"): > > cryptsetup -c aes-xts-plain64 luksFormat <device> > > There is a potential security issue with XTS mode and large blocks. > LUKS and dm-crypt always use 512B blocks and the issue does not > apply. > Not directly related with this by also related with and open issue about deniable plausibility implementation, you mentioned Truecrypt, but I would also give mention to scubed, it's unmaintained but it's small (+-600 lines of source code) and works fine. And thats all, thanks. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
