Oh, yeah, you are right. That part was clear and therefore I forgot to write it down. I meant: cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 2000 --use-random (--verify-passphrase) luksFormat /dev/sdXY I don't know 'verify passphrase' is justified or not. I guess I'll use one of the password generators. I did not mention, this is a laptop, so it spins 5400 revolutions per minute. 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) According to the ArchWiki, the dd block size could be larger than default. It comes from this that the upper command may exit before wiping the last blocks if a larger block size is used. How could I prevent this or make sure everything is overwritten? Thank you! Mike On 15-09-25 22:24:10, Michael Kjörling wrote: > On 25 Sep 2015 23:48 +0200, from promike1987@xxxxxxxxx (Mike Nagie): > > 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 > > Looks reasonable, except you forgot to pass "luksFormat" and a device > to cryptsetup, so it won't know what to do with the rest. :-) (Oh, and > note that as discussed here previously, the problems with SHA-1 > leading to its current sunsetting don't affect its usage in LUKS. In > fact, I'd expect that for LUKS' purposes, even MD5 would still be a > secure choice, if perhaps somewhat... unusual.) > > If you want additional security against forensic analysis, a good > strategy might be to set up a LUKS container with a throwaway > passphrase and key, and then "dd" or "ddrescue" zeroes into it, then > create your real LUKS container in place of the throwaway one. That > will ensure that any remnants of old data are gone, and will prevent > forensic analysis based around which parts of the container appear to > hold encrypted data. In other words: > > cryptsetup luksFormat /dev/something > cryptsetup luksOpen /dev/something dummy > dd if=/dev/zero of=/dev/mapper/dummy bs=1M > cryptsetup luksClose dummy > cryptsetup luksFormat ... the real deal goes here ... > cryptsetup luksOpen /dev/something the_real_deal > ... now make a file system on /dev/mapper/the_real_deal and start using it ... > > Note that the "dd" will take many hours to complete on large drives. > Given that you have a 1 TiB drive and assuming it's a 7200 rpm drive, > I would expect that to take about 3-4 hours if you give LUKS the whole > drive and assuming that there are no other disk accesses going on > concurrently. Using GNU ddrescue instead will provide you with a nice, > continually updated progress report, but effectively does the same > thing. The all-zeroes will be encrypted and on the next luksFormat the > key will be overwritten, resulting in unused portions of the drive > looking like random garbage to anyone looking. > > -- > 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 -- You are so lucky! _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
