Phase 2 is done. Read it here. The findings summary is basically:
During the engagement, CS [Cryptography Services] identified four (4) issues, and none led to a complete bypass of confidentiality in common usage scenarios. The standard workflow of creating a volume and making use of it was reviewed, and no significant flaws were found that would impact it.
The most severe finding relates to the use of the Windows API to generate random numbers for master encryption key material among other things. While CS believes these calls will succeed in all normal scenarios, at least one unusual scenario would cause the calls to fail and rely on poor sources of entropy; it is unclear in what additional situations they may fail.
Additionally, CS identified that volume header decryption relies on improper integrity checks to detect tampering, and that the method of mixing the entropy of keyfiles was not cryptographically sound. Finally, CS identified several included AES implementations that may be vulnerable to cache-timing attacks. The most straightforward way to exploit this would be using native code, potentially delivered through NaCl in Chrome; however, the simplest method of exploitation through that attack vector was recently closed off.
So basically, unless you’re concerned about the Windows API generation of the encryption key, the last version of TC prior to the developer bailout remains an effective encryption solution. And TCNext is out there, though they’ve got no new version as yet (7.1 is available there).