Diskcryptor error code 4

Due to concerns about the security of TrueCrypt going forward, I decided to try DiskCryptor as an alternative tool for encrypting the contents of computer drives. (As described in the separate post discussing those concerns, however, I would later decide to return to stick with TrueCrypt after all.)

After considering an experiment involving encryption of my Windows 7 program drive (C:), I opted instead to start by exploring the use of DiskCryptor on an external drive that I had been using as a data backup drive. This post describes that exploration.

The external HDD in question was a 3.5″ hard disk drive (HDD) of the type normally installed internally in desktop machines. I had inserted the drive into an external drive dock connected via USB 3.0 cable to a laptop. For purposes of this inquiry, I began by encrypting it with TrueCrypt and then placing some data on it.

Users interested in a simple how-to guide for DiskCryptor might appreciate the step-by-step screens and description provided in a PCWorld article by Eric Geier, and also the tips offered by ghacks. My objective here wasn’t to provide a how-to. It was to think about what was going on, to play with the program a bit, and thus to gain a more informed impression of how much confidence I should place in DiskCryptor.

Ways to Transition from TrueCrypt

My first question was whether I could convert that existing TrueCrypt external drive to be a DiskCryptor drive. A search did not lead to any immediately obvious ways to do that. As an alternative, I wondered whether I could leave it as a TrueCrypt drive, but work with its contents in DiskCryptor — just as, for instance, Microsoft Word could work with files created in other word processing programs, and vice versa. That, too, seemed unlikely: DiskCryptor’s homepage indicated that DiskCryptor had been fully compatible with TrueCrypt only up through DiskCryptor 0.4, and I was using DiskCryptor 1.1.

I had created that partition using the Volume Creation Wizard in TrueCrypt 7.1a. I created it as a “non-system” and “standard” (i.e., not hidden) encrypted drive. I dismounted it in TrueCrypt and went into DiskCryptor. It didn’t see the drive. It was a Samsung drive, and there was simply no Samsung drive listed. I looked for a way to refresh DiskCryptor’s list of drives. There did not appear to be a Refresh or F5 option. TrueCrypt could see it: if I mounted it, Windows Explorer would then see its contents. When I compared it, in Windows Disk Management (diskmgmt.msc), against other TrueCrypt partitions that I had mounted, I realized it was different: the others were shown as RAW, whereas this Samsung was displayed as Not Initialized and Unallocated. And yet it did have a TrueCrypt drive containing data. I wasn’t quite sure how I had achieved that. Maybe that was why DiskCryptor couldn’t see it.

The data I had placed on that TrueCrypt partition was junk; I could lose it. So I said goodbye to the TrueCrypt partition and initialized the drive in Disk Management. DiskCryptor still didn’t see it, even when I killed and restarted DiskCryptor. Was it perhaps a problem with recognition of the particular drive bay in which I had it mounted? I tried sticking it in a different bay connected to a different computer. No, DiskCryptor still didn’t see it. I started over, completely reformatting the drive, and now DiskCryptor saw it. So, OK, apparently some confusion there.

I decided to try again with a TrueCrypt-to-DiskCryptor conversion. I quick-formatted the drive in TrueCrypt, using “test” as my password. With it not mounted in TrueCrypt, I tried mounting it in DiskCryptor. No joy. With “test” as the password, I got this:

Error
Error mount volume [F:]
Error code: 4

What did that mean? The Help option in DiskCryptor’s menu gave only an About option (i.e., information about the program). A search of DiskCryptor’s website led to a couple dozen items, mostly consisting of forum posts. There didn’t seem to be anything from an official manual. Several of the forum comments suggested that error code 4 meant I was entering the wrong password. That was an odd thing: I had not created a “right” password, as far as DiskCryptor was concerned. It seemed like it should have tested, first, to see whether this was even a DiskCryptor volume. But maybe they didn’t want to give away that kind of clue to an intruder.

So again it appeared that I wasn’t going to be able to mount a TrueCrypt drive in DiskCryptor. To get my data from TrueCrypt to DiskCryptor, it seemed I would have to take some other route.

