[dm-crypt] Basics

Mike Nagie promike1987 at gmail.com
Fri Sep 25 23:48:34 CEST 2015


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 at gmail.com (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.semichael at kjorling.se
> 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 at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
You are so lucky!


More information about the dm-crypt mailing list