Is it possible to tell if a hard drive is encrypted, regardless of what software was used, i.e., Truecrypt / VeraCrypt / Bitlocker for AES-256?

Just the other day, I thought it could be possible to tell if I scan the drive with "Sector View" to read the data. If the data is filled with randomness then that means that it is encrypted. Is it that easy to tell?

  • 2
    If you can retrieve readable data without a decryption key then it's not encrypted. – immibis Sep 4 '16 at 12:15
  • 26
    "If the data is filled with randomness then that means that it is encrypted" Of course... it could just be random data. – NPSF3000 Sep 4 '16 at 15:33
  • If you can record and compare hard drive activity, between one you know is not and one you suspect to be you would notice that one of them is much less performant on data read and perform a lot of read .. while some hardware are optimized for encryption, most of them suffer a performance loss. And there are volume header or apparent total empty or full or unknown volume type. – happy Sep 5 '16 at 1:23
  • 7
    In the vast majority of encryption algorithms, it is very easily to identify the data, because it is in the header. Encryption is not the process of HIDING data, that is called Steganography. So in practice, you just search for key signatures... – Aron Sep 5 '16 at 6:52
  • 1
    @NPSF3000 if the NSA ever investigates me, I'm going to hide a bunch of hard drives with random data on them around my house, just to mess with their heads. – PyRulez Sep 6 '16 at 0:53

We have two types of encryption here, "file based encryption" and "full disk encryption". There are documented forensics methods and software (e.g. EnCase) that help us detect the schemes and programs used to encrypt the disk.

I'm going to take a list of popular tools and standards and see if they leave any traces with which we can determine that they've been used:

  • Bitlocker
    Bitlocker is a full disk encryption standard available on windows operating system from Windows 7 onwards; this tool uses AES256 to encrypt the disk. A disk encrypted by bitlocker is different than a normal NTFS disk. The signature of "-FVE-FS-" can be found at the beginning of bitlocker encrypted volumes.
    These volumes can also be identified by a GUID:
    • for BitLocker: 4967d63b-2e29-4ad8-8399-f6a339e3d00
    • for BitLocker ToGo: 4967d63b-2e29-4ad8-8399-f6a339e3d01
  • DiskCryptor/TrueCrypt/VeraCrypt
    DiskCryptor is based on TrueCrypt. For both DiskCryptor and TrueCrypt we can detect their presence with the following criteria:
    • size of file or collection of clusters object is a multiple of 512,
    • minimum size of object is 19KB, although by default is minimum 5MB,
    • contains no specific file signature throughout the entire object, and
    • has a high Shannon entropy or passes Chi-squared distribution test. Note that since there's no specific signature or header left behind we can't tell for sure if TrueCrypt (or its siblings) were used, by combination of several methods we can try to make better guess about its presence.
  • FileVault
    Filevault is Bitlocker's equivalent on Mac and offers full disk encryption. The signature of "encrdsa" or hex value of "65 6E 63 72 63 64 73 61" can be found at the beginning of FileVault encrypted volumes.
  • cryptsetup with LUKS
    Linux Unified Key Setup is a disk encryption specification and can be used in cryptsetup on Linux which is a common tool for storage media volumes encryption. It is optional and users can choose not to use this format but if used we can detect its presence with "LUKS\xba\xbe" signature at the beginning of the volumes.
  • Check Point Full Disk Encryption
    At sector offset 90 of the VBR, the product identifier "Protect" can be found. Hex value "50 72 6F 74 65 63 74"
  • GuardianEdge Encryption Plus/Anywhere/Hard Disk Encryption and Symantec Endpoint Encryption
    At sector offset 6 MBR, the product identifier "PCGM" can be found. Hex value "50 43 47 4D"
  • McAfee Safeboot/Endpoint Encryption
    At sector offset 3 MBR, the product identifier "Safeboot" can be found. Hex value "53 61 66 65 42 6F 6F 74"
  • Sophos Safeguard Enterprise and Safeguard Easy
    For Safeguard Enterprise, at sector offset 119 of the MBR, the product identifier "SGM400" can be found. Hex value "53 47 4D 34 30 30 3A"
  • Symantec PGP Whole disk Encryption
    At sector offset 3 MBR, the product identifier "ëH|PGPGUARD" can be found. Hex value "EB 48 90 50 47 50 47 55 41 52 44"

Measuring File Randomness To Detect Encryption

Methods discussed earlier may not be feasible for every disk/file encryption scheme since not all of them have specific properties that we can exploit to detect them. One other method is to measure the randomness of files and the closer they are to random, the more certain we are that encryption is used.
To do this we can use a Python script named file_entropy.py. The closer the entropy value is to 8.0, the higher the entropy.
We can extend this further and draw plots to visualize the distribution of bytes. (calculate-file-entropy)

One other pointer to detect encryption is that no known file signature will be spotted in the volume. (No jpg, no office documents, no known file types) And since compression methods (e.g. gzip, rar and zip) have known signatures we can differentiate them from encryption for the most part.

Sum up

  1. Use known signatures to detect encryption (if possible)
  2. Use special characteristics (minimum file size, high entropy, absence of any special file signature, etc.) to detect encryption
  3. Rule out compressed files using their signature

