A Worthy Successor to TrueCrypt
In a post written in August 2014, I observed that recent actions by TrueCrypt’s developers had inspired worry that TrueCrypt might not reliably encrypt hard disk drives (HDDs). It seemed that DiskCryptor might provide a workable alternative. Unfortunately, as I concluded in a later post, DiskCryptor was still showing definite signs of immaturity. Until someone new decided to move the TrueCrypt project forward, it seemed best to stick with good old TrueCrypt 7.1a.
Fortunately, a year later, someone had taken up the TrueCrypt mantle. Using a description echoed by others, Wikipedia described VeraCrypt as a “fork” of TrueCrypt, reportedly developed in France (i.e., by people not necessarily concerned about being on a U.S. National Security Agency watchlist). As of this writing in October 2015, CipherShed, another fork, was available only in a pre-alpha version, with a warning not to use it for any critical purpose. Other alternatives included BoxCryptor Classic and Windows Bitlocker.
According to VeraCrypt’s FAQs page, as of the latest stable release (i.e., VeraCrypt 1.14), VeraCrypt fixed many of the security issues identified on the extensive security audit of TrueCrypt. That audit found a total of eleven security issues. According to Matthew Green, TrueCrypt “appears to be a relatively well-designed piece of crypto software” with “a few glitches . . . that could, in the right circumstances, cause Truecrypt to give less assurance than we’d like.” Michael Mimoso characterized TrueCrypt as having been very extensively analyzed over an extended period by numerous reviewers.
Potential Problems with VeraCrypt
Wikipedia nonetheless identified several potential vulnerabilities:
- VeraCrypt keys could be recovered from RAM if the machine continued to be powered up or in sleep mode after closing VeraCrypt.
- Attackers with physical access to the machine could install keyloggers and other hardware or software that could capture passwords and unencrypted data.
- Keyloggers and other malware could already be in place before VeraCrypt was installed.
VeraCrypt’s webpage reported no confirmed issues but a number of known limitations. The main limitations applicable to Windows 7 and 8 (and presumably 10) appeared to be roughly as follows:
- VeraCrypt does not support encrypting a system drive that has been converted to a dynamic disk.
- VeraCrypt volume passwords must consist of printable ASCII characters.
- An extended/logical partition that is within “the key scope of system encryption” cannot be mounted without pre-boot authentication. The quoted phrase refers to system partitions encrypted by VeraCrypt and non-system partitions located on a system drive encrypted by VeraCrypt, mounted when the encrypted operating system is running.
- Windows Volume Shadow Copy Service is supported only for partitions within the key scope of system encryption.
- Windows boot settings cannot be changed from within a hidden operating system if the system does not boot from the partition on which it is installed.
- Encrypted partitions cannot be resized except partitions on an entirely encrypted system drive that are resized while the encrypted operating system is running.
- The Windows installation on an encrypted system partition cannot be upgraded or repaired in the pre-boot environment (by using e.g., the Windows installation DVD) without first decrypting the system partition. This limitation does not apply to ordinary Windows Update fixes.
- System encryption is supported only on drives connected locally via ATA/SATA/eSATA/SCSI interface.
- Multi-boot configurations must remain as they were when VeraCrypt’s Volume Creation Wizard began encrypting the system partition or creating a hidden operating system, unless a running VeraCrypt-encrypted operating system is always located on drive #0. There are exceptions.
- When laptop power runs down and the machine enters power saving mode, VeraCrypt may fail to auto-dismount.
- File timestamps may not be reliably and securely preserved. It is not clear whether this limitation applies only to VeraCrypt containers and keyfiles.
- A low-level disk editor can write unencrypted data to a non-system drive hosting a mounted VeraCrypt volume and to encrypted partitions within the key scope of active system encryption.
- Read-only protection for local unencrypted filesystems and non-hidden VeraCrypt volumes, when running a hidden operating system, is not applicable to filesystems that Windows does not consider to be storage volumes (e.g., DVDs) (?).
- File-hosted VeraCrypt volumes located on floppy disks are supported, but device-hosted volumes are not.
- The maximum recommended size for a dynamic volume container file is 300GB.
- Hybrid shutdown in Windows 8 causes problems for VeraCrypt drives and should be disabled.
For me, an ordinary user just wanting to encrypt data partitions in Windows 7, none of those limitations appeared problematic. (To emphasize, there were other limitations for Windows Server, Windows XP, etc.) A search led to reports of other problems. Without further exploration, it was not clear whether those problems were with VeraCrypt or were more related to user error. I did not notice any issues that would prevent me from proceeding.
Encrypt the System Drive?
Therefore, as recommended by VeraCrypt’s developers, I downloaded the Windows version of VeraCrypt 1.14 (also available in Mac OS X and Linux versions) from the VeraCrypt download page. I attempted to use GPG4Win to verify the related PGP signature file (see tutorial), but ran into an error message whose solutions required more time than I could devote, so I said screw it and just ran the downloaded file.
The installer gave me a choice between Install and Extract. If I did not intend to encrypt the system partition (typically drive C), Extract (i.e., creating a portable version) would be a valid option. VeraCrypt’s page on System Encryption explained that encrypting drive C would protect private data copied from other drives onto drive C. Windows 7 constantly engaged in that sort of copying: creating various temp files, revising the contents of the paging (i.e., swap) file, creating a hibernation file, updating various lists of files opened, and so forth.
It would perhaps be unnecessary to worry about that sort of thing if one developed comprehensive cleanup practices (e.g., scheduling (Heidi) Eraser or some other utility to regularly delete temp files and wipe free space; not using hibernation; deleting the paging file at shutdown). Drive C might also not be much of a worry if one used encryption primarily to protect data on drives that were being shipped or stored in non-secure facilities. A computer stolen from one’s home or office by a local thief might or might not find its way to someone who would have the knowledge and inclination to explore drive C for information regarding bank accounts and other important files (e.g., lists of passwords). A search led to a GroovyPost article urging me to encrypt my system disk in order to protect my identity and my bank account, and also to avoid possible prosecution for inadvertently failing to maintain confidentiality of other information that might be on my drive (they offer the example of your employee’s Social Security number).
Against those worries, there was the possibility of doing something wrong, or of falling afoul of some later-discovered problem, and finding myself permanently locked out of my Windows installation. There also appeared to be potential for problems with drive images. I was a big believer in using Acronis True Image to keep a copy of my Windows drive, so that I could quickly restore Windows to drive C, in the event of system corruption, without having to go through a whole Windows reinstallation process. But now I found an Acronis page identifying several potential problems. Generally, it said, “Acronis Backup software may fail to back up or restore partitions or files encrypted by specialized software.” But it also said, “Acronis Backup software can always create a raw (sector-by-sector) backup of an encrypted partition when booted from Acronis Bootable Rescue Media.” In other words, it appeared there would be no problem if I booted the Acronis Rescue CD and used that to make a sector-by-sector image of drive C. The problems identified on that page appeared to arise from the option of using Acronis within a running Windows session. Note: that page also said, “If the encryption key is based on the hard drive or some hardware serial numbers, a sector-by-sector copy may not work as expected.”
That Acronis page did not appear to have been updated recently, and thus contained no reference to VeraCrypt. It did provide a link to a page about TrueCrypt, but that page did not appear to provide information on current versions of Acronis. Elsewhere, Acronis indicated that a sector-by-sector backup would be the same size as the partition being imaged; there would be no compression, not even of empty space. So I would want to install Windows 7 on a partition no larger than necessary to accommodate Windows and the programs that I might install. A 120GB partition might suffice for Windows 7; a 240GB partition would be a bad idea.
Since the Acronis webpages were not giving me reassuring news and appeared to be outdated, I took a quick look to see if perhaps some other drive imaging program would be compatible with VeraCrypt. The VeraCrypt documentation itself said that the secure way to back up an encrypted system drive was, roughly speaking, to boot the system using something like WinPE or BartPE (or connect the system drive to another computer), create a new partition of equal or greater size, and then use a program like Acronis to copy the system partition to that new partition. This seemed to be more or less what Acronis had told me: boot the system with a bootable tool like the Acronis CD and then make a sector-by-sector copy of equal size. These images would take a lot longer, and would consume a lot more space, than the compressed backups that I could make when drive C was not encrypted.
It did not seem that some drive imaging tool other than Acronis would be able to achieve anything better in this regard. A search led to several indications (by e.g., Top Ten Reviews and BackupReview), that Paragon would be perhaps the leading challenger to Acronis. A search regarding Paragon led mostly to older materials, including a 2009 discussion thread in which someone logically explained that an image of an encrypted drive would have to capture the entire drive (using e.g., Acronis’s sector-by-sector approach) because the imaging software would have no way of knowing which parts of the encrypted drive contain empty space: it would be encrypted empty space.
There was another issue. That VeraCrypt page urged me to consider using cascading ciphers (e.g., AES-Twofish-Serpent) rather than just a single encryption algorithm. That raised a question of performance. My previous post reported that, in TrueCrypt 7.1a, with a 1GB buffer, TrueCrypt’s built-in benchmarking tool indicated that encryption speed using just AES would be seven times faster than Twofish, 11.5 times faster than Serpent, and 27 times faster than Serpent-Twofish-AES. A search led to Rusen’s webpage describing his tests and presenting his findings that TrueCrypt did not affect gaming performance, and had only a slight impact on boot time, but resulted in “a huge 15% decrease in performance” in general computing (e.g., photo editing; office software) on a desktop machine, with a 30% decrease in solid state drive (SSD) performance in one configuration. This contrasted against the GroovyPost article (above), which cited Tom’s Hardware for the view that the performance impact of encryption would not be noticeable to average users. But that Tom’s Hardware article actually said,
Depending on the application or benchmark, the real-time encryption/decryption may have a noticeable impact. . . . [P]ower users will complain [about the performance impact, even on a fast machine]. . . . [M]ulti-level encryption . . . [such as AES-Serpent-Twofish brings] a performance impact that is more noticeable . . . [comparable to that of running] multiple applications with an anti-virus tool scanning the hard drive in the background.
I ran VeraCrypt’s benchmarking tool with a 1GB buffer. Its results differed somewhat from those reported above. For AES, the fastest algorithm, the mean encryption/decryption rate was 171 MB/s. For Serpent(Twofish(AES)), it was 36.4 MB/s. Hence, AES would move data at about six times the rate of AES-Twofish-Serpent. Whatever the specific numbers, the potential difference seemed substantial.
One other factor of possible concern to some users: it appeared that VeraCrypt would work only with BIOS/Legacy booting, as opposed to UEFI/GPT mode. Note also that one would probably want to prepare a VeraCrypt Rescue Disk as a safety tool if one did encrypt the system drive.
Based on the foregoing considerations, I decided not to encrypt my system drive. This decision would result in some vulnerabilities, as described above, at least until I fully implemented a program of wiping free space and otherwise minimizing the amount of unprotected data on drive C.
So I proceeded with Extract rather than the Install option in VeraCrypt’s installer. That choice called up a notice that Windows required drivers to be registered; VeraCrypt required a driver; therefore, I gathered, Windows would contain information that a sophisticated attacker could use to determine that VeraCrypt was being used. I did not know whether it would be feasible to muddy the waters by installing several encryption programs.
The Extract option put a bunch of files into a folder that I called simply VeraCrypt. I moved that folder to the Encryption folder in my customized Start Menu, which I could copy from one machine to another.
Preparing to Encrypt Data Drives
Among the several executables in the VeraCrypt folder, I ran VeraCrypt-x64.exe. This gave me a dialog quite similar to the familiar TrueCrypt dialog.
Now, what did I propose to do with it? The preceding discussion had raised a concern that would apply, not only to drive C, but to any encrypted drive: the program could fail, or I could lose my password, or for some other reason I might find myself completely locked out of my own data. Something like that had happened to me once, and that was hopefully enough to teach the lesson.
I could try making a backup of my data drive using some other encryption program. But I had chosen VeraCrypt because it was not only reliable but also secure. Using some other program could enable an attacker to gain access to data stored within that alternate format, even if s/he could not crack VeraCrypt. In addition, the alternate encryption program would have a password. Having two special passwords (i.e., one for VeraCrypt, and one for this other program) would seemingly double the risk that someone would find and use one of them, unless I chose to keep them solely in my memory. Perhaps I could have a separate password for each drive. But I had found that it was easier to remember passwords when there were not so many of them.
The best backup-backup that I had been able to imagine, at this point, involved zipping data folders into passworded .zip (or .rar, or .7z) files, and then backing up those compressed files. This would not solve the problem of multiple passwords. But it would broaden the selection of programs to use. There appeared to be several relatively secure file-zipping programs (e.g., WinRAR, 7-Zip). The zipping process would be time-consuming. It would also create a mess: reconstructing a drive from a pile of zip files would presumably require me to store, elsewhere, a list of the folders on the data drive. But at least it might protect against complete loss of data due to loss of the VeraCrypt password, or because of some unanticipated problem in VeraCrypt.
I decided not to worry about that now. For me, the project was simply to use VeraCrypt to encrypt some data drives. For example, I might encrypt a data drive inside the computer, and I might also encrypt an external backup drive. These drives could be in several different conditions or formats: brand new, or previously used but now empty, or presently containing data.
I started with a brand-new, never used drive. This was an HGST drive, so I began by letting Windows 7 configure and format it using Disk Management (i.e., diskmgmt.msc). Then I ran HGST’s extended test on it. As discussed in a previous post, I also looked at the drive with CrystalDiskInfo. (I would also have used Passmark’s DiskCheckup, but it did not seem to work with drives, like this one, that were mounted in external USB docks.) In TrueCrypt, it was possible to use a quick format option to quickly encrypt a previously unused drive. In VeraCrypt, I went into Create Volume > Encrypt a non-system partition or drive > Standard VeraCrypt volume > Select Device > Create encrypted volume and format it > Encryption Algorithm > AES > Password (no PIM) > no Quick Format (because, consistent with VeraCrypt’s advice, this new drive did not pass one of the tests in the popup dialog: it had not already been securely and fully encrypted) > Format.
There were several things to note about that sequence of choices. First, I did think about doing the Hidden VeraCrypt Volume alternative. VeraCrypt explained that this would be useful if, for example, a user was compelled to give up the VeraCrypt password. An intruder with that password would then go into the data drive, but would see only a plausibly large and generally noncritical set of files. It seemed this approach would not be suited for simple backup drives (i.e., straight-across copies of the data drive in my computer); it would fit better with a plan to rearrange files so that the critical ones were handled differently from the rest. An effort of that nature might also consider hiding one encrypted file inside another encrypted file, or inside a JPG.
In the choice of algorithms, I decided to revisit the advice given by the VeraCrypt page cited above. Was it indeed necessary to use cascading ciphers (e.g., AES-Twofish-Serpent), or was that just the advice of people so obsessed with security as to actually develop a freeware program like VeraCrypt? I found 1 2 3 discussion threads, all at least a few years old, in which the prevailing advice was to just use AES. Reasons included performance (including the availability of hardware acceleration for AES), absence of any successful breach of any of these algorithms, greater degree of testing of AES than of the others, and likelihood that problems with a popular choice like AES would be quickly noticed and fixed. As noted above, a decision to go with cascading algorithms could impose a serious performance penalty, especially on disk-based operations. I noticed, incidentally, that even KeePass used only two algorithms (AES and Twofish).
Rather than emphasize choice or sequence of algorithms, the discussions I saw recurrently emphasized making sure to use a very strong password. The standard advice was, more or less, to make the password at least eight (or twelve) characters long (but VeraCrypt recommended at least 20); use a unique password for each website or other application; include numbers, symbols, and upper- and lower-case letters; use random arrangements of characters, not words that can be found in a dictionary; don’t use obvious substitutions (e.g., H0use, with a zero, instead of House); and avoid often-used combinations (e.g., one uppercase, five lowercase, and three digits). But according to Yael Grauer’s article (March 2015) summarizing a recent study, online password checkers designed to test the user’s observance of these suggestions (e.g., Microsoft’s password checker as well as checkers by Apple, Dropbox, Drupal, Google, eBay, Microsoft, PayPal, Skype, Tencent QQ, Twitter, Yahoo, LastPass, 1Password, and KeePass, among others) varied dramatically in their reliability, with some giving really poor advice. Grauer said that DropBox and KeePass were the only effective ones they tested. The DropBox checker did not seem to be working at the time of this writing, but DropBox offered its own critique of various password checkers, as well as some other suggestions: several uncommon words used together; nonstandard uppercasing (e.g., aPple); creative spelling (e.g., speling); personal slang; inside jokes. InfoWorld emphasized length rather than complexity and advised users to lie in response to password reset questions (e.g., What was your mother’s maiden name?). Remembering such passwords could be difficult, but USA Today, using advice from HowToGeek, offered an explanation for how to convert “Tramps like us, Baby we were born to run” into “Tl|_|,BwwB2R,” and InfoWorld advised using a common word (e.g., Tadpole) in different ways, each tailored to the particular website or application (e.g., AmazTadpole32, 44TadpoleNow) — though presumably a brute-force attempt to crack one’s password would be vastly simplified if an attacker knew that common word.
VeraCrypt offered a page on keyfiles. The general idea seemed to be that I could use a password, or I could select or create a file that would let me in just as a password does, or I could do both. The keyfile would be a semi-physical alternative (e.g., a digital file stored on a USB flash drive) to the password. If both keyfile and password were used, the keyfile would protect the contents even if someone found or guessed the password, and the password would protect the contents even if someone got a copy of the keyfile. VeraCrypt warned users to disable VeraCrypt’s password caching option in order to prevent the cache from storing the contents of the keyfile where an intruder could find them. VeraCrypt recommended using a compressed file (e.g., MP3, JPG, ZIP) as the keyfile. Another VeraCrypt page recommended that keyfiles be at least 30 bytes long, but apparently material beyond 1MB would be disregarded. One writer indicated that KeePass would work with TrueCrypt (perhaps also VeraCrypt?) to insert keyfiles without providing information about file or path name, so as to foil even a keylogger. The problem here was that, if I lost either the password or the keyfile, I would apparently be unable to gain access to the data. Not to say that a keyfile would be overkill in every case, but a strong password seemed sufficient for individual if not enterprise usage.
For reasons discussed above (notably performance and the question of what one will definitely remember), after reading the VeraCrypt documentation, I decided not to vary the PIM value.
Encrypting Data Drives
With those settings sorted out, the Format process took about two hours for an empty 1TB HDD. Meanwhile, I had another drive, mounted in another external USB dock. Unlike the first one, this drive was not empty. It, too, had not been previously formatted by TrueCrypt or VeraCrypt. The files on it were of no importance to me, but I wondered whether VeraCrypt would treat it much differently from the first drive, if I told VeraCrypt to preserve those preexisting files. (I tested this drive, too, using HGST diagnostics and CrystalDiskInfo.)
I noticed that VeraCrypt took a while before moving on to the next step, each time I entered a password. I assumed this was because it was taking more secure steps with that password than TrueCrypt had done.
I wondered if VeraCrypt would permit multiple sessions of its Volume Creation Wizard. Back in the main VeraCrypt dialog, I clicked Create Volume, while the other drive was still being formatted. A new Volume Creation Wizard dialog opened up, so I went with it. It offered me some options that differed from those described above. One difference was that, for this disk, I chose “Encrypt partition in place” instead of “Create encrypted volume and format it.” I wondered whether the existence of a smallish amount of data (about 65GB on a 1TB drive) would significantly slow the process, or whether instead VeraCrypt would cruise right through the unused space on that drive. VeraCrypt also gave me a choice of Wipe Mode. I assumed it was planning to wipe the empty space, so as to delete possibly recoverable traces of previously deleted files. But this was a new drive; the files that I had added to it were the only files that had ever been on it, so there was presumably nothing to wipe. So I chose None for the Wipe Mode. After I clicked the Encrypt button, VeraCrypt estimated that this process would take 14 hours. Would that estimate change, once it got past that 65GB worth of material? I gave it nearly three hours (starting at 3:30 PM), saw that it was 20% done and was estimating 11 hours to finish, and decided to cancel. The Defer button was the only option for that purpose. I went with that, and then went into Create Volume > “No, do not prompt me” (about resuming the previous encryption) and started over with the faster “Create encrypted volume and format it” option described above. The conclusion here was that the “Encrypt partition in place” alternative was going to be much slower and would take the same amount of time regardless of the amount of data on the drive.
By this point, a few hours down the line, the first drive was done. The only remaining VeraCrypt task for that drive was to go into VeraCrypt’s Select Device and choose that drive, and then go into Volume Tools > Backup Volume Header. As the name suggests, that option’s purpose was to make a copy of the key data (i.e., the volume header) on the VeraCrypt drive. VeraCrypt (and for similar functionality in TrueCrypt, Wikipedia) explained that this backup would help to recover the drive’s data after some forms of drive corruption. I could have done this later, but now it was taken care of. Then I mounted the drive. To do that, I went into VeraCrypt > select the drive letter that I wanted the drive to use (e.g., D:) > Select Device > highlight the drive that I wanted to mount (i.e., the line containing the details, e.g., \Device\Harddisk0\Partition 1) > Mount > enter password. Now I was able to start putting data on the drive. I would be taking similar steps with other drives as VeraCrypt finished preparing them.
Drive Corruption Problems
An odd thing happened when I attempted to encrypt another brand-new drive: I got an error message. I finished the part of the encryption process where VeraCrypt told me to move my mouse randomly within the window; I clicked Format; and then I got this:
VeraCrypt Volume Creation Wizard
The system cannot find the file specified.
When I clicked OK in that dialog, I got “Failed to create volume \Device\Harddisk3\Partition1.”
A search for that error message led me to understand that perhaps what VeraCrypt meant was that it unable to find the drive. It had found it, in a sense: back in the Volume Location window, when I clicked Select Device, I saw something like this:
In other words, VeraCrypt had erroneously listed Harddisk3, the separate HDD that I was trying to encrypt, as though it were a volume within Harddisk2. (Harddisk2 was a separate, currently mounted VeraCrypt-encrypted drive.)
I had probably caused this: I had dismounted and powered down the hard drive that was previously sitting in that external USB drive dock, and replaced it with this new drive that I was trying to format. This would not have been a problem in TrueCrypt — I had done such things many times — but VeraCrypt had somehow failed to prepare itself for the entry of a new drive in that external dock. Unfortunately, closing and restarting VeraCrypt did not solve the problem; Harddisk3 continued to be listed under Harddisk2. I had used the same drive letters for the previous drive that I was now trying to use for this new Harddisk3. But that didn’t seem to matter: trying to mount the new drive on a different drive letter didn’t significantly change the listing shown above.
Looking at the drive in Windows Disk Management, I saw that there was now a 1MB unallocated space at the beginning of the drive. That was newly caused by VeraCrypt; it had not been there just a few minutes before. The rest of the drive continued to be displayed as a 931.51GB RAW partition with drive letter T. In Disk Management, I right-clicked on drive T and chose Delete Volume. This produced an error: “The system cannot find the file specified.” I tried MiniTool Partition Wizard. It did not see that 1MB unallocated space. It deleted drive T without a problem. After a refresh, Disk Management now reported that Disk 3 was Not Initialized. An attempt to right-click on the left panel of Disk 3 in Disk Management, and choose Initialize Disk, produced an error: “Virtual Disk Manager. The system cannot find the file specified.”
It seemed that I might be experiencing a Windows problem, or a hardware problem, rather than a VeraCrypt problem. I was not sure. As I was working through the steps described in the preceding paragraph, I suddenly got a notice that the other VeraCrypt drive, mounted in another external USB dock, had been suddenly dismounted. I hadn’t dismounted it. The cable was still connected. This particular computer had done that before, with TrueCrypt volumes. On those occasions, I had assumed that it was because I had bumped the USB cable or something. But I was pretty sure I had not bumped the cable this time. Sometimes this computer, or this Windows installation, also had problems recognizing some other USB devices. A short time earlier, I had found that it was not now recognizing a voice recorder connected by USB cable.
I tried a cold reboot — consisting, in the case of this laptop, of shutting the machine down, unplugging the AC power supply, removing the battery, and letting it sit for a while (in this case, about ten minutes). Now the situation was worse. Never mind the drive I was trying to encrypt; I had problems with the one that I had already encrypted, that I had been trying to fill with data when I got that message indicating that it had been abruptly dismounted. Now, when I tried to mount that drive in VeraCrypt, I got this message:
Operation failed due to one or more of the following:
– Incorrect password.
– Incorrect Volume PIM number.
– Incorrect PRF (hash).
– Not a valid volume.
I tried it again. I made sure I was entering the right password. I got the message again. So the password wasn’t the problem. I hadn’t changed the PIM number. I didn’t know what the PRF was. It seemed I might have an invalid volume. I tried once more, again making sure to enter the right password, and once more got the same result. I tried again, this time clicking Mount Options and checking the box for “Use backup header embedded in volume if available.” No luck: same result. Unfortunately, I had forgotten to make a backup header for this drive. It seemed I would have to start over at the point of re-encrypting the drive.
Now, why had this happened? As I say, this computer had previously seemed to dismount TrueCrypt drives. But maybe I was wrong about that. Maybe those previous dismounts had been due to a bug in TrueCrypt. After all, the computer did not seem to be randomly dismounting other USB devices, though granted I did not tend to leave them connected for hours at a time; maybe those, too, would have been disconnected eventually.
Regardless of whether those previous dismounts were due to the computer or TrueCrypt, in my experience of working with TrueCrypt (going back a few years at this point), I didn’t recall any case where the disk was corrupted as a result. But now it had happened with one of the first drives I had ever tried to use with VeraCrypt. There did seem to be something inferior about VeraCrypt in this regard.
I didn’t think the problem was that I was using VeraCrypt to handle two separate hard drives in separate external USB docks simultaneously. I had done that many times with TrueCrypt. Most likely, I felt, the problem traced back to the point where VeraCrypt was erroneously showing Harddisk3 as a volume within Harddisk2 (above). I didn’t know why that had happened. I also didn’t know whether the damage was already done at that point, or whether I might have avoided trouble by bailing out of VeraCrypt immediately, as soon as I saw that erroneous listing, rather than try to forge ahead with Harddisk3.
While I was re-encrypting that drive, I tried to mount one of the other drives I had recently encrypted, in the other external USB dock. It did show up as its own item — as Harddisk 3, not a part of Harddisk 2 — in VeraCrypt’s Select a Partition or Device dialog. Yet this one, too, produced the Operation Failed error message (above). When I tried to look at this drive in Windows Disk Management, I got the reminder, “You must initialize a disk before Logical Disk Manager can access it.” Had I not already done this? Possibly, with the stack of three disks and the passage of a couple of days, doing this amidst other tasks and interruptions, I had thought I had taken all of the required steps, and perhaps I hadn’t. So now I started over on this one too, with HGST diagnostics and CrystalDiskInfo, and then encryption via VeraCrypt. That all worked, and I had no further problems with that drive. So I really wasn’t sure what went wrong there.
Reading a TrueCrypt Drive
I had a drive that I had encrypted using TrueCrypt 7.1a. Now I put that drive into an external USB dock and tried to mount it in VeraCrypt, taking the same steps that I would have used in TrueCrypt. I made sure I was using the right password. The attempt was unsuccessful. VeraCrypt gave me the Operation Failed error message shown above. It did not seem that this was supposed to be the outcome: the VeraCrypt FAQs page said, “Starting from version 1.0f, VeraCrypt supports mounting TrueCrypt volumes.” I tried with TrueCrypt, and had no problem: using the same password, the volume mounted immediately. I tried again, with that same drive and also with another TrueCrypt drive, this time mounted internally in a desktop machine. Once again, VeraCrypt would not mount these drives, but TrueCrypt would.
I was concerned that possibly VeraCrypt had gone off the deep end again, so I tried again to mount one of the drives that I had just mounted and unmounted in VeraCrypt, using a different external USB dock. That worked OK. So VeraCrypt wasn’t on the blink; it was just not interested in working with that TrueCrypt drive.
To see whether others had had this problem, I did a search. That led to a page in the VeraCrypt documentation. It said that I had to check “TrueCrypt Mode” in VeraCrypt’s password prompt dialog. That worked. So the problem was a simple oversight on my part.
Drive Corruption Again
The preceding sections describe the problems that I encountered when I was first trying to use VeraCrypt. At this point, I used VeraCrypt for several weeks. Then, one day, I received, again, the error message discussed above, to which I had found no solution other than wiping the drive and starting over:
VeraCrypt Volume Creation Wizard
The system cannot find the file specified.
When I clicked OK, I received another message:
VeraCrypt Volume Creation Wizard
Failed to create volume \Device\Harddisk3\Partition 2
A search yielded no explanations of this error. A broader search led to a Wilders Security Forums discussion where someone received a somewhat similar error in TrueCrypt. That discussion did not seem directly relevant, but it made me wonder whether my recent steps with this drive could have produced the problem.
Recently, I had done this: (1) Encrypt the drive using VeraCrypt, with the drive in an external USB dock connected to a different machine. (2) Disconnect the drive from that machine and connect it to my main machine using another external USB dock. (3) Reformat the drive using Windows Disk Management (diskmgmt.msc) because I had forgotten: I wanted this new drive to have no drive letter, and in the previous setup it did have a drive letter. (4) Go through the encryption steps in VeraCrypt, and observe that encryption did seem to commence. (5) Get the error message (above) after a few minutes of apparent encryption.
In case those steps had caused the problem, I decided it might make sense to start over from scratch. Using a partitioning program (I chose MiniTool Partition Wizard), I deleted all partitions on that drive. (It was a 3TB GPT (not MBR) drive.) Something (I think Windows Disk Management) had put a small 128MB partition at the start of the drive; I deleted that too. Then, in Partition Wizard, I created a single primary partition spanning the entire drive (which was what I had wanted previously) — with, again, no drive letter. Partition Wizard did not re-add that extra 128MB partition.
Then I tried again in VeraCrypt. I went through all the introductory steps to create the VeraCrypt volume, until I got to the Encryption Options step. I used the defaults (AES and SHA-512) and clicked Next. This gave me a new error:
VeraCrypt Volume Creation Wizard
The device is not ready.
I clicked OK. That gave me another message:
VeraCrypt Volume Creation Wizard
If you are accessing a drive for removable media, please make sure that a medium is inserted in the drive. The drive/medium may also be damaged (there may be a physical defect on it) or a cable may be damaged/disconnected.
I wondered whether that error was due to the absence of that leading 128MB partition (above). In Windows Disk Management, I right-clicked to delete the existing volume and then right-clicked again to create a new one. Although that process did not appear to have created a new leading 128MB partition, this time VeraCrypt did at least begin to encrypt. But then, within a minute or two, it put me back at the same 2678 error quoted at the start of this post.
I wondered if maybe my VeraCrypt installation was defective. I had been using VeraCrypt 1.14 (64-bit). At this point, the latest stable release was 1.16. I exited VeraCrypt, downloaded version 1.16, and (as before) used the Extract rather than Upgrade or Install option, so as to create VeraCrypt Portable. I had to reboot the system to run the new version. Before rebooting — having learned from the previous go-round — I went into VeraCrypt > Volume Tools > Backup Volume Header, so as to make a backup header for each of my mounted partitions. Unfortunately, this effort failed with the following error:
Operation failed due to one or more of the following:
– Incorrect password.
– Incorrect Volume PIM number.
– Incorrect PRF (hash).
– Not a valid volume.
I got the same thing on two other mounted VeraCrypt partitions. I tried right-clicking on those volumes and using Repair Filesystem, but that process reported no problems, and the attempt to back up the header still failed.
I wrote the foregoing materials in mid-October 2015. I returned to finish this post at the end of November 2015. I had been using VeraCrypt almost exclusively during the intervening weeks. In doing so, I had encountered no problems. Somehow I had gotten past the problems I had previously experienced in creating backup headers: I was now able to make backups for both internal and external drives. I was not sure whether all of the previous problems had accrued while connecting an external USB dock to the problematic laptop; since then, I had been using VeraCrypt mostly on the desktop. VeraCrypt seemed stable.