Thank you very much for your detailed explanation. The whole thing is much clearer. You and Arno convinced me. I might have taken it too seriously, but I really wanted to understand. I'll probably use this command: cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 (or an other one I haven't decided yet) --iter-time (about) 2000 (I'm generous, about 2 secs seems fine) --use-random Thank you again Mike On 15-09-25 19:44:46, Michael Kjörling wrote: > On 25 Sep 2015 19:33 +0200, from promike1987@xxxxxxxxx (Mike Nagie): > > So first thing; this is a 1TiB HDD. Do I need plain64? Or is there any > > drawbacks? > > For optimal security you _must_ use the "plain64" variant for any > container _larger than 2 TiB_. You _can_ use the "plain" variant for > containers smaller than 2 TiB with no ill effects, but using "plain64" > will not have any ill effects on a smaller container either. > > I would recommend using "plain64" as a future-proofing measure. > > > > Second: Everybody talks about the aes. It seems the twofish is faster > > here. Does this really matters? I mean this is a HDD, I guess it never > > does anything at that pace. (207MiB/s) > > You can expect a theoretical maximum of about 100 MiB/s (+/- 20% or > so) throughput from a 7200 rpm rotational HDD, which is most likely > what you have (unless it's a laptop; then it might be slower). > > I/O patterns are _very_ rarely limited by the maximum achievable > sequential I/O throughput. In practice, you are much more likely to be > limited by other software or by factors not related to sequential I/O > throughput, such as the attainable I/O Operations Per Second (IOPS) of > the hard drive (which is, theoretically, 120 IOPS for a 7200 rpm > drive; in practice probably slightly less). IOPS is a function of the > average seek time of the drive. > > In other words: _any_ choice that gives you about 100 MiB/s or more > will not be the part that bottlenecks your system when using a HDD to > hold the LUKS container. > > AES is a very widely studied cipher which so far has stood up well to > analysis. If you don't have a _very specific_ reason to pick another, > I would recommend that you just go with the flow. > > > > Third: Since xts is supposed to be safer I think it's justified. > > XTS should not be any less secure than CBC-ESSIV, and may be more > secure. > > Summarizing for your first three questions: The default is > aes-xts-plain64 for a good reason. > > > > Fourth: Key size I'm totally lost. Why 512b (even though it's splitted > > to 256) faster than the others? I'm sure something is not right with my theory > > else who would use 256b?! Do encrypted files bigger with 512b or > > what is the point here? > > It might be that AES is hardware accellerated. > > The key size has no impact on the size of the output of the cipher, so > storage capacity is not affected by the choice of key length. > > For a given cipher, I suggest using the longest key length that has > sufficient performance for your scenario. Given that even 512-bit > aes-xts gives you about 110 MiB/s throughput on your particular > system, I see little reason to not go with that when using a > HDD-backed container. Even when using a SSD for storage I would > probably strongly consider it. > > > > Fifth: Hash: I'm thinking about sha256. > > I may be wrong here, but I think the hash is only used during > passphrase to key derivation, and for the LUKS header (which is small > enough that the speed of the cipher should be a non-issue). LUKS > itself does not validate your "payload" data using a hash. SHA-256 > should be fine, SHA-512 might well be better, but neither is a poor > choice IMO given what we know at this time. (Cryptography is an > evolving field, but, pardon the pun, quantum leaps are rare.) > > > > Sixth: iteration time. I misunderstood the benchmark. I thought > > sha256 391259 iterations per second > > means 391259 iterations per second. However I set the iteration time to > > 391259 and well... it needless to say, it didn't open the encrypted > > partition in a second, more like in 10 minutes. So I have no idea how > > should I interpret this one. > > No, the iteration time parameter to cryptsetup takes the _time in > milliseconds_ to iterate the hash function. 391259 ms = 391 seconds or > about 6.5 minutes. The exact time necessary each time you open the > container may vary slightly depending on system load at the time. > > If you want the luksOpen to take about a second, set the iteration > time to 1000. If you check the resultant container using luksDump, > that should show an iteration count in the neighborhood of 400,000 > iterations. > > > > And lastly: --use-random or --use-urandom. I didn't get this one at all. > > Use --use-random. It's really as simple as that. > > The reasons why you might use --use-urandom do not apply to a regular > desktop system. > > -- > Michael Kjörling • https://michael.kjorling.se • michael@xxxxxxxxxxx > OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp > “People who think they know everything really annoy > those of us who know we don’t.” (Bjarne Stroustrup) > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt -- You are so lucky! _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