One approach would apparently involve using TrueCrypt 7.2, which (according to the TrueCrypt website, itself a source of controversy) offered an option to Permanently Decrypt a TrueCrypt partition. In other words, I would start by decrypting the TrueCrypt partition. If that partition contained data, that data would now exist in an unencrypted state on the drive. From a security perspective, this act of writing unsecured data to the drive would make it necessary, not only to re-encrypt the data (perhaps on another drive), but also to wipe this drive, so as to remove electromagnetic traces of the unencrypted data. I would soon see that DiskCryptor offered wiping options within its encryption process, thereby simplifying but also potentially lengthening that process. If I had been using a solid state drive (SSD) rather than an HDD, there would have been further complications in that wiping effort.

I did not like this TrueCrypt 7.2 option: it would require a potentially large amount of time, and an uncertain amount of computing resources, to read and write, decrypt and then recrypt, all on the same drive. And what would happen if the process had to be interrupted — if, for instance, Windows suddenly crashed, or got rebooted by some rogue program’s self-updating process, or if the external drive accidentally got disconnected, or if its power was momentarily interrupted? Moreover, the data in question would be available to intruders during any gap period between decryption and recryption — and that gap would be large if DiskCryptor was doing a thorough wipe of each sector before putting encrypted data on it. If the TrueCrypt experience was any guide, it would be much faster to encrypt the drive before rather than after putting data on it.

So the TrueCrypt 7.2 approach did not seem ideal. If my data was already stored on an encrypted drive somewhere, the better approach would seem to be the one I had generally taken with TrueCrypt 7.1a: securely wipe this target drive (before or during the DiskCryptor encryption process) if it had contained any unencrypted data since its previous wipe (or since purchase, if it had never yet been wiped); create a DiskCryptor partition on it; and then copy or move the data from that other encrypted drive to this newly encrypted partition.

At this point, I switched to experimenting on a different external drive. This was a Toshiba 3TB HDD. In Windows Disk Management (diskmgmt.msc), it was showing up as a 2794.39 GB RAW partition. This RAW format was how Disk Management typically interpreted TrueCrypt partitions. I right-clicked on the data space (i.e., not on the left side of the Disk Management display) and chose Delete Volume. Now Disk Management showed it as Unallocated. I right-clicked again, chose New Simple Volume, and went with all of the default options. Now I had New Volume, listed as drive F, an NTFS primary partition.

I copied some junk data to that new partition, and then opened DiskCryptor. It displayed my various drives and their partitions. There were no right-clicking or highlighting options for any drive. But under each drive, the available partitions were listed with their letters and their names. DiskCryptor seemed to recognize a difference between TrueCrypt encrypted partitions and non-encrypted partitions: right-clicking anywhere on the row for a TrueCrypt partition gave me the options of Format or Mount (even if the partition was already mounted in TrueCrypt); right-clicking on an unencrypted partition (such as this drive F) gave me Format or Encrypt. Drive C was an exception: it was not encrypted, but the only option available there was Encrypt. The DVD drive was another exception: its only option was Mount. I seemed to get the same options if I left-clicked on a partition, to highlight it, and then chose the Volumes option from DiskCryptor’s menu.

Benchmarking

Right-clicking on drive F, I chose the Encrypt option. This gave me an Encryption Settings dialog. Within this dialog, I could choose Algorithm and Wipe Mode. Since I was pretending to care about the junk data on the new F partition, I left Wipe Mode at the default None option: that is, I did not want that data wiped. I also left the Algorithm at the default AES option. That had been the fastest option in TrueCrypt.

But then I recalled seeing something about benchmarking. Why not find out for sure how fast DiskCryptor would be, with these various encryption algorithms? I clicked Cancel. But for some reason, that caused DiskCryptor to become nonresponsive. After getting the Not Responding message for a minute or so, I clicked on the X in the upper right corner to kill it and start over. But it did not seem to be going away. After another minute or so, I started Task Manager (Ctrl-Alt-Del in Windows 7) and saw that, yes, DiskCryptor was still listed there, and was still in a Not Responding status. I had just rebooted the machine within the previous hour, and had not been running anything unusual, so this did not seem to be a problem with some other program; it seemed that DiskCryptor itself was the problem. I clicked again on the Not Responding dialog in DiskCryptor, and now I got the Windows dialog offering to close the program. I took that option and started over.

I wondered whether that was a persistent bug in DiskCryptor, so I retraced the steps just described. This time, I did not have a problem: clicking Cancel in the Encryption Settings dialog just took me back to the main DiskCryptor window, even if I tinkered with the Down arrows in that dialog.

