michael at kjorling.se
Sat Sep 26 17:38:23 CEST 2015
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
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
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
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.se • michael 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