On 10/10/2011 10:03 PM, Arno Wagner wrote: >> * If device is not rotational disk, cryptsetup no longer tries >> to wipe keyslot with Gutmann algorithm for magnetic media erase >> but simply rewrites area once by random data. > > Hmm. How do you determine that? Not that I see any fundamental > problem, Through kernel sysfs, rotational flag: /sys/dev/block/<major>:<minor>/queue/rotational If not available, then it is expected that device is rotational. (This flag should be authoritative, e.g. filesystems like btrfs uses it as well to determine allocation strategies.) >> WARNING: There is no possible check that specified ciphertext device >> matches detached on-disk header. Use with care, it can destroy >> your data in case of a mistake. > > It should refuse to mount though, just like a plain dm-crypt > device if you enter the wrong passphrase. yes. I just want to say that by separating header user is responsible to proper pair header and ciphertext device. >> WARNING: Storing LUKS header in a file means that anti-forensic splitter >> cannot properly work (there is filesystem allocation layer between >> header and disk). > > You mean the splitted data may end up all over the disk making > wiping problematic, especially if the filesystem does "overwrites" > to different places? You cannot be sure how is the file represented on disk, it can be fragmented etc. (AF has perhaps problems with SSD wear-leveling so it is nothing new. We should analyse AF with new storage types anyway...) Anyway, header in file is exactly as the same situation as header backup to file. In fact, I forgot to mention that header backup can be directly used in --header parameter. >> * Enhance check of device size before writing LUKS header. > > To prevent problems if the device is smaller than the header? Old code did not checked if header + all keyslots fit on device (but device activation was not possible because payload offset exceeded device size then). But now with separate header it is needed - header write is refused if device is too small. Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
