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."
It would appear that the intended meaning is 'impractical'. The code is available, and the original project declared itself dead, so forking is totally possible; but the author believes that it would probably be a better use of time to use the existing project as a reference for building a new one, rather than get sufficiently familiar with the old one that you can (safely) start modifying it.
I don't know if it's true or not; but it's a much less radical assertion.
Reading between the lines here, it seems fairly probable that Truecrypt has either
a) Very serious security bugs, or
b) Had backdoors introduced by the NSA.(Does Truecrypt use elliptic curve cryptography?)
In either event the code is basically tainted and shouldn't be used for any future projects.
The vague and sometimes bizzare nature of the statements from the Truecrypt dev team, including this one, lead me to believe that they have been placed under a standard NSA gagging order and have decided to burn Truecrypt rather than see it be turned against its users. Comments like "Forking is Impossibe" appear to be an open code for communicating that they are essentially unable to communicate, but that Truecrypt is no longer a trustworthy piece of software.
Reading though the Lavabit case, it's clear that those placed under NSA gagging orders have very, very little room for legal/media maneuver, but nevertheless still retain the freedom to walk away from their projects and tell others not to use them. Such actions appear to be the last defense of cryptographers in the US, and I think that is what we're seeing with Truecrypt.
May the Maths Be with you!
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.
As far as we know so far, Truecrypt hasn't been compromised. So ending use of it might be a victory for the NSA and their kind. And all they had to do was sow some seeds of doubt.
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
> Unless the deveopment is done outside of US.
At this point this is the way it has to be. Any piece of software developed by US citizens, companies, foundations, etc. is no longer trustworthy. The US is dead as far as secure software is concerned.
He says:
"I am sorry, but I think what you're asking for here is impossible."
As a developer, he uses the term "impossible". Nobody says
"impossible" in a development framework. You could
say "difficult" or "expensive" but not "impossible".
He says "impossible" because he is telling us in
specific terms:
It is "impossible" to use the current code base because
it has been compromised. He can't talk about it. He is
under court order or some fucking thing.
Since he cant tell us where the compromise is
he says fuck it all and start from scratch.
He is very specific.
Look, if the developer of an encryption product
says the product is not secure and it is impossible
to fix, I take that as:
"Stay the fuck away from this thing".
To be forewarned...
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."
This.
Try blowing the whistle on something. Revel in satisfying your moral obligation and the feeling of righteousnous. It will last until the first threatening letter from a lawyer arrives. Then you'll see what you're made of. Chances are good that it's not steel. Until you've experienced it, you won't know.
Just about any government organization or better than medium-sized private entity has the resources to crush an individual with very little threat of recourse. You really can't imagine the kinds of crap they can lob. If you are thinking of blowing a whistle, be very careful. Read up on the subject (Google for "how to whistleblower"). Absolutely DO NOT try to use internal channels. There are organizations that try to support whistle blowers, contact one (anonymously) and see what reading material they can give you. Make sure your nose is absolutely clean. Try to find cases of similar acts of whistle-blowing in your legal jurisdiction. How did they turn out for the whistle-blower? Probably not very good. Do everything right. Make sure you have enough evidence for an iron-clad case (without actually stealing anything). And wait until you have some distance. If you can keep the perpetrator(s) from figuring out your identity, absolutely do so. You will save yourself a lot of grief. This means you have to keep your mouth shut and trust nobody. (Note that I'm posting anonymously.) You won't be able to vent to anyone, especially co-workers. This is much harder than you might think. If you like to talk, you'd best just forget what you've seen. If you can time your actions so they hit while the perpetrator is under pressure for other problems, so much the better. Before you pull the trigger, think long and hard about the affect this will have on your loved ones. Consider supporting an anti-corruption organization to satisfy your need to do good rather than risking yourself.
Yes, it's really that bad. The sort of folk that deserve to be found out are more entrenched than you suspect. They are willing to go to extreme lengths to protect themselves. The problem almost definitely is more widespread than you think. The way it often works is that there is a web of wrong-doing, where one fellow's previous mistakes are used as leverage for silence/support by someone else. It makes for a kind of club. Many members of the club will have had one or more whistles blown on them before and have strategies for dodging and attacking the whistle-blower.
And that's just if you are whistle-blowing on a run of the mill organization. Going up against the likes of the NSA, the DOD, or the CIA... The TrueCrypt authors have all of my respect for shutting the project down. It was an act of bravery.
The Guardian reported on a hidden Latin message: TrueCrypt probably didn't leave a Latin message alerting users to NSA spying. I'm not so sure about their in-headline conclusion, though.
They quote this comment on Wikipedia by 'Bardon':
The Guardian article rebuffs this with: "In fact, "uti nsa im cu si" is meaningless in Latin - except to Google translate, (mis)translates it to the message Badon discovered."
But isn't that enough? It's a hidden message; it doesn't need to be correct Latin as long as the point gets across. If you put into Google Translate right now, you get "If I wish to use the NSA". Unusual that it's been changed slightly, but still expresses the same message: The NSA has compromised TrueCrypt.
I'm not one for conspiracy theories, but this entire TrueCrypt saga has been bizarre. Obviously something happened beyond "the task of maintaining a widely used cryptography program just became too much work" or else why not just say that?
Code review did not find it to be a clean product. They simply found that the Windows binary that was distributed could be produced from the source code. IE there were no extras in that bin. Whether the code itself has crap in it is still at question and is being audited.
Binary Reproducibility wasn't a goal (or even attempted) by the audit project - that was done by somebody else.
The audit project didn't go through the entire TC codebase, but covered a lot of important areas. They found some issues here and there, but nothing they highlighted was especially serious - i.e., no cold-attack vectors, which is the important thing to guard against (anybody with physical access to your machine would be able to dump keys from memory, Game Over).