I often see two questions related to free (a.k.a. “unallocated”) disk space when people talk about Windows BitLocker™ Drive Encryption on various forums:
Q: What happens to unallocated space when I enable BitLocker on my volume? Does it get encrypted?
Q: I enabled BitLocker on my volume and – poof! – all my free space is gone! What’s wrong? More importantly, how do I get it back?
Good news: nothing is wrong and the only thing that you have to do to get it back is wait. Here’s a high level explanation (some intricate technical details have been omitted for brevity).
In the IT world “delete” usually means “remove from plain view” rather than “obliterate out of existence”. Unallocated disk space is prone to contain interesting data: rotting skeletons of compensation spreadsheets, “deleted” text files with passwords and credit card numbers, discarded autosave copies of top secret presentations. Hence, BitLocker cannot just ignore free space when the volume is being encrypted.
On the other hand, encrypting (or, to be exact, “reading, encrypting, and writing back”) free space is a real waste on a typical volume that is usually less than twenty percent full. As a performance optimization, BitLocker simply overwrites unallocated space with noise, thereby avoiding redundant reads. As expected, wiping free space is about two times faster than encrypting data, but it still takes considerable time on large volumes.
Now, free space tends to be very fluid. Unallocated chunks of disk space appear and disappear all over the place, all the time. Determining whether a given sector needs to be encrypted or wiped at a particular moment of time is a considerable technical challenge. BitLocker solves this problem by creating a huge file that takes most of the available disk space (leaving 6 GB for short-term system needs) and wiping disk sectors that belong to the file. Everything else (including ~6 GB of free space not occupied by the wipe file) is encrypted. When encryption of the volume is paused or completed, the wipe file is deleted and the amount of available free space reverts to normal.
(Note: if you have a Beta 2 build, you may have noticed that volume conversion leaves only 2 GB of free space, not 6 GB as described here. Increasing the amount of free space available during conversion from 2 GB to 6 GB was a recent change that is aimed to avoid ‘disk full’ errors in some common scenarios, such as installation of large software packages or writing a full memory dump on systems with 2+ GB of RAM.)
When BitLocker is turned off and the volume is decrypted, the wipe file is created in a similar way, and everything except the wipe file is decrypted. There is no need to decrypt sectors that are occupied by the wipe file, since no useful data is contained therein. Wiping unallocated space is not necessary either, as the whole volume is reverted to clear text anyway. As such, sectors occupied by the wipe file are skipped during decryption; consequently, decryption of a volume is typically much faster than encryption. As in the case of encryption, the wipe file is deleted when decryption is paused or completed.
And finally, a bit of trivia: the noise that is used to overwrite free space is generated by encrypting a buffer filled with 0x57 (‘W’ in ASCII code). So, if you ever opened an encrypted volume in a disk viewer and wondered what those vast spaces filled with W’s are – that’s most probably unallocated space that has been wiped during encryption.