On Tue, Jan 29, 2019 at 03:48:01PM -0800, Gordon Messmer wrote:
On 1/27/19 6:47 PM, Wolfgang Pfeiffer wrote:
[ .. ]
It sounds like you're unfamiliar with the implementation, and possibly with filesystems and block devices in general. I'll try to explain, with some simplifications. You suggested this command:
cryptsetup open --type plain -d /dev/urandom /dev/<block-device> to_be_wiped
This creates a mapping in the kernel where blocks on the virtual device named "to_be_wiped" are filtered through an encryption algorithm before writing, or after reading, blocks on the physical device /dev/<block-device>.
Running this command (unless I'm misreading the docs for the "plain" section) doesn't actually write to or modify the content of the block device at all. Only when you write to /dev/mapper/to_be_wiped will encrypted data actually be written to /dev/<block-device>.
Seems you are right: I've tested it on a USB flash drive, with ext4 on it and a few files. After running the command above "cryptsetup open --type ..." targeting that drive, the files on it were not overwritten but still there: mounting the drive the usual way just showed me exactly that ..
So the warning cryptsetup is giving here:
------------- cryptsetup open --type plain -d /dev/urandom /dev/sdd dmcrypt.test WARNING: Device /dev/sdd already contains a 'ext4' superblock signature.
WARNING! ======== Detected device signature(s) on /dev/sdd. Proceeding further may damage existing data.
[ .. ] -------------
is technically correct (*may* damage ..) - but chances seem to be extremely good the data on the targeted drive are still alive - So the warning might give the user an unjustified sense of security.
(You would normally create a new filesystem on /dev/mapper/to_be_wiped, which would replace a small number of blocks on the disk with new blocks containing encrypted data related to the filesystem. Again, most of the pre-existing data isn't overwritten by that process. The old data would not be readable through /dev/mapper/to_be_wiped, but could be directly through /dev/<block-device>.)
Understood, I think ..
The next step of the process you suggested was:
cat /dev/zero > /dev/mapper/to_be_wiped
This will write zeros to the virtual block device, which will be filtered through the encryption algorithm and the results written to the blocks on the physical device. This will sequentially overwrite the contents of the physical disk.
In other words: It seems the file system is encrypted, not the data: see the already mentioned FAQ: "Create the LUKS container" - at the end of the section: "Done. You can now use the encrypted file system to store data"
The command you referenced above doesn't use LUKS, but that's a minor nit.
Both the filesystem and your data are encrypted when using dm-crypt (whether you use LUKS or not). However, creating a dm-crypt device doesn't modify the pre-existing data. It only writes encrypted data to the disk when data is written to the virtual device.
Provided it works: yes. I had situations where I first ran
cryptsetup open --type plain -d /dev/urandom /dev/<block-device> to_be_wiped then cat /dev/zero > /dev/mapper/to_be_wiped or something similar like dd if=/dev/zero of=/dev/mapper/to_be_wiped bs=1M status=progress
and the data on the targeted drive were still there. No idea whether this happened because of faulty hardware or because of a software bug, or whatever. A sign that something like "cat /dev/zero .. " doesn't write encrypted data to the physical drive might be that the command finishes after only a few seconds (didn't take ten secs here, IIRC)
One last "cat /dev/zero .." worked 'tho after closing "gnome-disks", which previously ran while issuing the cat or dd command. And the reason I tell that is not to open a debate about why cat or dd commands didn't work in that situation. It's just a reminder to be careful if a user is trying to secure their data this way.
Does that make sense?
Definitely: Thank you very much for your time and the effort to explain all this.
Regards, Wolfgang