A previous post discusses perplexing developments connected to TrueCrypt, the popular Windows-based drive encryption program. This post describes my initial exploration of DiskCryptor as an alternative to TrueCrypt.
After viewing DiskCryptor’s SourceForge page and home website, I downloaded and installed its latest version (1.1.846.118; alternate download at Softpedia). I would have liked a portable rather than installed version. There had been some discussion of that option, but evidently it was not going to be available in the foreseeable future. The download was small; the installation was fast and simple and required a reboot.
Upon running DiskCryptor, one improvement over TrueCrypt was evident immediately: the interface referred to the drives with their user-friendly names (e.g., Toshiba drive F rather than \Device\Harddisk1\Partition2). Oddly, the two disagreed on the device designation. For example, for the Toshiba hard drive on which my drive F was found, TrueCrypt said it was \Device\Harddisk2\Partition2, whereas DiskCryptor said it was \Device\HarddiskVolume9.
DiskCryptor offered a handful of options, some of which would be useful to me at times (e.g., Open Explorer on Mount, Cache Passwords in Memory, Wipe Cached Passwords on Exit/Logoff). An odd thing happened, though: when I tried to select the Unmount All on Logoff option, DiskCryptor froze (as shown in this
screenshot photograph, capturing the mouse cursor):
Not sure what I did to deserve that, but that’s how it stayed. I killed the program and tried again. I had the TrueCrypt program running, so I killed that before trying. That is, I killed the GUI: I still had some TrueCrypt drives connected and mounted. This time it didn’t freeze. I clicked Cancel, rather than save those setting changes, so as to try it again, with the TrueCrypt GUI running again. But, sadly, it froze when I clicked that Cancel button. I tried it once more, and this time it worked. No idea what that was all about, but now I had my settings set as desired.
Now there was the question of what drive to experiment with. I was willing to try it out on an internal hard disk drive (HDD) plugged into an external dock, connected to the computer via USB 3.0 cable. In that case, nothing lost: it was just a backup drive. There was the alternative of encrypting my program drive, which I had not previously done. That is, my drive C consisted almost exclusively of Windows 7 and other program files that defaulted to being installed there. This arrangement made it possible to keep drive C relatively small, and thus to mount it on an internal mSATA drive for speed. My data was on a separate internal HDD — bigger space, slower access.
If I decided to encrypt drive C with DiskCryptor, PCWorld offered a basic how-to, and TutsTeach offered a video tutorial. One point to emphasize: create a bootable live CD from within DiskCryptor, so as to have an alternative in case the system became unbootable.
But I wondered whether I should experiment with DiskCryptor on drive C. The scenario was that I would turn on the computer; it would require me to enter the DiskCryptor password as soon as it tried to run software on drive C (i.e., immediately after completing the power-on self test); and the password would allow the computer to go ahead and do whatever it wanted to do next. For most people, including me, that next step would be the booting of the operating system. Then, shortly thereafter, I would have to enter my Windows 7 password.
The need for a DiskCryptor password on drive C would arise, for instance, in the case of theft of a laptop. The Windows password would deter a thief who just wanted to see if there was any immediately available information of value, before selling the laptop to someone else. But the Windows password would not deter a thief who had the time to take out the hard drive and plug it into an external USB dock connected to another computer. In that arrangement, the thief could examine the contents of my drive C at his/her leisure: s/he would have needed my Windows password to boot my machine, but not to boot his/her own machine. My Windows password would not safeguard the contents of my disk; it would just prevent access to those contents on my Windows 7 installation.
If my approach to security went well, the advantage of encrypting drive C would be that its contents would be inaccessible to anyone who lacked the DiskCryptor password. This would matter to the extent that drive C would contain data that I did not want thieves or others to see. Since I stored my data files on a separate partition, the only user-specific data found on drive C would be that which assorted programs might put there, in the course of their operation. This would include the Windows pagefile (pagefile.sys) and hibernation file (hiberfil.sys), as well as various temporary and cache files.
In some cases I had redirected the creation of such files to a separate partition. I had done that to increase speed (i.e., reducing the load on drive C) and to reduce the size of backup images of drive C. Encryption would presumably inhibit performance to some degree. This redirection of caches and such to another partition reduced the amount of personal user data found on drive C; it also raised questions about security measures on that separate partition. Without encryption, it seemed that a relatively thorough security scheme might identify the places where such data might go, and might use scheduled batch files or other tools to delete such files when they were no longer needed, followed by an automated process to wipe drive free space on a regular basis. Such measures might not expunge data still preserved in RAM or saved in recently created temp files.
I had lost more data to bad or lost passwords and failed encryption schemes than to thieves and (as far as I knew) to the NSA (see previous post). I could imagine a situation where, for some unanticipated reason, Acronis or some other drive imaging program would balk or screw up when working with some aspect of an encrypted drive — leaving me with, perhaps, the long and tiresome task of completely reinstalling and reconfiguring my installation of Windows and other programs. At the very least, I figured that it would no longer be possible to explore an Acronis image to retrieve a Windows 7 file from some previous image of my drive C: the image would capture the scrambled and inscrutable contents of an encrypted drive, and there would presumably be no way to get past that encryption from within Acronis. In the worst case, the encryption of drive C could render my system unbootable, as others had experienced for various reasons, perhaps all of which were surmountable.
Until I had greater familiarity with the whys and wherefores of DiskCryptor, it seemed that the wise approach was probably to consider other security measures on drive C, and to undertake my initial DiskCryptor experimentation on some other drive. The writeup of that experimentation appears in another post.