On 03.08.2009, Henrik Theiling wrote: > Yes, I know he is on this list. And I know it was invented for that > purpose. But still, Wikipedia claims: [....] So we'll never know unless someone with enough expertise can tell us the truth. > > 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. > I'd like to use an algorithm without such a weakness. The weakness is not related to the algorithm itself, but to the IV generator. I would maybe have used xts in this case and had the harddisk divided in three partitions with 500GB, using a different key for all of them. > 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. Ok, if your data are not likely to get stolen by one of the organisations with the three huge letters, I would say that it makes no difference what algorithm or method you are using. I would have choosen the one which provides the highest speed. I think that 99.9999999% of all people in the world are not able to do a successful attack on one of the supported algorithms and operation modes. So it does not matter if you are using it for wiping a harddisk, storing your data securely or have to send in a broken harddisk to the servicefolks. The main weaknesses are often related to a bad passphrase or different circumstances which makes it easy for an adversary to get it, e.g. writing down the passphrase or choosing not enough entropy. > 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. To know that for shure, this is up to the people who have written this beautiful piece of software, who have designed the methods/algorithms by themselves or ones who are able to fully understand the sourcecode. > > 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. That was not my intention, they are all listed in this file, and you can see what you will have to choose from. > So you decided by speed alone? Because you think any option is strong > enough security for you? Yes. > 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). Multi-layered encryption is just stupid. See Kerckhoff's principle: http://en.wikipedia.org/wiki/Kerckhoffs%27_principle With regards to my little knowledge, the algorithm which is most secure per today is serpent, I probably would have choosen "-c serpent-xts-benbi:sha256 -s 512" and had the harddisk gotten divided into three partitions of 500GB. This results in Serpent-256 encryption (256 bits go to XTS). > > A lot of distributions also use "-c aes-xts-benbi:sha256". > And why do they do so? That's the question :-) I simply don't know. We can only guess. There's so much disinformation and uncertainty out there. I don't know. PGP WDE e.g. uses (hardcoded) AES-256 in EME mode, and the key is derived via the STR2KEY function. But _why_ they use it (maybe they think or know this is the securest possibility?!), I don't know either. Sorry I can't help you out. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
