[dm-crypt] Basics

Michael Kjörling michael at kjorling.se
Fri Sep 25 21:44:46 CEST 2015


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)


More information about the dm-crypt mailing list