(Note: a subsequent post updates this one, without this post’s attention to debates about possible law enforcement intrusion leading to the collapse of TrueCrypt. That subsequent post focuses on the use of VeraCrypt as an alternative on Windows systems.)
It appears that an effort to keep your data out of other hands should begin with this question: are you prepared to switch over to Linux?
That may seem like an odd place to start a discussion related to TrueCrypt. The general concern driving that question is simply that corporations, especially American corporations, are vulnerable to pressures and opportunities offered by powerful players in the law enforcement and national security arenas, such as the National Security Agency (NSA). There is considerable distrust of Microsoft and its Bitlocker disk encryption tool, and also of Apple disk encryption options, not to mention tools developed by smaller players who could have even fewer options against threats issued by agents of such organizations.
Linux has some advantages in those regards. Its source code is not a corporate secret. It is open for inspection by people of any nationality. It is relatively unlikely that Linux code could facilitate a backdoor entry into your data that people would fail to detect and close. Yet even those who choose the Linux Unified Key Setup (LUKS) specification (in a program like dm-crypt or Cryptsetup) do not necessarily claim that it provides absolute security. As stated in one Ubuntu thread, “your computer is reasonably safe unless you are subject to serious organised cyber crime or Government investigation.”
As someone pointed out in response to that caveat, there are also numerous real-world constraints upon the possibilities for data security. A previous post discusses possibilities and precautions related to keylogging (i.e., observation or other theft of the series of keystrokes typed into a computer). Another post lists other security measures to consider. It is advisable to think about the specific situations being protected against. For instance, as noted by the Electronic Frontier Foundation, encryption is of little value within the context of civil litigation: a refusal to provide data known to exist, upon demand, can have severe consequences.
Within the specific area of disk encryption, even in Linux and certainly in Windows, there are reportedly ways to capture (e.g., from RAM) the password used to gain access to one’s drive. People have also been known to do foolish things with passwords. And for weak passwords, brute-force attacks (i.e., guessing millions of passwords per second, narrowed down with the aid of various rules and databases) provide an option now, and will become an increasingly feasible option for the holder of your drive in future years.
Of course, the password is not even necessary if the machine containing the drive is accessed after the password has been entered. The latter concern is especially relevant for machines that are accessed while powered up in their present location, and also for stolen machines that continue to be powered during and after the theft. The latter group includes laptops that are currently running on battery power, as well as any machine that has been placed into hibernation or some other state that will preserve the entered password after power is restored.
There are good arguments for disk encryption. You don’t want thieves to access your bank account; you don’t want blackmailers to demand a ransom in exchange for keeping quiet about what they’ve found on your drive; you don’t want a hyperactive or corrupt prosecutor to pursue a trumped-up violation of law based on “evidence” found on your disk. At the same time, Edward Snowden notwithstanding, you are not likely to know how much various good and bad guys know about you and your data. Short of the fantasy of doing all your work in a secure room, on a computer that has no means of access by anyone other than yourself, the best you can hope for may be to keep things reasonably safe and maintain a low profile so that nobody has much motivation to pursue you.
The question about Linux, at the start of this post, arose from recent developments related to the popular Windows-based TrueCrypt disk encryption program. In May 2014, the TrueCrypt website was abruptly changed. Basically, TrueCrypt’s developers suddenly decided not only to cease development, but also to drive users away from TrueCrypt — and they did so in ways that have given rise to considerable speculation and suspicion. For instance, the Internet Archive states that the URL for the TrueCrypt website has been mysteriously “excluded from the Wayback Machine.” In response to a guess that maybe the developers just decided to quit, a participant in one long and interesting thread said this:
Similar discussions flourished elsewhere. Authoritative commentators were equally baffled. There were speculations that perhaps TrueCrypt had been discontinued because its developers had discovered insurmountable flaws in it. But as just noted, the manner of their withdrawal was exceedingly odd — not to mention that their withdrawal, in mid-May 2014, came shortly after news that TrueCrypt had passed the first round of an intensive security audit.
(Upon reviewing this post three months later, in November 2014, I decided to return to TrueCrypt, and to discontinue my experimentation with DiskCryptor and other alternatives for the time being. There were several reasons for this decision. As discussed elsewhere in this post and in another post, DiskCryptor produced speed results that could diminish confidence. I discovered Steve Gibson’s arguments in favor of TrueCrypt, and at this point I was more inclined to agree: TrueCrypt was evidently the only encryption tool that had been audited; remarks by TrueCrypt developers did not support conspiracy theories; someone would surely take up TrueCrypt’s further development at some point. But the remainder of this post was written in August 2014.)
Whatever was going on, however, there was a question as to what encryption tool would be most appropriate for ordinary users going forward.
As one possibility, it was pointed out that TrueCrypt versions prior to 7.2 would not be affected by the oddities pertaining to 7.2 and the newly bizarre TrueCrypt website. Since those prior versions — notably 7.1a — were no longer offered by TrueCrypt itself, however, there was a question as to where one might get them. At this writing, some fairly safe sources (e.g., Softpedia, but not MajorGeeks or CNET) (and Steve Gibson) were still making 7.1a available.
There was some concern that any software will need updating as problems (and perhaps vulnerabilities) are discovered — that, in other words, an unmaintained security program could be an accident waiting to happen. Some might consider that worry potent enough to warrant switching encryption programs immediately; others might wait a while. Some voiced a belief that someone else would surely take up the TrueCrypt development project in the not-too-distant future, but others cited serious barriers to such an undertaking. Whether that belief would pan out, and how credible any resulting product might be, remained to be seen.
For those who decided not to switch to Linux for its potentially superior encryption safeguards (along with any other perceived advantages of such a switch), the Windows alternatives to TrueCrypt included Microsoft’s Bitlocker, DiskCryptor, CompuSec, FreeOTFE, and BestCrypt. There were others (notably AxCrypt and AES Crypt, or for that matter WinRAR and 7-Zip) that could encrypt files and folders but not entire drives.
I quickly decided against that last option, involving encryption on the level of files and folders. It seemed that some forms of file and folder zipping and encryption could interfere with file and content searching programs. Bill Bosen and Gizmo cited a number of other drawbacks of file-oriented encryption. A drawback I found particularly persuasive, from personal experience, was that in practice a person would tend to forget about making sure that each new file and folder is encrypted. Even if one remembered, it could be cumbersome to undertake manual encryption of such new creations. A detailed inspection of the features of various file- and folder-level encryptors might turn up some programs that would minimize such concerns. But I decided to focus my limited time for this project on the more comprehensive full-drive alternative.
Among the several full-drive options listed above, Bitlocker was surely the best-known. As noted above, however, many doubted Microsoft’s commitment to the privacy of their data. There would also presumably be concerns about the commercial and/or proprietary nature of CompuSec and BestCrypt, two other TrueCrypt alternatives sometimes mentioned. Though I did not investigate it, one source stated that, in addition, CompuSec worked only on Windows XP and earlier. FreeOTFE, reported to be a Windows version of Linux’s dm-crypt, did previously get a few moderately positive reviews, but it apparently had a steep learning curve, was reportedly not available in Windows 7 or 8, at least not in 64-bit versions, and was no longer being maintained.
This left DiskCryptor as essentially the only game in town. It did not appear to be a bad option. Its website characterized it as a capable open-source tool. DiskCryptor had drawn numerous positive reviews. Experience suggested, however, that reviewers tend to be looking at features, performance, and other immediately visible characteristics that, however important, do not necessarily sum up to an impression of the program’s real-world reliability. Was it going to accept all my data for six months and then turn out, for some unforeseen reason, to be a black hole? Would there be a bug that would render its encrypted data unreadable upon the occurrence of X condition?
Only time would tell. There were a couple of possible responses to such concerns. One strategy, it seemed, would be to maintain one or more parallel backups in some other format (e.g., TrueCrypt) while transitioning to DiskCryptor. This would require some additional time and hardware over an extended transition period, but perhaps at not much net cost after resale. Another line of inquiry would involve review and interpretation of advisories (i.e., advisory reports) and informal reports of problems regarding DiskCryptor. Secunia, one potential source, had no advisories on DiskCryptor 1.x, at least not in recent years. (At this writing, the current version offered at DiskCryptor’s website was 1.1.846.118.) But for purposes of illustration, one could examine a DiskCryptor advisory by iViZ Security in 2008.
Since it was not clear what one should make of the abrupt TrueCrypt developments of May 2014, I had to consider the possibility that its developers had discovered a tremendous flaw, either in its actual code or in what NSA or some other player had been able to make of it. While I had no desire to jump from the frying pan into the fire, it did seem advisable to take seriously the prospect that years could pass before a verified reliable upgrade of TrueCrypt would arrive on the scene. It also appeared that DiskCryptor would have some advantages over TrueCrypt — in terms of speed, for example, and features, and open-source checking and verification of code. I decided, therefore, to take steps toward transitioning to DiskCryptor.