New Attacks on the AES

Justin, could you persuade some of the experts with whom you have contacts to explore the TrueCrypt source code together with you?

That way the world would have the first solid analysis of the most popular free encryption software.

 

I'm working on it.

 

This could also be done hiring one (or more) experts who will examine the code. They could be paid on a donation basis. So what is needed is a way to gather the required experts (I am sure Justin could select some who would do a good job) and set up a little project giving Truecrypt users the possibility to donate something until X$ is gathered in order to pay the experts.
I am an active economical supporter of Truecrypt, but I wouldn't mind deviating some of the funds to an academical project on the security of implementation of Truecrypt.
The output would be a paper that, in the end, would be extremely useful for Truecrypt developers as well, who wouldn't need to give up on their anonimity.

 

Gerard, what is the rationale behind the decision of the TrueCrypt developers to remain anonymous?

Note that the suggested inspection activity isn’t a one-time event -- it should be repeated with each ‘significant’ release of the product, as is the practice of PGP with FIPS 140-2 validation (see here).

 

A very good question indeed. Take the Tor developers for an example, they are developing open source software which provides militant anonymity for years. And still, all the leading developers are not hiding their identities. On the contrary, they are publically promoting Tor. If anybody ever tries to force them to create a backdoor they would all give up from the project.

The same logic should apply to TrueCrypt. There isn't any valid reason for TrueCrypt developers to remain anonymous. The fact that nobody has a clue about who the developers are is starting to make me suspicious. I think I'll probably start using another on the fly encryption program as well.

 

Leonid, I too can’t think of a reason why the TrueCrypt developers wish to remain anonymous -- but, I’m open to changing my perspective if a valid rationale is provided. I agree that this situation should, at a minimum, cause users of TrueCrypt to at least pause and question what’s going on.

In addition, consider that “The domain name ‘truecrypt.org’ was originally registered to a false address ..., and was later concealed behind a Network Solutions private registration” (see here).

 

Maybe they have chosen to be anonymous for their own personal safety ?
If law enforcement could locate the developers, I could imagine they would be pressured to give out information.

The alternative, or so it seems, is that TrueCrypt is a somewhat rogue program. Possibly with a backdoor, possibly government related.

 

If that was the case, it would be trivial for "The Government" behind the project to find somebody who would lend his name as "The Developer" of Truecrypt, avoiding to raise suspects.

 

Fly, in my opinion, if any aspect of the protection provided by TrueCrypt is dependent upon knowledge held by the developers, then there is something seriously wrong with the architecture of the application.

 

We still depend on primitives whose designers are essentially unknown -- unless, of course, you consider the designer known if that designer is the NSA. Whether the design was a standard from the get-go (SHA family) or declassified at some point (Skipjack), we've been able to judge the designs for what they're worth, without regard to who designed them. That, and we know that the NSA has a penchant for this sort of thing, so we know they're pedigree to some extent.

Unfortunately, we have nothing to go on regarding the designers of TrueCrypt, and I'm not convinced. I would rule out any government involvement, given their unorthodox design decisions and the observation that they're analytical capabilities aren't as progressive as the state-of-the-art, given the hop from CBC to LRW to XTS. They at least seem to take design cues, even if they don't openly discuss them.

Implementing cryptography is no less difficult than designing it, given the merciless environment of real-world applications. Security-wise, I can only see a benefit in interacting with the community. To have such a cult-like following that I haven't seen since PGP is pretty darn cool; its users are gung-ho loyal. Cryptography, as we know it, flourishes because of openness. So, TrueCrypt, what's the deal?

TrueCrypt is riding on the zeal of its community, but this will wear off, if they aren't more transparent and receptive to influence. I'm still giving them the benefit of the doubt, and hope they get in the groove, but my optimism hasn't made if off the ground. I'll always be a critic, and it will continue to always be with its success in mind.

 

Speaking of “receptive to influence,” it is my understanding that the developers historically have had a penchant for deleting posts in the TrueCrypt user forum which are critical of the product. However, in fairness, I don’t know the frequency or the severity of this issue; and, other companies have been known to do likewise from time to time.

 

But Justin,

There is a saying that goes along somewhat like: "you can judge a book by its cover".
Therefor: can we, or you, not just judge Truecrypt simply by what they've came up with instead of looking at its makers.
Hell, you even have the sourcecode of the whole program.
I cant see myself or an external security consultant analysing the source codes of SafeBoot or Pointsec's full-disk-encryption products.

To keep the comparison limited to those two: would they be beter at making an encryption-product then the makers of Truecrypt?
You swap the lack of identity of Truecrypt's makers with the lack of sourcecode from Pointsec and Safeboot.

Which of those two is the bigger negative?

 

