Somebody who has been following TrueCrypt closely seem to think the project lost momentum and they just decided to call it quit.Their comment is on slashdot and the link is: http://it.slashdot.org/comments.pl?sid=5212985&cid=47115785
Makes the most sense yet. The question that was asked in response to that Slashdot post was why anyone would choose to quit the way they did (unprofessional and so on), and this doesn't sway me. If I lost my star dev and couldn't follow the code myself I might (speculation, as ever) well be petulant enough for this mess. There may be any number of factors behind it, ranging from animosity within the team to fear or self-doubt.
Truecrypt is dead, long live ChipCrypt: a Truecrypt fork with TRESOR and scrypt built in. TRESOR is a technique that keeps the volume key strictly in the CPU registers and not in RAM. This completely prevents RAM freezing and related attacks. A running computer that is locked cannot be trivially decrypted anymore by dumping it's RAM. Scrypt is an advanced password derivation function that makes even trivial passwords…
These two (TRESOR and scrypt) are incompatible, unless you allow for some time period where keys can be extracted. The point of scrypt is to be sequentially memory-hard: it mixes password and salt in a huge amount of RAM and makes it impossible to not use RAM for this operation.
I guess a stupid way to do that would be to prompt "This next step requires you to disconnect from the internet" and loop as long as 8.8.8.8 is pingable or something, then prompt when it's safe to reconnect.
This seems highly suspicious, especially the recommendation of BitLocker, a product we have little to no evidence does what it says and after PRISM, have no reason to trust[2]; not to mention it being limited to a (very small subset of) Windows platforms vs. TrueCrypt's cross-platform functionality. If this was legit[1], it'd probably be directing people to one of the other TrueCrypt-like programs. [1]The new version…
A screenshot that says "We have the recovery key", but zero indication of how they got it? The previous slide could not possibly be something related to dumping RAM, could it? Or perhaps an optional Microsoft-account feature to back up your encryption keys. Something that most normal users would want, just like they want it on Apple devices? Because a lot of common users aren't going to want FDE if it means "oh and l…
No, bitlocker explicitly send the key to MS for non-domain systems - as such, I would guess it potentially still does for those on a domain too, it'd just be kept quieter.
These two (TRESOR and scrypt) are incompatible, unless you allow for some time period where keys can be extracted. The point of scrypt is to be sequentially memory-hard: it mixes password and salt in a huge amount of RAM and makes it impossible to not use RAM for this operation.
I would say "complementary" not "incompatible". Once you have derived the key you can clear the RAM and keep the key on the CPU chip only. So there's a vulnerability window of a few seconds during which the key (or key related material) is stored in RAM, after which it can no longer be recovered. In sharp contrast with regular TrueCrypt where the master volume key is stored in RAM all the time. It's already standard…
Agreed. Only doing operations involving transferring the key to RAM when the user is present should mitigate it, perhaps with a prominent WARNING dialog showing when memory is vulnerable, and overwriting the memory locations used for the key when done.
"BitlLocker, the proprietary disk encryption program that ships with every Windows version since Vista." This is misleading - Windows 7 product line has Bitlocker only for Ultimate and Enterprise. Even Windows 7 Professional users cannot use Bitlocker without upgrading to Ultimate. Very unfortunate.
> Very unfortunate.
I wouldn't actually say that, but I see what you mean.
This seems highly suspicious, especially the recommendation of BitLocker, a product we have little to no evidence does what it says and after PRISM, have no reason to trust[2]; not to mention it being limited to a (very small subset of) Windows platforms vs. TrueCrypt's cross-platform functionality. If this was legit[1], it'd probably be directing people to one of the other TrueCrypt-like programs. [1]The new version…
Would this be a Lavabit-like situation? The governement asking for a backdoor and the developers are refusing it.
Suddenly (while there is an audit), they quit everything, change the assemblies and the website, so users can get to another product... It seems weird that after 10 years of hard-work, they suddenly quit without further explanation.
A screenshot that says "We have the recovery key", but zero indication of how they got it? The previous slide could not possibly be something related to dumping RAM, could it? Or perhaps an optional Microsoft-account feature to back up your encryption keys. Something that most normal users would want, just like they want it on Apple devices? Because a lot of common users aren't going to want FDE if it means "oh and l…
No, bitlocker explicitly send the key to MS for non-domain systems - as such, I would guess it potentially still does for those on a domain too, it'd just be kept quieter. http://windows.microsoft.com/en-us/windows-8/bitlocker-recov... Bitlocker is not trustworthy as an overall method of FDE.
Your link says "There are several locations in which your BitLocker recovery key might have been saved." and then mentions "Your Microsoft account online.". Do you know under which conditions this happens?