So now, instead of moving toward encryption, I chose the Tools > Benchmark menu pick. Clicking Benchmark in the resulting dialog yielded a momentary pause, followed by an indication that (on my machine, apparently), using AES, DiskCryptor would encrypt at a rate of 6608mb/second. That was about seven times faster than Serpent, the second-fastest option, and almost 17 times faster than AES-Twofish-Serpent, the slowest option. As someone pointed out, it was not reassuring that the DiskCryptor author(s) referred to “mb,” which could mean a variety of things, when s/he apparently meant MB, megabytes. Presumably the benchmark was saying that, at its best, on my machine, DiskCryptor would encrypt at a rate of 6.6GB/second.

I wondered how those DiskCryptor benchmarks would stack up against TrueCrypt’s benchmarks. So in TrueCrypt 7.1a, I went into Tools > Benchmark. There, I saw various Buffer Size options. At the smallest possible buffer size (100KB), it said the AES encryption speed would be 1.3GB/second, more than four times faster than Twofish, the second-fastest option; it would be about 5.5 times faster than Serpent, and nearly ten times faster than Serpent-Twofish-AES, the very slowest option. At the largest possible buffer size (1GB), TrueCrypt’s benchmark said the AES encryption speed would be 2.9GB/second: seven times faster than Twofish, 11.5 times faster than Serpent, and 27 times faster than Serpent-Twofish-AES. For both TrueCrypt and DiskCryptor, repeated benchmarking produced slightly varying results.

So if both programs’ benchmarks were accurate, and if we were indeed comparing apples to apples, it appeared that, using the AES algorithm, DiskCryptor would encrypt at more than twice the rate of TrueCrypt at its best. The difference was more pronounced when using slower and presumably more secure encryption algorithms, or combinations of algorithms. At the slow end of the scale, depending on buffer size, encryption using AES-Twofish-Serpent in DiskCryptor would be nearly ten times faster than that same kind of encryption in TrueCrypt.

Hopefully, these differences were due to various optimizations in DiskCryptor. But it was also possible that the benchmarks did not compare apples to apples — that the two programs would have performed more similarly when subjected to truly fair benchmarking. At worst, pending a thorough security review, there did remain the possibility that DiskCryptor was faster because it cut corners on encryption, with potentially disastrous data security implications.

As cautioned in the TrueCrypt benchmarking window, “Speed [of benchmarks] is affected by CPU load and storage device characteristics. These tests take place in RAM.” That is, real-world encryption rates, typically involving HDDs, would generally be very much slower than the rates just cited. As noted in a Tom’s Hardware test of TrueCrypt, the multi-level encryption options (e.g., Serpent-Twofish-AES) would not only take much longer to encrypt data; their intensive computations would also be likely to have a noticeable adverse effect on performance, especially when doing “heavy multi-tasking or when taking on intensive workloads such as video transcoding,”or when an antivirus program was attempting to scan the drive. (See also other sources.)

It seemed there might be ways to mitigate that sort of performance penalty. For instance, possibly one could combine light encryption on a temporary working drive with heavy encryption on a backup drive. If the backup drive was located on a separated synced machine that was not busy with anything else, perhaps it would more or less keep up with work in progress, without impairing performance on the machine in active use. At day’s end, after powering down or disconnecting the second machine, perhaps the working machine could be left to run sequentially more thorough wiping processes overnight.

Dry Runs

For now, I chose to encrypt my test (junk) data on New Volume (drive F), on my external Toshiba 3TB drive, using simple AES encryption. In DiskCryptor, I right-clicked that partition and chose Encrypt. I wasn’t sure whether the Wipe Mode option would wipe the data already on the drive (as distinct from wiping the place where that data had been, while encrypting it at another location on the partition), so for the moment I left Wipe Mode set to None. I entered “test” as my password, received the assurance that my password was “Trivially Breakable,” and proceeded to the actual encryption. DiskCryptor estimated that it would take about 17 hours to complete the encryption. There did not seem to be a Quick Format option comparable to the one in TrueCrypt, for those cases where the drive in question had previously been wiped and/or encrypted, as this one had.

