Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Encryption Open Source Privacy Software

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."
This discussion has been archived. No new comments can be posted.

TrueCrypt Author Claims That Forking Is Impossible

Comments Filter:
  • by fuzzyfuzzyfungus ( 1223518 ) on Thursday June 19, 2014 @10:13AM (#47271703) Journal
    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.
  • by satan666 ( 398241 ) on Thursday June 19, 2014 @10:47AM (#47272201) Homepage

    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)

    by Megol ( 3135005 ) on Thursday June 19, 2014 @10:47AM (#47272209)

    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.

  • by Kremmy ( 793693 ) on Thursday June 19, 2014 @12:17PM (#47273261)
    As far as we know so far, Truecrypt hasn't been compromised.
    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)

    by melchoir55 ( 218842 ) on Thursday June 19, 2014 @12:21PM (#47273307)

    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.

  • by wbr1 ( 2538558 ) on Thursday June 19, 2014 @01:14PM (#47273895)
    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.
  • Re:wrong (Score:5, Informative)

    by FuzzNugget ( 2840687 ) on Thursday June 19, 2014 @01:51PM (#47274291)

    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.

  • by Anonymous Coward on Thursday June 19, 2014 @02:09PM (#47274449)

    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).

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (3) Ha, ha, I can't believe they're actually going to adopt this sucker.