Slashdot Mirror

thegarbz said

someone paid someone money to look at a code and tell us if it was safe. They said yes, turns out the answer is no.

The audit team said

Overall, the source code for both the bootloader and the Windows kernel driver did not meet expected standards for
secure code

What part of that sounded like "safe" to you? The report is easy enough to read.

They didn't qualify it at all. That was the editor who wrote the story, and the Slashdot editor who quoted the story. Neither quoted it from the report. https://opencryptoaudit.org/re...

First of all, there's a source code audit taking place. The source code audit has shown the binaries match the source, eliminating the possibility that the binaries were built with different source.

No, the audit didn't show that - the matching build was done by somebody else. A later goal of the audit project is to produce "repeatable, deterministic build", though.

Second, it's open-source. If a backdoor is put in the code, it would be in the commits.

The backdoors you have to worry about in Real Life isn't of the "if (nsa_are_connecting) { ... }" type - it's very subtle things that look like late-night coding errors, buffer overflows that allow remote code execution, or really obscure mathy stuff in crypto algorithms (like the wonky Dual_EC_DRBG stuff - that required hard math analysis, and wouldn't have been exposed during a code audit). In other words: you wouldn't discover backdoors from commit logs unless you were a world-class programmer and cryptographer, and you did hardcore analysis of all core-crypto related commits.

IMHO, any buffer-overflow or other "ability to run code on target machine" flaws aren't indicative of backdoors, merely human errors, and it's not critical to the security of TrueCrypt (or any other encryption software) - what we need 100% security against is cold attacks on encrypted volumes. Of course other flaws should be fixed, crypt-key material should be burned as soon as not needed, et cetera - but as long as you have an encrypted volume mounted, you are going to have the encryption key loaded in memory, and if anybody is able to execute code with root/admin/ring0/CallItWhatYouWill, they will be able to snatch your encrypion keys, and you're game over.

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

So who exactly is "the OCAP team?" I admit not following crypto research very closely so the only name I recognize on their site is Bruce Schneier, and though there's a few comments mentioning them on his blog he hasn't as far as I can tell said anything about being involved.

Enough time to rewrite the binaries, change the passwords, and disable the whole lot since it's all been compromised for years. Gets rid of a dangerous product, and pisses off the Feds without violating the terms of anything since TC is still available for download, just in a crippled form.

Well, the TrueCrypt audit project did manage to exactly recreate the binaries from the source file and so far haven't seen anything fishy in the source code other than some slightly weak encryption options making brute forcing of weak to medium strength passwords realistic.