Operation Manual

99
have various security implications. For instance, data that is to be encrypted in place may remain
unencrypted in the bad sector. Likewise, data to be erased (for example, during the process of
creation of a hidden operating system) may remain in the bad sector. Plausible deniability (see
section Plausible Deniability) may be adversely affected whenever a sector is reallocated.
Additional examples of possible security implications are listed in the section Security
Requirements and Precautions. Please note that this list is not exhaustive (these are just
examples). Also note that VeraCrypt cannot prevent any security issues related to or caused by
reallocated sectors. To find out the number of reallocated sectors on a hard drive, you can use e.g.
a third-party software tool for reading so-called S.M.A.R.T. data.
Defragmenting
When you (or the operating system) defragment the file system in which a file-hosted VeraCrypt
container is stored, a copy of the VeraCrypt container (or of its fragment) may remain in the free
space on the host volume (in the defragmented file system). This may have various security
implications. For example, if you change the volume password/keyfile(s) afterwards, and an
adversary finds the old copy or fragment (the old header) of the VeraCrypt volume, he might use it
to mount the volume using an old compromised password (and/or using compromised keyfiles that
were necessary to mount the volume before the volume header was re-encrypted). To prevent this
and other possible security issues (such as those mentioned in the section Volume Clones), do one
of the following:
 Use a partition/device-hosted VeraCrypt volume instead of file-hosted.
 Securely erase free space on the host volume (in the defragmented file system) after
defragmenting.
 Do not defragment file systems in which you store VeraCrypt volumes.
Journaling File Systems
When a file-hosted VeraCrypt container is stored in a journaling file system (such as NTFS), a copy
of the VeraCrypt container (or of its fragment) may remain in the free space on the host volume.
This may have various security implications. For example, if you change the volume
password/keyfile(s) and an adversary finds the old copy or fragment (the old header) of the
VeraCrypt volume, he might use it to mount the volume using an old compromised password
(and/or using compromised keyfiles using an old compromised password (and/or using
compromised keyfiles that were necessary to mount the volume before the volume header was re-
encrypted). Some journaling file systems also internally record file access times and other
potentially sensitive information. If you need plausible deniability (see section Plausible
Deniability), you must not store file-hosted VeraCrypt containers in journaling file systems. To
prevent possible security issues related to journaling file systems, do one the following:
 Use a partition/device-hosted VeraCrypt volume instead of file-hosted.
 Store the container in a non-journaling file system (for example, FAT32).