I did not care to sit there for 17 hours, watching DiskCryptor’s informative screen. I wondered what would happen if I bailed out midway (or, actually, less than 1% of the way through). There was no Stop or Cancel button. There was an Unmount button, which I assumed could have relatively catastrophic effects upon any data surviving on the drive at this point. The Unmount button did seem willing to go all the way: when I clicked it, it said, “Confirm: Unmount volume [F:]?” I said, uh, no, I guess not. There was also a Pause button. That made the Encrypt and Decrypt buttons available; they had previously been grayed out. I wasn’t sure what they would do. On the other hand, there was no “Un-pause” or “Proceed” button; the Pause button was grayed out. I tried Encrypt. That allowed the encryption to resume where I had paused it (i.e., it did not start over at the beginning).

I noticed that these several buttons were context-specific. That is, what was grayed out would depend upon which volume I had selected. So while clicking on drive F on the list of partitions would show me how the encryption was progressing on the Toshiba drive, with grayed-out Encrypt and Decrypt buttons, clicking on another drive would switch from the Action tab to the Info tab, showing me information about that other drive, and the Encrypt button might not be grayed out.

I went back to drive F. I decided to try Unmount without first clicking Pause. It said, “This volume contains opened files. Would you like to force a unmount on this volume?” I said yes. It said, “Encryption error on volume [F:]. Error code 1.” This time, I found a list of DiskCryptor error codes. That list said that error code 1 meant “Unknown error.” I tried to look at the contents of drive F in Windows Explorer. I got two different errors:

You need to format the disk in drive F: before you can use it.

Do you want to format it?

and

Location is not available

F: is not accessible.

The volume does not contain a recognized file system.
Please make sure that all required file system drivers are loaded and that the volume is not corrupted.

These messages suggested that interrupting DiskCryptor could be dangerous to the health of your data. But then I mounted drive F in DiskCryptor. That seemed to succeed: DiskCryptor stated that it was mounted. Now Windows Explorer, listed specific files. I tried opening a couple of those files. Success!

As far as I could tell, without extensive investigation, interrupting the DiskCryptor encryption process had done no harm. It did seem that a working DiskCryptor partition had been created. I did have to enter my trivial password to enter it. The contents that had been there on the drive previously were still there, and now they were viewable only within DiskCryptor, not within Windows Explorer.

My interpretation was that maybe DiskCryptor began by encrypting the drive’s header or file allocation table or whatever it was that kept the drive organized, but that took only a few minutes, and the rest of those 17 hours would be devoted to a process of passing over each square inch of the drive, sprinkling holy water and muttering incantations. In other words, there was a possibility that DiskCryptor could be safely interrupted at any time, especially after the first few minutes, but that substantial sections of the drive might not have been properly sanctified. Data on those sections might not actually be scrambled in such a way as to elude the trained investigator. In short, it might look OK to interrupt the process, but it might not actually be OK.

In that light, I wondered what to make of advice offered by PCWorld: when using DiskCryptor, “if you need to restart or shut down, be sure to click Pause first. To resume the process, simply select the drive and click Encrypt again.” Really? And DiskCryptor would reliably remember where it left off? It was a nice feature, if it worked, but how would we know if it was leaving gaps or only doing a half-baked job?

I tried another angle: unmount the drive, format it in Windows, put some dummy data on it, fire up DiskCryptor again, try encrypting again, but this time choose a wiping method. I wanted to see whether it was already doing a wipe anyway — whether this choice would make any difference in the estimated time to complete the encryption process.

Of the three wiping methods offered by DiskCryptor, I chose the fastest, US DoD 5220.22-M (8-306. /E). (According to Sedory, software-based wiping methods, as distinct from physical degaussing, might protect against file recovery using commercially available software, but could not be trusted to protect against all possible recovery methods.)

This time, using the same setup as before except that now I had added that fast wiping method, DiskCryptor could not decide how long the process was going to take. Even after running for 12 minutes, it kept changing its estimates radically: 1:33 (i.e., one hour, 33 minutes), or 22:32, or various values in between. Based on the information appearing on the DiskCryptor screen, my own calculations at this point were as follows: by now we had wiped 15.8GB in 16 minutes 39 seconds, for a rate of about 0.95GB/minute. I repeated the calculation after an hour and a half. The rate was nearly the same, at 0.97GB/minute. At that rate, it would take about 47 hours to wipe and encrypt 2.72TB. By this point, 90 minutes out, DiskCryptor’s estimates were still all over the map, even worse than before: from 21 hours down to just a few more minutes for the entire process.

