4 ms·

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 r

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 very hard to bruteforce. A scrypt derived key is 20000 times harder to crack than the equivalent PBKDF2 derived key of the same password. The TrueCrypt license is not GPL compatible but it allows redistribution in source form as long as the software is not called "TrueCrypt". Who's up for it ?

dchest 12y ago
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.
- cornholio 12y ago
  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.
  - blueskin_ 12y ago
    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.
    - cornholio 12y ago
      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.
      - skycrypt 12y ago
        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.
- spiritplumber 12y ago
  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.
  - mseebach 12y ago
    It would be stupid, yes :) 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.
rflig2 12y ago
"Who's up for it ?" Neither Google (no hit) nor Wikipedia [0] You might want to provide a link to the softwares homepage as well as additional information? [0] https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_...
al2o3cr 12y ago
"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." Until an interrupt happens, and the handler saves the registers on the stack. (sad trombone)
- cornholio 12y ago
  Actually, they use the internal CPU debug registers which aren't automatically saved - in fact they whole purpose is to trigger a context save when the hardware break-point is hit and invoke the debugger. If breakpoints are disabled, using 8 1 bit flags contained in the registers, you have a whooping 6x32-8=184 bits of storage on x86 and 376 bits of storage on x64.

dchest 12y ago

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.

cornholio 12y ago
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.
- blueskin_ 12y ago
  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.
  - cornholio 12y ago
    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.
    - skycrypt 12y ago
      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.
spiritplumber 12y ago
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.
- mseebach 12y ago
  It would be stupid, yes :) 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.

rflig2 12y ago

"Who's up for it ?" Neither Google (no hit) nor Wikipedia [0] You might want to provide a link to the softwares homepage as well as additional information? [0] https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_...

al2o3cr 12y ago

"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." Until an interrupt happens, and the handler saves the registers on the stack. (sad trombone)

cornholio 12y ago
Actually, they use the internal CPU debug registers which aren't automatically saved - in fact they whole purpose is to trigger a context save when the hardware break-point is hit and invoke the debugger. If breakpoints are disabled, using 8 1 bit flags contained in the registers, you have a whooping 6x32-8=184 bits of storage on x86 and 376 bits of storage on x64.