4 ms·

Is there an encryption method that renders my password only valid for <frame>? And I am only able to set a new password and reset <frame> when authenticated? Th

Is there an encryption method that renders my password only valid for <frame>? And I am only able to set a new password and reset <frame> when authenticated? That is, if I do not authenticate and reset in time, the volume has no known password? Unlike a dead man's switch, I don't actually want the volume to be touched -- anything destroyed.

Deestan 13y ago
Pedantically, no. An encryption method can't depend on time, as you could just make up a date to send through the encryption/decryption function. The encrypted volume handler could do this if you could guarantee it had an active agent running, and no-one powered down the system and/or copied the disk before the timeout. Which I guess is practically "no", as: 1. If someone arrests you and confiscate your equipment, they are going to switch it off immediately. 2. They would try to extract data directly from the disk instead of booting up your system. 3. I can't imagine a scenario in which you want the deadman switch to go off before you are arrested.
anonymous 13y ago
For instant messaging, I suggest using one-time keys which aren't stored and not keeping any logs. In effect, once your client is switched off, any data collected is impossible to be decrypted, since the keys are lost and you never knew them yourself in the first place. For data you want to hide, use TrueCrypt (or similar) to encrypt most of your hard-drive and set up two keys - one which unlocks the illegal data and one which unlocks the legal data. It is important that you keep as much of your mostly legal data under the first key and only store truly problematic data (like pirated mp3s, the map to your secret hideout, etc) in the other. It's really hard to fabricate a ton of clean data and I think it's best if you simply encrypt everything you can and keep a tiny portion hidden.
jzwinck 13y ago
Maybe we can design one using https://www.btproof.com/ https://www.btproof.com/ ? That system lets us permanently store timestamps with roughly hourly precision along with 160 bits of arbitrary data. This would let us, for example, find the (earliest) time a password was set, so we could know if it is too old. But there's still a lot to be figured out here, and I'm no cryptanalyst. For starters, can the decryption system know it is seeing the "real" Bitcoin blockchain and not that of an interloper?
- tlrobinson 13y ago
  If someone has a copy of the encrypted file on hardware they control then there's absolutely no way to prevent them from modifying the software/RAM to fool the decryption routines into using a fake timestamp/blockchain/whatever. You'd need tamper-proof hardware.
  - malandrew 13y ago
    I reckon you could make hardware tamper-proof by setting the hardware in a booby-trapped container that would self-destruct if tampered with. Make sure that the only two connections coming out of the booby-trapped container are power and a data connection over which the memory of the device cannot be accessed, such as ethernet.
  - rdl 13y ago
    You could build something where the human never had the actual key. The human has a passphrase which goes to a piece of hardware with the actual key, either tamper-responding physical hardware with a clock, or some kind of network service (e.g. a .onion service) which takes the user's passphrase and returns a key. As long as the user (or subverted hardware) doesn't retain the actual key each time, it's probably ok, and protected from this particular case of compelled disclosure. The ideal is to use some kind of tamper-responding hardware to process the data (as well as decryption), though. And probably locally -- I don't think I'd trust an .onion service to stay up if it disappearing meant I would no longer have access to my files.

Deestan 13y ago

Pedantically, no. An encryption method can't depend on time, as you could just make up a date to send through the encryption/decryption function. The encrypted volume handler could do this if you could guarantee it had an active agent running, and no-one powered down the system and/or copied the disk before the timeout. Which I guess is practically "no", as: 1. If someone arrests you and confiscate your equipment, they are going to switch it off immediately. 2. They would try to extract data directly from the disk instead of booting up your system. 3. I can't imagine a scenario in which you want the deadman switch to go off before you are arrested.

anonymous 13y ago

For instant messaging, I suggest using one-time keys which aren't stored and not keeping any logs. In effect, once your client is switched off, any data collected is impossible to be decrypted, since the keys are lost and you never knew them yourself in the first place. For data you want to hide, use TrueCrypt (or similar) to encrypt most of your hard-drive and set up two keys - one which unlocks the illegal data and one which unlocks the legal data. It is important that you keep as much of your mostly legal data under the first key and only store truly problematic data (like pirated mp3s, the map to your secret hideout, etc) in the other. It's really hard to fabricate a ton of clean data and I think it's best if you simply encrypt everything you can and keep a tiny portion hidden.

jzwinck 13y ago

Maybe we can design one using https://www.btproof.com/ https://www.btproof.com/ ? That system lets us permanently store timestamps with roughly hourly precision along with 160 bits of arbitrary data. This would let us, for example, find the (earliest) time a password was set, so we could know if it is too old. But there's still a lot to be figured out here, and I'm no cryptanalyst. For starters, can the decryption system know it is seeing the "real" Bitcoin blockchain and not that of an interloper?

tlrobinson 13y ago
If someone has a copy of the encrypted file on hardware they control then there's absolutely no way to prevent them from modifying the software/RAM to fool the decryption routines into using a fake timestamp/blockchain/whatever. You'd need tamper-proof hardware.
- malandrew 13y ago
  I reckon you could make hardware tamper-proof by setting the hardware in a booby-trapped container that would self-destruct if tampered with. Make sure that the only two connections coming out of the booby-trapped container are power and a data connection over which the memory of the device cannot be accessed, such as ethernet.
- rdl 13y ago
  You could build something where the human never had the actual key. The human has a passphrase which goes to a piece of hardware with the actual key, either tamper-responding physical hardware with a clock, or some kind of network service (e.g. a .onion service) which takes the user's passphrase and returns a key. As long as the user (or subverted hardware) doesn't retain the actual key each time, it's probably ok, and protected from this particular case of compelled disclosure. The ideal is to use some kind of tamper-responding hardware to process the data (as well as decryption), though. And probably locally -- I don't think I'd trust an .onion service to stay up if it disappearing meant I would no longer have access to my files.