So going back to the main question, "Is it that easy to tell?", this falls under forensics methods, we may be dealing with steganography techniques. In a normal case where user isn't trying to fool us, it is somehow easy to tell encryption is in place but in real world scenarios where user's may try to hide things and deceive us they may just pipe /dev/urandom to a file! It's not gonna be easy.

  • 4
    Is it for certain that we can detect TrueCrypt encryption by following the above criteria or it is just a better guess? – cpx Sep 4 '16 at 8:49
  • 6
    You don't calculate the entropy of the file. Shannon entropy is defined for probability distributions and not for fixed pieces of data. You assume that the bytes in the file are independently drawn from a probability distribution. You then use the frequency of each possible byte value to approximate this probability distribution. Finally you compute the entropy of this probability distribution. – CodesInChaos Sep 4 '16 at 9:58
  • 8
    @Silverfox That misuse is common, even among cryptographers. The bigger problem is that you only look at biases in the bytewise histogram and ignore all patterns that extend across multiple bytes. For example you'd give the sequence 0 to 255 repeated a perfect score, despite being a super obvious pattern. In theory there is Kolmogorov complexity which is defined for individual files, but it's completely unusable in practice. In practice the best we have are test suites like die harder – CodesInChaos Sep 4 '16 at 10:05
  • 4
    You can pass -c and -h to cryptsetup and use it without LUKS. Therefore cryptsetup is not exactly the same as LUKS. here is an example of a question on U&L by someone who uses cryptsetup without LUKS. And yes, cryptsetup without LUKS has no signature (that was OPs problem there) – grochmal Sep 4 '16 at 12:44
  • 2
    So basically, you "detect encryption" by using statistical methods to detect randomness. So if I filled a hard-drive with random garbage, it would be detected as "encrypted" using this method. I think that gives the user a fair repudiation :) – BlueRaja - Danny Pflughoeft Sep 4 '16 at 16:57

While you can't tell for certain, you can tell within a certain range of confidence.

Encrypted data looks like white noise: each bit has exactly a 50% probability of being set, regardless of the rest of the bits; there is no correlation between any given bit and any of the others. It's purely random.

It turns out that this high quality of randomness isn't particularly common in a hard drive's normal lifecycle. In general there's some pattern or another. Either a residual pattern from the manufacturing process, or a pattern from the filesystem setup, or a pattern from current or previously-deleted files. So if a disk contains pure white noise, then the most likely explanation is that either someone did a "secure erase" on the drive, or it contains encrypted information.

As an exception, one common unencrypted form of data that often looks a lot like noise is compressed data. The higher the compression ratio, the more it will resemble encrypted data. Still, compressed data usually has tell-tale markers so a more careful examination can generally rule that out.

  • FWIW, White noise is ideal but their are block modes that still carry information and are therefore vulnerable to preimage attacks (ECB) – Yorick de Wid Sep 4 '16 at 8:23
  • @YorickdeWid TrueCrypt uses XTS, not ECB. If you look at a single snapshot of the disk, it should be indistinguishable from random, up to the birthday bound. I'm not aware of any disk encryption software where the actual mode of operation is distinguishable, though many have obvious headers. – CodesInChaos Sep 4 '16 at 9:50
  • @CodesInChaos So does BitLocker, but the OP doesn't specify a particular disk encryption tool. And ECB is still used – Yorick de Wid Sep 4 '16 at 9:56
  • 3
    I sort of disagree with you. The purpose of encryption isn't to HIDE information. Most encryption algorithms actively advertise its existence to the world (helps stop people accidentally deleting it). Conversely the process of hiding the data is called Steganography. – Aron Sep 5 '16 at 6:50
  • 2
    @Aron If the encryption container identifies itself then the question is moot. Yes, you can identify truecrypt files by the ".tc" file extension, but certain products offer "plausible deniability" features, allowing you to create an encryption container that has no identifying markers. This question only makes sense in that context. – tylerl Sep 5 '16 at 7:38

If the data is filled with randomness then that means that it is encrypted. Is it that easy to tell?

No. If I am going to throw out, or give away, a hard disk I would remove personal data from it by running a program like shred which replaces the contents with random data. Thus the presence of random data proves nothing.

You might then reformat that disk with some file system or other, which would make the first part of the disk look normal, and the rest random. That still doesn't prove if the random part is encrypted, or just left-over from the cleanup operation.

I'm a little surprised that most encryption products leave signatures lying around as described by Silverfox. That seems to lend the user open to brute-force decryption as described here:


  • 3
    I would think that, if you really wanted to do the work, something like dd if=/dev/urandom of=/dev/disk... would be more appropriate. Blow away the entire filesystem as well as all its metadata/journals/logs. – smitelli Sep 5 '16 at 0:01
  • 1
    I was using shred on the entire drive (eg. /dev/sda) not a partition. Shred lets you do multiple passes. You can finish up with a pass of zeroes if you want. I understand the issues with an SSD, but the question was about a hard drive. – Nick Gammon Sep 5 '16 at 5:04
  • 3
    I'm a little surprised that most encryption products leave signatures lying around - Cleartext "headers" require extra engineering effort to avoid, and in any situation where it matters, you're probably already screwed. Customs officials, for instance, may be just as suspicious of a hard drive completely full of white noise as they would be of a hard drive with obvious disk-encryption headers. – zwol Sep 5 '16 at 14:57
  • You could be right, but I would have thought that signatures could be detected in seconds using the right tool. The lack of any obvious signature can be explained away by saying you reformatted the drive after securely wiping it (eg. because your boss told you to before travelling to another country). – Nick Gammon Sep 5 '16 at 20:46
  • 1
    We are drifting into a discussion about how to make sure people can't get at your private data (eg. the firmware not overwriting the sector you thought it was - which is certainly an interesting point). However regarding the question itself, I don't think the mere presence of what looks like random data proves there is encrypted data waiting there to be discovered. There might be. – Nick Gammon Sep 6 '16 at 23:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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