On 26 Sep 2015 09:14 +0200, from promike1987@xxxxxxxxx (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.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
