Hi! Thank you for you interesting reply! Heinz Diehl writes: >> 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. > > ESSIV has been develop to address this problem and is not prone to > watermarking. The developer of ESSIV is here on the list, and maybe > you're lucky and he will explain this a little bit closer to you. Yes, I know he is on this list. And I know it was invented for that purpose. But still, Wikipedia claims: > To protect against the watermarking attack, a stream cipher is often > used to generate the IVs from the key, so that an adversary cannot > predict them. In particular, the ESSIV approach discussed below uses > a block cipher in CTR mode to generate the IVs. Another option would > supplement this IV with a hash function applied to every block but > the first. However, neither of these options guards against the > decryption attack above. Q: http://en.wikipedia.org/wiki/Disk_encryption_theory Quite obviously not all is true that's written out there, but there we are: I just do not know. If any trustworthy person told me that the above is rubbish, it would be fine with 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? > > So they who has raised these claims you described above didn't provide an > explanation for their statements? IIRC, the weakness itself was discussed on this list a few months ago. Here's another source: > According to the IETF NIST submission[0] for the tweakable block > cipher xts (and I paraphrase here, as the document prohibits direct > quotation): the proof yields strong security guarantees as long as > the same key is not used to encrypt much more than 1 terabyte of > data. Up until this point, no attack can succeed with probability > better than approximately one in eight quadrillion. However this > security guarantee deteriorates as more data is encrypted with the > same key. With a petabyte the attack success probability rate > decreases to *at most* eight in a trillion, with an exabyte, the > success probability is reduced to *at most* eight in a million. Q: http://tinyurl.com/np9wum I'd like to use an algorithm without such a weakness. >> I don't seem to be able to make a decision on my own, so I'd like to >> ask for help. > > We shall decide for you? No, of course not! I'd be very happy with pointers to more information so I can judge myself which problems are bad for me and how I can avoid them. > That's generally a bad idea. There's only one person with the whole > knowledge, and that's you. I'd love that to be true! But I do not have all knowledge concerning the likelihoods of the attacks, and also lack knowledge about how to avoid the weaknesses. > I don't know why you want to have your harddisk encrypted, ... > what kind of data you have, how important they are for yourself and > others, how the potentially encrypted harddisk is secured else, and > so on and so on... There is no immediate threat or strict confidentiality involved, but I'd like to keep all my data private, e.g. in case it is stolen, and because it's easily done. Plus very secure erasure of encrypted hard disks is very quick by overwriting the keys (in case I don't want to use them anymore). Further, if a disk is broken, I can send it in without companies being able to read plain text. But I'd like to avoid mistakes of using a weak encryption algorithm, so I would like to understand what are the pros and cons for cbc-essiv or xts-plain or any other alternative. > You can take a look at dm-crypt.c to find out what methods of IV > generation are supported by LUKS/dmcrypt. Encryption algorithms are very complex beasts, and I do not think from reading source code I could see any subtle weaknesses myself. > -c twofish-cbc-essiv:sha256 > > in case it gets lost or stolen, to prevent the thieves from getting > access to my money. I decided to use just this algorithm because I > did some benchmarking and it performed best (the major drag on a > Laptop is the slow harddisk). So you decided by speed alone? Because you think any option is strong enough security for you? Speed is not really an issue for me -- any simple option is very propably fast enough for me (except maybe multi-layered encryption, which would seem like overkill to me). I read a lot of manuals, all using one or another particular setting for -c, but without explaining why exactly that one was chosen for the examples. Is feels arbitrary. E.g. I used aes-cbc-essiv:sha256 before, because I found this recommendation in a manuals. But now I have larger disks and, of course, there are new algorithms and more understanding of old ones, so now the recommendation might not be valid anymore (it was without explanation in the first place). > A lot of distributions also use "-c aes-xts-benbi:sha256". And why do they do so? **Henrik _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
