Phase two of the TrueCrypt audit figures to be a labor-intensive, largely manual cryptanalysis, according to the two experts behind the Open Crypto Audit Project (OCAP).

Matthew Green, crypto expert and professor at Johns Hopkins University, said a small team of experts will have to, by hand, examine the cipher suites, key algorithms and random number generators used in the open source encryption software.

Green said he hopes to crowdsource experts for the second phase of the audit, attracting people skilled in examining cryptography.

“We’re still flushing out the idea, but it will be a group of people who are well respected in the industry who have done this type of thing on a smaller scale,” Green said, adding he was not yet ready to publicly name them. “We would not be doing this if it were not for these people. We’ve created a series of challenges and we’re going to divide them up. I’m sure it will be fairly successful; we’re still in the planning stages.”

ISEC Partners, the consultants who were hired to conduct the first phase of the TrueCrypt audit that looked at the TrueCrypt bootloader and Windows kernel driver, will not be involved in phase two, Green said, adding that the results for the second half of the audit may not be available for a few months.

The movement to audit TrueCrypt began last fall, a few months after the Snowden leaks began going public. TrueCrypt, which provides full disk and file encryption capabilities, has been downloaded close to 30 million times, making it a tempting target for intelligence agencies that have been accused of subverting other commercial and open source software.

ISEC on Monday released its report on the first phase of the audit and said it found no backdoors in the portions of the software it looked at. There were, however, worrisome vulnerabilities around the quality of the code and build processes.

“The good news is that there is nothing devastating in the code,” Green said. “The auditors said there were problems in code quality and pointed out other legitimate issues. These are not reasons to stop using it.”

One of the first concerns leading to suspicions that the Windows binary version of TrueCrypt had been backdoored was a mysterious string of 65,024 encrypted bytes in the header. Experts wondered why these random bytes were there and whether they could be an encrypted password. Adding to the intrigue was that, aside from the fact the Windows package behaves differently than versions built from source code, no one really knew who the developers behind TrueCrypt are.

In October, however, some of those concerns were laid to rest when Green and OCAP co-organizer Kenneth White, senior security engineer at Social & Scientific Systems, were contacted by the anonymous developers who endorsed the audit. Also, an independent audit of TrueCrypt conducted by Xavier de Carne de Carnavalet of Concordia University in Canada, was able to reproduce a deterministic compilation process for the Windows version that matches the binaries. He concluded TrueCrypt was not backdoored.

“We’re not going to say the issue is closed, but we’re a lot less panicked about it,” Green said. “That doesn’t mean there isn’t something there, it’s just not on my list of things to worry about.”

The relief with the initial results is that there isn’t a widespread bug in the software; while TrueCrypt isn’t deployed on a scale of OpenSSL or Apple software, the recent Heartbleed and so-called gotofail iOS bugs have left some in the security community a little shell-shocked. White, for one, is hoping the cryptanalysis turns up equally positive results as in phase one.

“Our confidence in encryption software is driven by the level of expertise afforded proper peer-to-peer review, by deep experts in the field. And there is a very small group of people who are qualified to conduct this kind of analysis, particularly with the encryption components,” White said. “What they find might be gross errors or might be a trivial single character mistake.”

While very few of these types of public audits have been conducted—perhaps the most high-profile security tool subjected to a public audit was open source private chat application Cryptocat—Green and White see the potential for more of these in the future.

“It’s much harder to do than it seems. It’s not just about getting the money and paying people; you have to find people who are interested doing it. Not every firm is interested in doing a public audit,” Green said, adding that the TrueCrypt audit is the first of its kind that was crowd funded. “We have a good technical advisory board who were willing to put in the time to make this happen. You need good organization with people whose job it is to do this; you can’t do this in your spare time.”

White said future projects are under consideration, but for now 100 percent of their efforts and funding is going toward the TrueCrypt audit.

“I think there is a subset of people who had their minds made up before we started, and have no intention of changing. For me, the appeal of this work has been to begin to establish a framework for conducting community-driven security audits and formal cryptanalysis on open source (or, in the case of TrueCrypt, source-available) software,” White said. “I think if after the final report we can say, ‘We marshaled some of the best minds in the field, and they looked at the code, the crypto, and the implementation and we found [X]’ then that’s a victory. As a privacy advocate, I’m obviously hoping for a clean verdict, but as a security engineer, I remain skeptical until the end.”

Categories: Cryptography, Vulnerabilities

Comments (2)

  1. coins
    2

    I’m still suspicious of the “cascading cipher” TC uses. Sounds like snake oil. Would also be interesting to see how easy it would be to detect so-called deniable layers, meaning inside and outside container.

    Reply

Leave A Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>