TrueCrypt Author Claims That Forking Is Impossible 250
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."
You keep using that word... (Score:5, Informative)
I don't know if it's true or not; but it's a much less radical assertion.
Let me attempt to translate for you guys (Score:5, Informative)
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...
Re:Rewrites Suck (Score:5, Informative)
With few exceptions, rewrites are a bad idea. They only make sense when you need to fundamentally change the architecture, and even then it's often better to refactor heavily. Almost without exception, whenever someone says "Oh, it'll be easier to start from scratch", they're wrong. I understand that the TrueCrypt codebase is something of a mess, but I'm still skeptical that a rewrite is actually a better choice.
My opinion is the exact opposite: rewrites are often better when reaching a certain codebase size. The main reason is that existing functionality can often be put into a better shape by taking the big picture and adjusting everything according from the experience of the existing code.
The idea that rewrites are bad (that is often taught in programming classes) is mostly economical: it is less economical to do a rewrite rather than patch another level of indirection somewhere in the code tree. It requires more effort, a thorough understanding of the existing codebase (which often doesn't exist at all when code reaches some size, depending on _what_ the code does) and it requires a time gap between the releases.
But all these problems are fundamentally economical. But doing a rewrite can often be more economical, it's just that doing a patch is easier to quantify in money than a rewrite that will simplify patching/upgrades in the future and avoid fragile bug promoting messes.
Refactoring is essentially a "running rewrite" where parts of the code is changed while keeping most/all other parts intact or slightly changed. It decreases the time gap problem but in most cases require more effort than a rewrite while making many types of improvements hard or impossible.
Re:What whas the problem in the first place? (Score:3, Informative)
No, you're wrong.
From the TrueCrypt website:
WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues
WARNING: Using TrueCrypt is not secure
It may not use the explicit word 'compromised', but that says it clearly right there. TrueCrypt is compromised, whether a TLA did it or not.
Re:Translation (Score:5, Informative)
Foreign software isn't immune. No one thinks it is. The point is that US software is vulnerable *by law*. It is legally impossible to create secure software if you are a US entity. At least if the software is created in another country it is possible that it is secure. Even if the chance is 1/100, that chance is greater than 0.
Re:What whas the problem in the first place? (Score:4, Informative)
Re:wrong (Score:5, Informative)
Fair point, but what's the alternative?
BitLocker? Nope, might as well be called BootLicker, given Microsoft's complicity with the federal surveillance apparatus.
LUKS/CryptSetup might be OK for Linux users. But I need Windows for applications and drivers.
DiskCryptor (more like DiskCripple) has nowhere near the complete feature-set of the TrueCrypt suite.
There's eCryptFS... again Linux-only. You might be able to concoct some virtualized, networked Frankensystem to work with Windows, but that won't encrypt the OS.
And none of these options, as far as I'm aware, have TrueCrypt's plausible deniability feature, as fragile as it may be.
The best option *is* a TrueCrypt fork after the independent review has completed its final phase. And I think that's what the author is trying to say without actually saying it. Yay for 'Murican freedom.
Re:What whas the problem in the first place? (Score:5, Informative)
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 [opencryptoaudit.org] - that was done by somebody else [concordia.ca].
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).