Encrypting a large ZFS Volume... Initialize with Random Numbers

[cyberjock]

Okay, this is basic crypto.

If you do:

Code:

# dd if=/dev/zero of=/dev/da0
<now create encrypted filesystem on da0>

then even a newbie can tell that a certain amount of space is or has been used on the encrypted filesystem: you count the number of blocks that still contain all zeroes. This is an information leak, a major crypto no-no.

However, if you do

Code:

<create encrypted filesystem>
# dd if=/dev/zero of=/mnt/my-encrypted-fs/file

and let it fill the filesystem, the data actually written to da0 is an encrypted stream of zeroes; each block is different from the next, and you need the decryption key to figure out that they're all actually zero.

Now, from a security point of view, that's still not really all that great, because someone who is attacking the system to recover data, and is able to obtain the encryption key, may be given clues as to which blocks are irrelevant to analyze.

So the ideal method is to fill the disks with /dev/random. However, the point I'm making is that if the process of filling your disks with noise takes so much time that it doesn't complete successfully or in a reasonable amount of time... well, filling with /dev/zero on the encrypted filesystem at least eliminates the first case.

Aah, I understand what you are saying. I was thinking only about removing the current data that is on the drive and not potential future attacks on the disks.

I think there's two different thoughts here.

If you're wiping a drive purely so data is not recoverable, then a /dev/zero wipe should be sufficient. The drive is empty, and nothing retrievable. (I think the jury's still out on whether, with advanced analysis, you could still get to the original data when it's been overwritten with zero's. I don't think so.)

Then there's wiping a drive with the intent of using it to store encrypted data. This has to be wiped with random data so that further encrypted data can't be told apart from the non-used random data. 'Used' encrypted data should be indistinguishable from 'old' random data.

I don't think I'd use the gui for wiping drives that are going to be used in encryption. I'd startup dd's on the console, and monitor them from there. Depending on the cpu, there may be little point to starting all the drives at once. I assume /dev/random is single threaded, so with a quad core cpu, there may be no point in writing random data to more than 4 drives at a time.

After the dd random wipe, which may take quite a while, I'd use the gui to make the pool, and NOT check the option to initialize with random.

^^^ This is exactly what I was thinking next. Sure, it requires you to manually ensure that they are all wiped, but its not that hard to do.

 

[jgreco]

Removing current data is best done with DBAN, which I think also has a mode that'll leave pseudorandom trash on the disk.

 

[macnlz]

Hi! This is my first post, and I’m new to NAS in general, FreeNAS, FreeBSD, and building a PC from parts... but I do have some comments on this topic. ;)

First, writing zeros onto an encrypted file system may open an attack vector, because it creates a large region of known data, and depending on the encryption method, it may become easier to decrypt other parts of the data if you have such a Rosetta Stone. This may or may not be the case here, but if you’re going to be paranoid, it’s always better to write random data before encrypting the drive...

Second, I looked up the difference between /dev/random and /dev/urandom. The former will be slower because it has an entropy pool which may be depleted, and reading from it will block until sufficient entropy has been added back to the pool. The latter will be sufficiently random for most purposes, so I think it should be fine to use here. I’m getting about 57MB/s from /dev/urandom on my machine.

Third, both random devices can apparently only be accessed by one process at a time, so writing to multiple disks will simply reduce throughput per disk as the other dd processes have to wait for their turn to get data. I compared the sum of throughputs when writing to one or more drives, and it seems that sequentially clearing the drives may be at a slight advantage.

Fourth, I found that a block size greater than 1MB seems to slightly reduce throughput in this scenario.

I kicked off a detached tmux session in the console and am currently running the following command to prepare my drives:

Code:

ls /dev/ada* | while read disk; do dd if=/dev/urandom of=$disk bs=1M; done

For my six 2TB drives, I’m looking at 57 hours of wipe time...

 

[survive]

Hi guys,

So...not to get off topic, but do we have any idea what the errors were that filled up /var?

-Will

 

[macnlz]

So...not to get off topic, but do we have any idea what the errors were that filled up /var?

In my first attempt, I used the feature provided by FreeNAS.

I didn’t check /var, so I can’t say for sure whether this is related, but I did notice some bad behavior:

Notice the wedge of increasing user-space CPU usage. That was caused by a single process: “/usr/local/bin/python /usr/local/www/freenasUI/manage.py runfcgi method=threaded host=127.0.0.1 port=9042”

The wedge went away when I did a “renice 20” on the process.

I left the 6 parallel dd processes running for about about 19 hours, and reniced after the first 8. The feature was using /dev/random though, and I was only getting about 8MB/s per drive – or 48MB/s total throughput, compared to the current 57MB/s. But the reason I canceled it was that I didn’t trust this web process wasn’t still doing some other bad things (such as logging to /var) in the background.