Stap0510, from my perspective, the key underlying issue is not primarily the developer’s identity per se, but is FIPS 140-2 validation. If the identities of the developers are preventing TrueCrypt from achieving “independent assurance that the standard cryptographic algorithms … are implemented correctly,” then that’s a legitimate concern (see posts #22 and #23).

TrueCrypt isn’t the only encryption application whose source code can be publically inspected. The same is true of PGP (see here), which is also FIPS 140-2 certified (see here).

 

I used to contribute there quite often, with novel-like posts of verbosity and concern, but, mysteriously, I tried logging in one day to no avail. After numerous attempts to resolve the issue, including contacting the forum administrators -- no luck. Even registering again with another e-mail address -- not a free one, but an ISP-provided one --- again, no luck. I'm not sure how closely this relates to the issue you've mentioned. Regardless, I can still post my concerns about TrueCrypt elsewhere, so not all is lost.

Sure, and I agree that we often have no choice but to judge a book by its cover, hence my mentioning of the NSA's SHA family and Skipjack. However, we know that the NSA has an unparalleled pedigree in this sort of thing, so while we may not know exactly who designed it, we know the cryptanalytical expertise behind them. We can go with what we have, but it's always nice to know whether or not the designers of a primitive, protocol, application, or what have you, know how to design secure cryptographic software. Otherwise, the chances of them producing something good are slim. That's not to say that TrueCrypt is bad; it very well may be good. Failure is inevitable, no matter how well-versed you are in secure software design, but knowing who is calling the shots makes it all less of a crapshoot.

 

But are the identities needed for the FIPS 140-2 validation?
Could it not just go through TC's foundation?
How much would such a validation-process cost in total?
Does anybody know?

As Markoman also mentioned, if money is the problem then donating money for that specific purpose wouldn't be an issue for me.
I'll be happy to donate some money for that.

 

Justin, that’s a troubling report. Suppression of free speech is incongruous with the core philosophical underpinnings of privacy. From my own perspective, such behaviors are directly relevant to the issue of the integrity of the developers and therefore may be indirectly relevant to the TrueCrypt product itself.

Stap0510, I am relying upon Gerard Morentzy’s statement (see post #23) that identities are required when applying for FIPS 140-2 validation.

Stap0510, that is very generous and thoughtful. However, as I noted earlier, be aware that code inspection and validation “isn’t a one-time event -- it should be repeated with each ‘significant’ release of the product, as is the practice of PGP with FIPS 140-2 validation (see here).” Therefore, an ongoing supply of financial resources would be required.

 

For me, just having one version (6.2 ?) of Truecrypt FIPS 140-2 certified is enough.
You got to start somewhere.

 

Another New AES Attack dated July 30, 2009 by Bruce Schneier.

-- Tom

 

You mean someone with a silly name like "Roger Dingledine",
a graduated from MIT who just so happens to be working on a
project called TOR, originally sponsored by the US Naval Research Laboratory ..
I can see why people would trust that more than TrueCrypt ..

Maybe the TC-developers are so secretive to prevent any STASI-bastards
from serving them a court-order forcing them to release a version infected with the Bundes-trojaner ??

Anyway, now Bruce is recommending using AES128 over 196/256 ?? Hmmmmmm .... and how is it that we know he isn't a spook ?

 

Out of curiosity what exactly would the attacker need to know to crack the encryption? Your router make and model and the manner in which said model implements AES right? And for the attack to work, the router would have to NOT implement the full, what is it 14?, rounds of AES. Am I right?

 

This is a matter of key schedule, rather than key space; that is, these attacks don't extend to the key schedule of AES-128, hence the recommendation.

Keep in mind that these related-key attacks apply to applications of the AES that we don't usually encounter in practice, such as hashing. For encryption, or applications where we assume the AES to be a PRP, it's just fine. I don't know of any router, or application, for that matter, that uses the AES in a way that is susceptible to these attacks.

 

Hi Justin,

Thanks for the response. So under what situations is AES susceptible? When used to encrypt files in TrueCrypt? What about PGP or other data encryption type situations? When is AES used in hacking?

 

These related-key attacks, in a nutshell, assume that an adversary has access to different plaintexts encrypted under different, related, keys, which can be ruled out, if you do things right. From the way it looks now, the attacks would apply if the AES was used as a hash function, in Davies-Meyer mode, for example, which is essentially the construct on which MD5, SHA-1, SHA-2. However, we don't need to use the AES this way, because we have dedicated hash functions already that meet security requirements of which the AES was never intended.

We use the AES for purposes like message encryption and message authentication, where modes, such as CTR (i.e., encryption for confidentiality) and CMAC (i.e., authentication for integrity) assume the AES to be a PRP; this is still just fine. On the other hand, if we expect the AES to behave like an ideal block cipher, as might be assumed in Davies-Meyer mode, then we might have a problem. So, TrueCrypt and PGP aren't susceptible. Furthermore, I can't think of any application that is.

 

Alright thanks for that Justin, you have set my mind at ease!

 

Re: I disagree.

Even if considerably late, thanks Justin for pointing this out, you (and Mr. Ross) just changed my mind.

The reason why I originally thought cascade algorithms are safer is because Truecrypt User manual specifically says a cascade algorithm may be more secure (page 40 Truecrypt User manual).