Grain of salt

Before I'd trust a fork, I'd want an idea of why the original developers considered it insecure in the first place. I'd think if they just didn't have the resources or interest to maintain it, they'd say they were ceasing to maintain it rather than make an ambiguous statement about security. And there's more than one security risk. If it were something like they were ordered to hand over copies of the private key used to sign binaries, rendering TrueCrypt vulnerable to government-created "official" versions, that can be dealt with in several ways. If it's a case of TrueCrypt being unable to protect the data against interception within Windows on it's way to the application, there's nothing anyone can do about that and it has to be mitigated against in other ways. And if finally there really is some obscure and fatal flaw in the basic design or coding of TrueCrypt that makes it inherently vulnerable, we'd need to know what it is so we know any new maintainers have in fact fixed it before we could trust the new fork.

I'd note one interesting indirect attack: use methods that'll cause the most secure projects to declare themselves at risk without letting them say why, letting paranoia push users into switching to software maintained by less scrupulous companies who'll stay quiet about their software being compromised until forced by outside discovery of the compromise.

Dear Techdirt...

>suddenly announcing that development had stopped and that the code was not secure.Is it even a question? Everyone knows who is behind this. It was the beloved Dictator, Commander in chief, Admiral, General, CEO, President of the Free Democratic Peoples Federal Republic of America.

For all looking for the current secure release + older versions and sources and some additional information, i recently made website about the whole events with a data archive. all files with hashes for download.

Gibson's new summary & links page

Re: Gibson's new summary & links page

Well, the developers are certainly correct about Bitlocker: nobody who's serious about security would even consider using Windows, so for those people who insist on doing so anyway...let them use Bitlocker, it's only the second-worst decision they've made.

I do hope the neo-Truecrypt project takes that to heart and excises all support for Windows. Supporting an inferior operating system is a lot of work, and takes away resources that could be better spent elsewhere. The focus should be entirely on 'nix-based systems.

Re: Re: Re: Grain of salt

fix license issue first

TrueCrypt is not FOSS. They'll need to fix the license issue first. I'm guessing they'll have to deal with removing and replacing the contended E4M derived code before they can be in the clear abut forking it. This assuming the current developers want to allow forking the original portions of the code.

Re: Re: Re: Re: Grain of salt

“Fascism should more appropriately be called Corporatism because it is a merger of state and corporate power”

“The definition of fascism is The marriage of corporation and state ”

"Fascism, the more it considers and observes the future and the development of humanity, quite apart from political considerations of the moment, believes neither in the possibility nor the utility of perpetual peace.”

Re: fix license issue first

There is a forked version already. I don't know all the details of the license issues.

"The realcrypt application in the RPM Fusion repo is an encryption application based on truecrypt, freely available at http://www.truecrypt.org/. It differs from truecrypt in only the following ways:

"- The name truecrypt is changed to realcrypt throughout the application, as requested by the truecrypt License:

" -All original graphics are replaced with entirely original new ones, as requested by the truecrypt License:"

-more-

"It does not differ from truecrypt in any other respect; in particular, no code relating to actual encryption or decryption is modified. Nevertheless, the truecrypt License requires that we ask you to report any and all bugs you find to [https://bugzilla.rpmfusion.org/ RPM Fusion's Bugzilla] and not to the truecrypt project."

Re: Dear Techdirt...

This sort of bare comment isn't really helpful. What exactly about the Techdirt comment system do you see as antiquated, or otherwise problematic?

I think it's one of the better ones I've seen in current use. About the only thing I could point to as unambiguously improvable about it is the fact that posting a new comment takes you to a different page, and you have to go "back" to continue reading from where you left off.

(There are of course quite a few of what I might call "ambiguously improvable" things, i.e., things which if changed in the way I have in mind might end up better, or worse, or even just different after all.)

Re: Re:

Re: Re: Re: Gibson's new summary & links page

"The problem with BitLocker isn't that it runs on Windows [...]"

Yes. It is. People who care about security and privacy do not use Windows (a) because it's a maldesigned piece of junk with an enormous and still-growing litany of baked-in security problems and (b) it's closed-source, which means if it's backdoored -- and I think there's a fair chance that it is -- that it will be very difficult to discover that.

If you want at least a modicum of security, then make a better choice in OS. But please, let's not even put "Windows" and "security" in the same room together.

It would be

Re: Re: Re: Re: Gibson's new summary & links page

I don't disagree, basically (although it is certainly possible to run a secure Windows installation, it takes more work and skill than most people are willing to invest. It's easier just to use a more secure OS from the start.) But we're talking about two different things. I'm talking about the security of the crypto, not the OS.

Backdoors can be anywhere including open source s/w

The problem for s/w developers today is that all systems can be "backdoored" without the backdoor existing in the source code of the application you are compiling.

Any toolchain in use can be compromised without the source code being compromised. All it takes is to generate a single compiler that inserts the backdoor into any system in a specific manner and all compilers and all applications generated thereafter can be compromised.

When we look at something like *ix systems, at some point we need to use a binary to compile the source code of the compilers we use. All it takes is a single infestation into a distribution to propagate that infection.

To get around this, it requires knowing the provenance of all code within the system, including any binaries that are in use.

Of course, it goes without saying that to do this requires real skill, foresight and knowledge. This is not necessarily the domain of any of our security forces/organisations.

Re: Backdoors can be anywhere including open source s/w

Any toolchain in use can be compromised without the source code being compromised. All it takes is to generate a single compiler that inserts the backdoor into any system in a specific manner and all compilers and all applications generated thereafter can be compromised.

I presume you are referring the the Ken Thompson hack. All such hacks are liable to discovery as a system evolves, and better debugging tools become available. Also they are liable to failure when the underlying system changes. Such hacks have to be targeted to very specific routines, and have to assume that neither the routine name, or required actions change. Relying on any external code introduces another point of failure. All code that is not maintained will fail due to external changes at some point in time.Note one extreme weakness of such hacks, they cannot keep their insertions hidden from a reverse assembler, as it is always possible to write a reverse assembler and compile it without the hack being able to detect it, never mind change it. Similarly, with open source, it is always possible to add logging code to the kernel that the hack cannot detect and bypass. Code that did not exist prior to the hack being implemented, or never available to the person carrying out the hack cannot be modified by the hack.

Re: Re: Backdoors can be anywhere including open source s/w

Agreed, they are not completely hidden (particularly with reverse assemblers), but the ting here is that with the various optimisations that compilers do do, various signatures in the object code can be recognised to place the compromised object code accordingly.

Any part of the toolchain can be compromised accordingly for this kind of purpose up to and including the linkers and loaders.

We see enough problems with source code having errors, let alone trying to determine what is actually happening with the object code generated.

The problem is that most people "trust" that the tools they are using are okay and don't go that extra 100 miles to check the binary code generated.

I know that in my youth I would set aside time to examine the binary code produced particularly if strange errors were being obtained. But these days, for the kind of stuff I do, I don't put in such time as I have other things that need to be done.

All I am saying is that backdoors can be put in without any changes being made to the source code.

Audit guys are backpeddling a bit but..

His original tweet was:"We are considering several scenarios, including potentially supporting a fork under appropriate free license, w/ a fully reproducible build."But later followed up with:"Just for the record, we are not 'forking Truecrypt'. We plan to audit it and perhaps organize (financial) support around such an effort."

Now, there IS a fork in the process of creation over at http://truecrypt.ch/ but as it is in the early stages of the process, and the Audit guys have yet to complete the rest of their study of the app crypto, it would be better to leave this on the back-burner until we know what bugs need to be fixed....