Remedy for not having filled the disk with random data?

Question

Filling a large HDD with /dev/urandom prior to encryption can be extremely slow (even with netcat, multiple instances in parallel, etc) and for this reason I'm sure a lot of users skip this advice even if it is recommended practice and unsafe to omit.

My question is: Assume a user has omitted this step of filling the disk with /dev/urandom, or only done it partially. Are there any steps that can be taken after the HDD has been encrypted to make it harder to perform cryptanalysis on the disk?

I'm assuming the best case scenario for the attacker would be if the user filled the entire disk with /dev/zero and then encrypted it? Would it then help if the user filled the entire disk (after having encrypted it) by writing /dev/zero to some arbitrary file in the file system, then deleted the file to recover the 'used' space? Wouldn't this remove any stray null bytes on the device and replace everything with just encrypted data?

So in the more realistic case, would it help to fill the disk with data after it has been encrypted? If not, why not? Imagine the disk has actually been filled to the maximum capacity after it has encrypted, what value does then the prior filling with random data before encryption hold? All that /dev/urandom data has been overwritten anyway, so what value does that operation hold at that stage?

If needed assume the system is: x86-64 GNU/Linux with LUKS, 256 bit AES, mechanical HDD (does this change with SSD? Please include why, as that would be interesting).

Attack scenario: The HDD is stolen and obtained removed from the computer by the attacker, preventing attacks such as evil maid and cold boot attacks.

Answer 1

Are there any steps that can be taken after the HDD has been encrypted to make it harder to perform cryptanalysis on the disk?

As the disk is now already encrypted, I'd suggest to fill the remaining filesystem space with (random) data, e.g. pipe /dev/urandom to a file (which you can delete afterwards). That way the underlying (block-)device will fill up with encrypted data ("noise").

So in the more realistic case, would it help to fill the disk with data after it has been encrypted?

Yes, it would help - see above.

Imagine the disk has actually been filled to the maximum capacity after it has encrypted, what value does then the prior filling with random data before encryption hold?

Well, doing it before the initial encryption would protect you from forgetting it afterwards. I.e. setting up full disk encryption in the morning and "I'll fill up the disk later this evening" but then the disk got stolen inbetween.

Note: even after a completed full disk encryption, the disk's controller may not be able to zero every part of the disk, see Data_remanence for more details on that topic.

Answer 2

The only information an attacker should be able to extract from an encrypted disk that hasn't had a full random overwrite is an upper bound on the amount of encrypted information on the disk.

To put it another way, a good disk encryption solution shouldn't be relying on an attacker's inability to determine the bounds of the encrypted partition for any security properties.

I agree that filling the disk with data after encryption should yield the result you expect (provided the encrypted partition can dynamically expand to fill the whole disk): all of the data on the disk should now appear to be random (minus partition table etc depending on the solution).

Answer 3

Filling a large HDD with /dev/urandom prior to encryption can be extremely slow (even with netcat, multiple instances in parallel, etc) and for this reason I'm sure a lot of users skip this advice even if it is recommended practice and unsafe to omit.

On newer Linux kernels, the /dev/urandom device uses ChaCha20 for randomness, rather than a slower SHA1 mixing function, allowing it to be very, very fast. If you don't have a newer kernel, a simple solution is to either use OpenSSL, or dm-crypt for creating randomness.

OpenSSL is the simplest, requiring only one command:

openssl aes-128-ctr -nosalt -in /dev/zero -out /dev/sdX -k $(head -c16 /dev/urandom | base64)

Using dm-crypt is more complex, but it can often make use of faster kernel-accelerated crypto:

cryptsetup open -M plain -c aes-cbc-plain -s 128 -d /dev/urandom /dev/sdX wipeme
cat /dev/zero > /dev/mapper/wipeme
cryptsetup close wipeme

My question is: Assume a user has omitted this step of filling the disk with /dev/urandom, or only done it partially. Are there any steps that can be taken after the HDD has been encrypted to make it harder to perform cryptanalysis on the disk?

Well first of all, the issue is not that it makes cryptanalysis easier. AES isn't so weak that mere gigabytes of known plaintext results in key recovery. Some of the strongest PRNGs generate random data by encrypting a null stream with a random key. The issue is rather filesystem-level metadata leakage (knowing what blocks are free and which are not), which gives away the overall layout of your filesystem. This can leak not only how much space has been used, but a lot more information such as file sizes, positions, possible previous actions done on files, and more. There have been cases of arrests and convictions based only on an encrypted file's metadata (for example, sizes).

I'm assuming the best case scenario for the attacker would be if the user filled the entire disk with /dev/zero and then encrypted it? Would it then help if the user filled the entire disk (after having encrypted it) by writing /dev/zero to some arbitrary file in the file system, then deleted the file to recover the 'used' space? Wouldn't this remove any stray null bytes on the device and replace everything with just encrypted data?

That would be good to do, yes. It is not perfect, because there will still be areas of the filesystem that will not be wiped even if it is filled. For example, the non-root user cannot overwrite the last 5% of space on an ext4 filesystem by default. And no user can overwrite certain metadata fields which may not be initialized when the filesystem is created, and left as null bytes. You would have to look into the on-disk format and formatting techniques used by your particular filesystem to understand what fields may not be initialized and may leak sensitive information. Since this is often such a complex task, it's generally easier to just start out with a randomized block device.

A very helpful post for understanding the issue with leaving some data unencrypted is here. The post is specifically about TRIM on SSDs, but the effect is the same, as TRIM zeros blocks which are freed, leaking information on what blocks are free and what are not. This may also answer your question about how this applies to SSDs.