Filling the disk with random data prior to encryption?

Question

Filling the disk with random data prior to encrypting it will supposedly make it harder for the attacker to perform any cryptanalysis. Most sources seem to state this is because it will be harder for the attacker to determine what data is actually encrypted (and which is just random garbage).

However, is this strictly necessary? It can take a prohibitively long time to fill the entire disk with random data, for large disks. If the data could be attacked and decrypted with any form of attack, then how much is this extra hurdle really worth? What is the real concern and attack scenario where this sort of prevention technique is actually any useful?

Has any encrypted data ever been decrypted because the owner failed to fill the disk with random data prior to encrypting it? Or is this practice just an overly paranoid extra measure that in reality provides no real additional security?

If needed to provide any specific answer, then assume the system is GNU/Linux with LUKS, AES 256 bit, having encrypted data on a normal HDD. Two partitions: One /boot partition with no encryption only used for booting and one root partition with said encryption.

Attack scenario: The attacker obtains the computer with the power turned off. Assuming no cold boot attack or evil maid attack is possible.

Answer 1

There are a few reasons why this is necessary. First, as you stated, it makes cryptanalysis of the data difficult due to being unable to identify the boundary between ciphertext and background noise. This could be defeated by capturing two snapshots of the volume and identifying the locations that change, so it's hardly a concrete security measure in this sense. This issue actually brings us onto a more important one - file systems don't evenly spread their data around on the disk, and often leaves remnant data hanging around.

This is where the background randomness is important. If an attacker can identify old blocks of ciphertext, e.g. from a file whose data was recently updated, he now has access to two versions of ciphertext using the same key (and likely the same IV, too) for two different plaintexts. This can lead to certain attack scenarios becoming more feasible, e.g. differential cryptanalysis. The background randomness makes identifying latent blocks of ciphertext exceedingly difficult.

Another case where background random data is mandatory is when deniability is required, such as TrueCrypt's hidden volumes feature. If an attacker can see that the volume spans over 10GB, but the volume only shows as 4GB when mounted, he can tell that there is a 6GB hidden volume too. By making the entire disk's data completely random, the ciphertext becomes indistinguishable from that background data, making identification of the hidden volume difficult if not impossible.

Answer 2

A couple things worth mentioning here. First, this would only make a difference for full disk encryption. If the file allocation table (or other index) is not encrypted, it would be trivial for an attacker to detect where the boundaries of the files are.

The second issue would be a static analysis of a highly sensitive drive. Certain information would leak by being able to tell a) how much data is on the drive and b) the allocation of information on the drive might give away some information about the level of use and/or file sizes.

Third is the situation that Polynomial mentioned where remnants of files would be left on the drive and could be useful for differential analysis or simply leak information about what has changed recently.

Practically speaking, is this information useful, for the first two, probably not in most cases, but the differential analysis is a more practical threat that could result in data recovery. Really anything that reduces entropy makes the encryption weaker though, so having a random background is more secure overall.