According to a German researcher, Mattias Schlenker, we are to expect that the reason for TrueCrypt's recent shutdown is not a National Security Letter, but a serious security flaw in how TC container files are created on Windows.
He expects the flaw to become public within a week.
What gives this chap some credibility is that he's one of the developers of "desinfec't", a Knoppix-based live Linux that comes with several virus scanners and is distributed by well-renowned German computer magazine c't (whose mother company/publishing house, Heise, hosts the forum where he made his announcement).
Link to his original German posting: http://www.heise.de/security/news/foren/S-Re-Warum -TrueCrypt-nicht-in-Desinfec-t-enthalten-ist/forum -280432/msg-25289876/read/
See our earlier coverage: TrueCrypt Discontinued, Compromised.
(Score: 2) by Angry Jesus on Friday May 30 2014, @11:46PM
> if the image is not mounted when the attacker wants to gain access, it doesn't matter what OS it's on.
It is possible that what matters is the OS that created the image. Off the top of my head I can think of at least one OS-specific vulnerability - the random number generator (RNG). If the RNG that truecrypt uses is OS-specific (as in it uses an OS-provided system call to generate random numbers) then it would be plausible that containers created on just one OS are vulnerable while others are not.
Truecrypt might uses its own RNG, I don't know. I'm just pointing out a way that the OS might make a difference.
(Score: 2) by edIII on Saturday May 31 2014, @12:52AM
You would think that TrueCrypt would use whatever CSPRNG (Cryptographically-Secure-Pseudo-RNG) is available in the Windows cryptographic primitives, but it doesn't.
Very difficult to find any documentation because TrueCrypt not only crippled the encryption mode, but also removed all documentation of the RNG from their website (interpret that as you may)
I was able to find an audit paper [privacy-cd.org] that detailed the proprietary RNG used by TrueCrypt to some extent:
However, this is just key generation. Typical usage on a full volume encryption would absolutely have to use the cryptographic primitives found in the OS to provide the performance required. There is simply no way that TrueCrypt could gain enough entropy from the mouse alone.
Personally, I always found it somewhat suspicious that TrueCrypt refused to use the CSPRNGs available in modern cryptographic primitives... but then again... the NSA did an extremely good job of compromising the Dual Elliptic Curve Deterministic Random Bit Generator (Dual_EC_DRBG) [wikipedia.org], so their paranoia was not unfounded.
In any case, the CSPRNGs in cryptographic primitives on both Windows and Linux already make use of many non-deterministic activities within the OS and inputs (need a citation myself) that provide truly random numbers to /Random, which is where (IIRC) that /URandom gets its input to provide much larger amounts of random numbers needed to meet the demands of typical usage.
Considering that you have to trust your OS anyways (otherwise no reason to be running it or TrueCrypt) it doesn't make a whole heck of a lot of sense to create your own in that way. If they wished to use something different, then they should have proposed a new CSPRNG that could be included in the standard primitives.
It's a real fucked deal anyways since the NSA has practically committed a "scorched earth" tactic by leaving the entire world with zero confidence whatsoever in either the approval process for the NIST standards, or the current CSPRNGs that are there anyways.
So in the end, getting TRNG input directly from a source like a mouse to generate the key at least wasn't that crazy. It just could've been implemented a little better, and should have collected the same TRNG data that standard cryptographic primitives do, and then applied it's own CSPRNG to gain more volume if required.
(Score: 2) by frojack on Saturday May 31 2014, @01:44AM
I suppose it is precisely because the encryption primitives on windows is suspected to be hopelessly compromised that they went their own way on this.
If the machine was not compromised at the time these containers were created, it should remain uncompromised. So unless the truecrypt people suddenly found out there is a master key in Microsoft's encryption, I still see no reason for them to suddenly walk away from their product in despair. They could just fix their problem, apologize, and move on.
No, you are mistaken. I've always had this sig.
(Score: 2) by edIII on Saturday May 31 2014, @02:52AM
I agree about them fixing the problem and moving on, which is why I'm so troubled that they haven't made a full disclosure about what happened. The silence is deafening over there.
Without tearing apart the code myself, which is no longer available anyways, I strongly suspect that TrueCrypt *was* using a CSPRNG from the standard primitives, despite evidence to the contrary. It's not like we have access to documentation anymore; It's been removed.
I'm not sure that is true, and I'm pretty positive that's it not. Unless you are mounting a container as read only.
Key generation is only one activity related to initialization of a container. During normal use on a container TrueCrypt needs to provide itself with large amounts of random numbers. This is especially true if you are using Blowfish as one of the chained algorithms.
Moreover, during container creation that requires an incredibly large amount of high entropy random numbers to initialize the container. How could they achieve such volume both during key creation and container operations? TRNGs are wholly incapable of doing so without expensive dedicated equipment to provide it. Commodity hardware has no choice but to rely on CSPRNGs for the volume required in modern encryption use cases. So my gut tells me that they were in fact using the standard primitives.
Another checkmark in favor of TrueCrypt is that it has survived all kinds of attacks previously in the known literature. I heard rumors that some people claimed they could detect hidden containers, but no actual papers, citations, or proof of concepts. I've not heard one single court case where the government had defeated plausible deniability of the hidden container.
What changed? I suspect that TrueCrypt containers are at risk regardless of when or if the machine was compromised. I just don't know how.
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 1) by fnj on Saturday May 31 2014, @06:38AM
The source is still available. Everyone who ever downloaded it potentially has kept a copy. If you really want to reference it, it is no trick at all to find a copy.
(Score: 2) by dbot on Saturday May 31 2014, @12:03PM
Windows can't do it, so let's take our pid, and gettimeofday() and seed rand()? [6]
Both linux[1] and Windows Vista (onward)[2] are using fortuna[3], for their RNG. RNGs in Windows prior to Vista were vulnerable[4]. XP SP3 received a patch[5].
Even if you want to roll your own RNG, /which is a really, really bad idea/, you should at least XOR your stream with your OS's RNG. The resultant stream will be as random as the most random source, providing there is no correlation between the two sources (which itself would be hard to prove). You can see this if you take any stream and XOR it with {1}, {0}, or {01}. Using a predictable sequence does not affect the randomness of the stream.
1. https://www.schneier.com/blog/archives/2013/10/ins ecurities_in.html [schneier.com]t or_attack#Windows_implementation [wikipedia.org]m mand=viewArticleBasic&articleId=9048438 [computerworld.com]- openssl-codebase-does-get-the-time-add-it [opensslrampage.org]
2. http://eprint.iacr.org/2014/167 [iacr.org] (pp3 in abstract)
3. http://en.wikipedia.org/wiki/Fortuna_(PRNG) [wikipedia.org]
4. http://en.wikipedia.org/wiki/Random_number_genera
5. http://www.computerworld.com/action/article.do?co
6. http://opensslrampage.org/post/82975103611/so-the
(Score: 2) by maxwell demon on Saturday May 31 2014, @10:30AM
(Taking the liberty to remove stray characters from the quote and add proper formatting):
I wonder if that would still work with udev. But nevertheless, it's an interesting point; it means that before using /dev/random or /dev/urandom you should first make sure that they have the correct major and minor device number.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by Tork on Saturday May 31 2014, @04:11AM
🏳️🌈 Proud Ally 🏳️🌈
(Score: 2) by Angry Jesus on Saturday May 31 2014, @05:32AM
To over-simplfy: A good seed is just a starting point (that's why its called a seed). For any generator, if you start with the same seed you'll get the same list of pseudo-random numbers out of it. If the generator's algorithms are weak or somehow flawed, then even a purely random seed won't be enough to guarantee that the list of "random" numbers really is random.
Here's an explanation of how a deliberately weakened random number generator can be exploited, you don't really have to follow anything but the most basic math in the explanation to see how the end result is compromised.
http://numberworld.blogspot.com/2013/09/nsas-sp800 -90-dual-ec-prng.html [blogspot.com]
(Score: 2) by Tork on Saturday May 31 2014, @11:08PM
I appreciate it, thank you.
🏳️🌈 Proud Ally 🏳️🌈