On 5/31/06, Carlo Wood <carlo@xxxxxxxxxx> wrote:
On Wed, May 31, 2006 at 10:20:42AM -0400, Deskin Miller wrote: > Right-- known plaintext attacks, perhaps other weaknesses in the > encryption with just zeros-- to messy to figure out. > > So how about this? We do like they suggest with /dev/zero, but we do > it with a randomly-generated key, which has nothing to do with the key > used to actually encrypt data, and furthermore doesn't need to be > remembered: we throw it away after writing the random (encrypted) > data. > > When the disk is actually mounted, it uses the real key, generated > from a passphrase or some other method, business as usual- the data > written to the drive is still zeros, but with a cryptographic key > which we didn't remember, and aren't using anyway, so with the real > key the data is seemingly random. Is it? I thought that things were encrypted per block. I don't know how this works, so anyone who does please correct me, but my guess would be that using all zeroes would result in a repeating pattern: every block would look the same, wouldn't it? If that is true, then it wouldn't be random at all.
It would be reasonably random, if you do any not-braindead approach, involving cipher block chaining and initial vectors for the encryption: these are intended to solve the problem of encrypting huge amounts of data with the same key, in blocks. Cryptsetup already allows you to do this, no need to further explain it here-- basically, the 'zeros' would not appear to be a repeating block.
Moreover, I still don't get why this is necessary at all. My guess was that you do this to *erase* the not-encrypted data that was on the disk before you installed dm-crypt. So, if the harddisk is brand new, then this is not needed, correct?
Depends on who you are-- there would certainly be no data for them to find. But maybe you want to hide that fact too, somewhat.
If however there was un-encrypted data on the disk, then please note that overwriting it with a random pattern won't help. It is possible to (after taking the disk apart, so one would need a laboratory for this-- but there are companies specialized in it) read the magnetic information from the disk in an analogue way.
True. So wipe it twenty times, with a different random key each time. It seems that this is chiefly a performance issue; we want to wipe our encrypted drives prior to use with random data, and we want to do it as fast as possible. Does anyone have *real* numbers on these different approaches? Another technique, since the device-mapper just creates a mapping, and does not prevent us from messing with the physical device underneath, would be to not bother with writing through encryption at all- read from /dev/urandom and write straight to the underlying block device. For instance, the setup might look like (following the top-of-thread directions): //random data to the block device... # dd if=/dev/urandom of=/dev/hdd7 bs=512 \ count=`blockdev --getsize /dev/vg0/home` //as before # cryptsetup --verbose --verify-passphrase luksFormat /dev/vg0/home # cryptsetup luksOpen /dev/vg0/home home and so on. I see three techniques, which I believe to be cryptographically secure (prove me wrong, fellas!), which, if this is true, should be *benchmarked*. (After all, that's all this discussion is about at this point): 1) write data from /dev/urandom straight to underlying block device (/dev/vg0/home in the example): looks darn random, and doesn't have to be encrypted. 2) write data from /dev/urandom to mapped LUKS-setupped device (/dev/mapper/home in the example): looks random, but has to go through the encryption specified at cryptsetup time, so should be slower. 3) write data from /dev/zero to mapped LUKS device, *using an on-the-fly generated key, which we don't need to remember*: dm-crypt takes care of `randomizing' the data by encrypting zeros (you did remember CBC and essiv mode, right?), which, after re-configuring the device with our real LUKS key, looks random. This, I would suspect, improves over #2, but falls behind #1; plus, it's a pain to configure a LUKS device, then have to reconfigure it after wiping it. -Deskin Miller --------------------------------------------------------------------- - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
