The TrueCrypt situation that has developed over the past four days is the strangest moment I have seen in the security-research community in some years. On the twenty-eighth of May, the truecrypt.org website redirected to SourceForge with the message "WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues" and a recommendation to migrate to BitLocker on Windows or other built-in disk-encryption tools on other platforms. A new TrueCrypt 7.2 was simultaneously released, with all encryption functionality stripped — the new version can decrypt existing TrueCrypt volumes for migration purposes but cannot create new encrypted volumes. The previous versions were withdrawn. The TrueCrypt Foundation, the anonymous group of developers who maintained the project for the past decade, has made no further statement. Nobody knows what happened.
The speculation has been substantial and contradictory. Theory one: the developers received a national-security letter or equivalent compulsion and have shut down the project rather than comply, with the cryptic message a deliberate signal of that. This is the Lavabit-shape interpretation and would fit the post-Snowden environment plausibly, but the recommendation to migrate to BitLocker — a Microsoft product whose closed-source implementation has historically been considered less trustworthy by privacy-conscious users than TrueCrypt's open-source position — is hard to reconcile with this reading. If the developers were forced into shutdown by compulsion, recommending migration to a less-trusted alternative would be either an act of resignation or a coded warning whose specific encoding is not obvious. Theory two: the developers had become aware of unfixable architectural issues with TrueCrypt that they did not feel they could address, and have shut down the project rather than continue maintaining something they no longer believe in. This would fit the technical observation that TrueCrypt's design has some weaknesses (the bootloader, the integration with full-disk encryption, the anti-forensic-features-of-questionable-utility) that have not been substantively addressed in years. Theory three: internal disagreement among the anonymous developers led to a project breakdown, with the shutdown message being one developer's unilateral decision. Theory four: the TrueCrypt website and code-signing keys have been compromised by an external party, and the shutdown announcement is a hostile action by an attacker rather than an authentic developer statement. Theories five through ten have been circulating with varying degrees of plausibility.
What is clear is that TrueCrypt is, as of last week, no longer a viable choice for new encrypted-volume deployment. The 7.2 version cannot create new volumes. The previous versions are no longer being distributed by the project. The codebase is in the public archives but the maintenance and forensic-review infrastructure is gone. The Open Crypto Audit Project's Phase 1 review, which had been ongoing through 2013 and which had produced an initial report in April that was, on balance, positive, is now substantially less useful as a guide to whether the codebase is trustworthy because the project that would respond to the audit's findings is gone. Phase 2 of the audit, which had been planned for this year, is now in question.
For the engagement work, the post-TrueCrypt question is what to recommend for clients with existing TrueCrypt deployments and what to recommend for new full-disk-encryption requirements. The honest answers are uncomfortable. For existing TrueCrypt deployments, the migration path is to BitLocker on Windows (with the caveats about closed-source cryptographic infrastructure that the Snowden material has sharpened) or FileVault on OS X (with similar caveats), or to a relatively-new alternative that I have less confidence in than I would like. For new full-disk-encryption requirements, the same alternatives apply. The structural answer that I would prefer — a community-validated open-source full-disk-encryption tool with no known compromise concerns — does not, in mid-2014, exist in a state that I would deploy at engagement clients.
The narrower question is what to do about TrueCrypt's specific cryptographic primitives and design. The Open Crypto Audit Phase 1 report found no critical vulnerabilities; the design choices were, on the auditors' analysis, defensible if not always optimal. The codebase is licensed in a way that allows derivative work; there is already public discussion of community-led forks (VeraCrypt, ciphershed, various others) that would maintain a TrueCrypt-compatible alternative without the original project. Whether any of those forks reaches the maturity where I would recommend it to engagement clients is a question for the next twelve months. I will be tracking the work but I am not, in 2014, willing to recommend any of the TrueCrypt forks for new client deployments.
For the Hedgehog SOC, the TrueCrypt situation is operationally peripheral — the SOC monitors network and infrastructure, not endpoint disk-encryption choices. The engagement-team advisory work is where the TrueCrypt recommendation lands; I have been redrafting the relevant sections this week.
The wider point — and this is the part I keep coming back to in the post-Lavabit conversations — is that the dependency on small, voluntary, anonymous, or under-resourced security projects is structurally problematic for any organisation that depends on them. TrueCrypt was anonymous; OpenSSL was under-resourced; Lavabit was small and voluntary. Each has, in the past twelve months, demonstrated the same general failure mode: the project ceases to be viable in some way that the dependent users had not anticipated. The structural answer is some combination of better funding for critical open-source infrastructure (which is what the Core Infrastructure Initiative is starting to address post-Heartbleed), redundant implementations of critical primitives so that no single project's failure produces a system-wide failure, and explicit architectural acceptance that critical-infrastructure projects can fail in ways the dependent users cannot predict.
The next post is probably the GameOver Zeus takedown that is rumoured to land within the next fortnight — there is substantial international-law-enforcement coordination underway against the GOZ botnet and its associated CryptoLocker operation — or whatever else surfaces. The TrueCrypt situation may also produce additional clarity over the coming weeks; I will write more if it does.