It occurred to me that maybe DiskCryptor was confused because I had initialized the 3TB drive with MBR rather than GPT partitioning. I wasn’t actually sure; I hadn’t paid any attention, when going through Disk Management’s initialization process. GPT was essential for gaining access to the full space of drives larger than 2TB. I did not know whether DiskCryptor had been designed to work with GPT. I stopped the encryption process and went into Windows > Disk Management > right-click on the drive > Properties > Volumes tab. But no, it reported that the drive had indeed been partitioned using GPT. Apparently the default settings in Disk Management had taken care of that. So that wasn’t the explanation for these wacky time estimates in DiskCryptor.

It seemed that DiskCryptor had not been programmed well enough to achieve a simple estimate of time remaining. I realized that there might have been a legitimate reason for this seeming ineptitude. It really might not have been an indicator of sloppy programming. Many people had recommended DiskCryptor. I decided to go ahead with the project. But at this point, with a few additional crashes that I haven’t mentioned, it did feel like I was working with beta software. The talk about optimizations for certain CPUs was not, I hoped, a hoax.

Maybe putting my data in DiskCryptor would ultimately prove to make it vulnerable to casual explorers. This raised the opposite question: would DiskCryptor somehow eat my data, so that I could no longer recover it? You never know. It could happen. I decided to keep a TrueCrypt backup for the foreseeable future, notwithstanding concerns about TrueCrypt’s security. At least I was fairly confident that I would always be able to retrieve my data from a properly set up and protected TrueCrypt drive. Better the devil you know than the one you don’t.

Encrypting for Real

I did not need to wipe the 3TB Toshiba drive. As I say, it had previously been wiped and encrypted, and I had added no meaningful unencrypted data to it since then. Hence, I went back to the original approach: set up the volume in Disk Management and then use DiskCryptor, with AES encryption and no wiping, to get it ready for data. As before, the time estimate without wiping was quite stable: within just a few minutes, it was steadily predicting a total encryption time of somewhat over 17 hours. That wound up being an underestimate: the actual time required for encryption was more than 19 hours. The estimates did inch upwards as we went on. When it ended, it did not announce that it had finished, and did not leave me with an indication of how long it had taken.

Once the drive was encrypted, I applied some of the tips suggested by ghacks. One was to disable auto-mounting. The idea here was that it makes no sense to go to all this trouble of encrypting a drive and using a password that even the National Security Administration can’t crack, if you’re then going to turn around and leave your password on your Windows drive, available to anyone who circumvents your Windows login. I had found it to be a hassle at first, but eventually hardly even noticeable, to have to enter the password each time I wanted to mount a TrueCrypt drive.

Another ghacks tip was to back up the drive’s headers. I wasn’t sure what this was about, and it was not easy to find clarification. I flailed around with results of a couple of searches — viewing a Microsoft article on GPT, for example, and pages by Rod Smith, Daniel Sedory, and SGI — before arriving at a search that led to more helpful sources. One was a Wilders Security thread that, while readable, provided more detail than I was prepared to digest. Another was a ghacks article that cut to the chase: it was about TrueCrypt, but it seemed relevant to DiskCryptor as well. It said that I would want a backup of my TrueCrypt partition’s headers if the header became corrupted or was changed by malware or by disk partitioning tools. A backup of the header would apparently not provide a door into my encrypted drive: the article said, “The header is worthless without the password.”

To back up the header in DiskCryptor, I had to select the partition and then go into Tools >  Backup Header. After entering the password, DiskCryptor was all set to save the backup header in a file called HarddiskVolume10.bin. I changed its name to something like 2014-08-23 Backup Header for USB Drive.bin, and put it into a folder where I saved settings and configuration files for various programs, located on a partition other than the DiskCryptor partition itself. (It was possible that I would have to rename it again, to a filename without spaces, in order to restore it, but for now it seemed advisable to have a clearly informative title.) I noticed that the Restore Header option was grayed out at this point; not sure what had to happen in order to awaken that option.

I wasn’t sure how often I should back up the headers. The ghacks tips article said, “The headers of the disk are important to determine whether a disk is encrypted or not.” I guessed, from this, that I would only need to back up the headers if I changed the fundamental configuration of the disk, by wiping and re-encrypting for instance. I wasn’t sure if I would also have to back up the headers again if I changed the password. I also wasn’t sure of the purpose of the Reencrypt Volume menu option.

It seemed there would continue to be more to know about DiskCryptor. I would probably return to this post to revise it in light of future learning. But for now, I had achieved the purpose of transitioning an external drive from TrueCrypt to DiskCryptor.