SoylentNews is people
SoylentNews
from the some-settling-of-contents-may-have-occurred dept.
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 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