Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
1  
Whether the disk is SSD vs spinner can matter. The discussion on your other question is relevant. –  Jonathan Garber Jan 25 '13 at 14:28
add comment

migrated from crypto.stackexchange.com Jan 25 '13 at 6:49

This question came from our site for software developers, mathematicians and others interested in cryptography.

2 Answers

up vote 1 down vote accepted

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.

share|improve this answer
add comment

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).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.