When decrypting EFS files in a case, you receive the result shown in the exhibit. What is the most plausible explanation for this result?

Question

Options

• AThe encrypted file was corrupt.
• BA different user encrypted the remaining encrypted file.
• CThe hash value of the remaining encrypted file did not match.
• DThe remaining encrypted file had previously been bookmarked.
• EAn incorrect CRC value for the $EFS certificate was applied by the user.

• A
  9% (5)
• B
  56% (32)
• C
  7% (4)
• D
  25% (14)
• E
  4% (2)

Explanation

Option B is correct because EFS (Encrypting File System) ties encryption to a specific user's certificate and private key. When decrypting a batch of EFS files, if some files were encrypted by a different user account than the one whose certificate you're using, those files will fail to decrypt - producing the mixed result shown in the exhibit. You can only decrypt EFS files encrypted with the private key you possess.

Why the distractors are wrong:

• A (corrupt file): Corruption would produce an error specific to that file's integrity, not a clean decryption failure pattern tied to ownership.
• C (hash mismatch): A hash mismatch indicates file tampering or integrity failure, a separate issue entirely from EFS key ownership.
• D (bookmarked file): Bookmarks are a forensic tool artifact; they have no effect on cryptographic decryption operations.
• E (incorrect CRC on $EFS): The $EFS alternate data stream holds EFS metadata, and a bad CRC would suggest corruption - but this is a far less common and less plausible explanation than a simple key mismatch.

Memory tip: Think of EFS as a personal padlock - each user has a unique key. If someone else locked a file, your key simply won't fit, regardless of your access level. When decryption partially fails in a case, always ask: "Whose key am I holding?"

No community discussion yet for this question.