[dm-crypt] Basics

Mike Nagie promike1987 at gmail.com
Sun Sep 27 13:08:59 CEST 2015

Thank you for your answer!
Let me summarize what I have learned so far.

The cipher key size doesn't impact on disk space. Maybe it might impact 
on speed; aes-xts 256b was 141.5MiB/s while aes-xts 512b was 108.5MiB/s. 
Twofish is a riddle why it's so fast.
I don't know how reliable this is, but
dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync gave me this 
536870912 bytes (537 MB) copied, 18.2785 s, 29.4 MB/s
(Without fdatasync I got 572 MB/s, which obviously is not true)
So according to the dd result, I could choose any cipher, even serpent 
would not slow my system down.

Since iteration time means millisecond here, it doesn't matter which 
hash I choose.
cryptsetup -h sha1   -i 1000 ... 
cryptsetup -h sha512 -i 1000 ... 
both should take 1 second, just sha1 has 644088 iterations per second 
(on my computer) while sha512 only 321254.
Isn't sha1 safer in this case? I thought the more iterations, the 
I still don't understand if -i just the number of milliseconds, why does 
it differ if I change the CPU. Isn't 1000 milliseconds, 1000 milliseconds 

Thank you for the hint about passwords/passphrases.
Whether is 'cleft cam synod lacy yr wok' more secure than 'nXRUzbL6' (a 
random 'pwgen' generated password)?
I thought I was going to use the same password as my login password, so 
I wouldn't have to enter 2 passwords during every boot.

On 15-09-26 15:38:23, Michael Kjörling wrote:
> On 26 Sep 2015 09:14 +0200, from promike1987 at gmail.com (Mike Nagie):
> > I guess I'll use one of the password generators.
> If you want a passphrase that you can actually remember, consider
> (_manually_) creating a Diceware passphrase of sufficient length. See
> www.diceware.com. Remember that you can increase the iteration time to
> effectively strengthen the passphrase without needing to make it
> absurdly long. Even going from a 1000 to 2000 ms iteration time makes
> a huge difference in the ability of an attacker to attack the
> passphrase directly (and even 1000 ms on common hardware is quite
> sufficient in almost any use case).
> > I did not mention, this is a laptop, so it spins 5400 revolutions per 
> > minute.
> In that case, you should expect maximum I/O throughput to be
> correspondingly lower, at which point I'd expect a full 1 TB
> purely sequential overwrite to take up to some 6-7 hours.
> > My data is not encrypted now, and I should securely erase it as 
> > you suggested too (against forensic analysis). Is
> > 
> > cryptsetup open --type plain /dev/sdXY dummy --key-file /dev/random
> > dd if=/dev/zero of=/dev/mapper/dummy
> > rm /dev/mapper/dummy
> > 
> > sufficient,  or I should use shred or srm beforehand?
> > (Time is not that important as security, but since this is a
> > 5400 1 TiB HDD, I bet srm would overwrite this for days)
> After replacing the "rm" with a "cryptsetup close" as mentioned by
> Mistave, I believe that will do fine.
> You _do_ want to specify a larger blocksize though; otherwise, that
> "dd" is going to be painfully slow. Just tack "bs=1M" (or an even
> larger block size) at the end of the dd command line. I think the
> default is a block size of 512 bytes, which _dramatically_ reduces
> attainable I/O speeds.
> With modern rotational drives (mid-1990s or so and newer HDDs), common
> wisdom is that a single-pass overwrite is sufficient for total erasure
> of data. It is _theoretically possible_ that remnants of old data may
> be left behind, but this will not be distinguishable from noise and
> thus of no practical use to an attacker. Also, unless you are a very
> high value target, chances are that an adversary would use only
> software-based methods of access to stored data anyway; anything more
> is simply too expensive to employ in anything but extraordinary cases.
> It is far more likely that a determined adversary would either install
> a keylogger, or force you to reveal the passphrase. Compare
> <https://xkcd.com/538>.
> The purpose of this overwrite step is to overwrite everything on the
> drive (or partition) with random garbage before you start using it as
> a LUKS container. That way, an adversary won't have the advantage of
> being able to focus on areas that actually contain data; the entire
> drive or partition will look the same to an external observer without
> access to the passphrase. To someone with access to the passphrase
> (and thus the data encryption key), there remains the possibility of
> telling which portions of the container are in use, but at that point,
> _you have already lost anyway_: they have the ciphertext and they have
> the key.
> As a consequence, **there is no need to do any other overwrite step
> before (or after) you do this through-LUKS overwrite**, regardless of
> which variant you use. The important part is that you throw away the
> key that you use for this overwrite and use a new one going forward.
> And lest we forget: make sure to have proper backups in place (ideally
> themselves properly protected, possibly through encryption). If the
> LUKS header gets damaged, or if you forget the passphrase, you will
> not be able to access the contents of your encrypted container.
> -- 
> 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