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 operating procedure for law enforcement to time raids when the computers are in use and make a dump of the machine RAM.
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.
Truth be told, if RAM is a security liability for the few seconds it takes to enter the password and derive the key, then you can't give any security guarantees whatsoever no matter what algorithm you use, scrypt, PBKDF2 or any other.
It's not like you can punch the password into the CPU directly, you need to use some sort of input device which has drivers which keep state in RAM, use DMA and IRQs etc. Any attacker capable of reading RAM during this phase is also capable of sniffing the password characters as they are typed on the keyboard.
If we keep thinking on tine slices of time, even a shoulder surfer attack (with cameras in case of a pass-phrase :)) can be a problem... We are not talking about how to prevent a break during the time when the user is typing the password (torture attack is still a valid one and no technology will ever prevent it). But I like good ideas: once mounted, the password cannot be retrieved as it's stored in the chipset itself... I don't know if the test pins on those processors will make this vulnerable but it worth a try-catch. And if Windows go into sleep/hybernate, you loose the password and have to mount again to restore operation. This is possible as we mount the driver as a removeable media.
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.
If someone has remote control of your computer, they'd install a sniffer that picks up the password and sends it back next time there's an internet connection.
