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
