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 result: 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 better/safer. 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 everywhere? 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@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 -- You are so lucky! _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
