Slashdot Mirror
TrueCrypt Author Claims That Forking Is Impossible
An anonymous reader writes On a request from Matthew Green to fork the TrueCrypt code, the author answers that this is impossible. He says that this might be no good idea, because the code needs a rewrite, but he allows to use the existing code as a reference. "I am sorry, but I think what you're asking for here is impossible. I don't feel that forking TrueCrypt would be a good idea, a complete rewrite was something we wanted to do for a while. I believe that starting from scratch wouldn't require much more work than actually learning and understanding all of truecrypts current codebase. I have no problem with the source code being used as reference."
Unless the deveopment is done outside of US. Because in that case you can use the letter to wipe your, let's say tears of joy and carry on writing the project. Unless, ofcourse you are planning to visit US any time in the future.
It's more likely that the author is the victim of a National Security Letter, and is obliged to say things like this to discourage people from using TrueCrypt or forking it. Which ever agency got to him must have known that this was likely to happen, and he is probably in it knee deep after putting lots of not-so-subtle hints on the revised homepage.
The 7.1a source code is being audited. There may be issues with the code base, but at least we will soon know with reasonable confidence if it is secure or not. Starting a new project would require a complete audit from scratch to get that level of confidence, and it is likely that at least one of the replacement projects is an NSA shill with backdoors installed from day one. The very fact that they went after TrueCrypt gives us some confidence that it is resilient to their attacks.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I'm seeing a Streisand effect. There is so much suspicion about TC's abrupt ending, especially after the code reviews found that it is a clean product, that more people seem to be using because they feel that it was killed by some powerful party.
TC is the only cross platform product out there that gives plausible deniability, is open source, and has been through an audit. The only thing against it are rumors about backdoors, none found.
--- Redefining "OS integration" to include "OS and boot integration", the short answer is: the boot process, hands down. You can model a new app based on TC's approach for OS-level (container/partition/disk) encryption, and you can do the same for MBR boot/system disk encryption, but now that everything is moving to TCG-TCM/UEFI/GPT/etc. it's a lot more complicated. -- Some history: IIRC from the TC forum, the TC's developer had issues finding a public API/method in the MS docs that could be used to pass keys and boot control from the MBR/bootloader to the OS and tc driver shim. There were third party apps out there doing it, but there didn't seem to be a documented way to do it, and the tc devs wanted to avoid fragile hacks to get it done. -- Microsoft actually responded to the TC devs by either publicizing a private API or by creating an official one. Again, this was back in the MBR days. -- With UEFI/GPT, trusted boot, etc., this part has become a lot more complex. I'm not sure what Microsoft's responsiveness would be on pursuing an official UEFI/GPT API, but I wouldn't be surprised if it's something along the lines of "Just use Bitlocker, it does this already."