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."
So far as I can tell he claims that it would be impossible to re-license it under an OSS license and allow Matthew Green to use the trademark. This may be "impossible" because he doesn't control the IP or he may just be using it as a figure of speech to say that he won't comply with the request. The article title somewhat misleadingly takes the quote out of context. Of course it's just an anonymously posted email on Pastbin, I wouldn't put too much stock by it unless there's some independent confirmation of its validity.
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."
It very well could be "code speak" (pardon pun) for; "yes our code is compromised, no we are not allowed to talk about it, end communication".
Then again it could me less complicated than that, and taken at face value they could be saying; "Our code is a mess. Fixing it would take more effort than we are willing to expend for this project so we ended it. You are welcome to try, but we would recommend you just start from scratch as it contains many fundamental problems."
It is too bad, I've always considered it the defacto standard in encryption. I am not a huge fan of the idea of MS being my provider of encryption with bitlocker, though I have heard some good things about it. Then again it isn't exactly free either.
The Slashdot tinfoil hat part of me wants to believe the NSA story, however common sense tells me it is just another open project that was led by a dedicated few with little resources that became too much to maintain over time. That said, they were rather elusive about it in the end, so who knows. Then again that could be a professional record thing, liability, or legal... plausible deniability limiting personal liability sort of thing.
This is a common problem with software.