On 8/8/06, Ed Gerck <[EMAIL PROTECTED]> wrote:
The worst-case setting for the user is likely to be when the coercer can do all that you said and has the time/resources to do them. However, if the distress password is strong (ie, not breakable within the time/resources available to the coercer), the distress password can be used (for example) to create a key that decrypts a part of the code in the binary data that says the distress password expired at an earlier date -- whereas the access password would create a key that decrypts another part of the code.
So the opponent then knows the password given to him is not valid, and might continue to search for a current one. And/or step through the program with a debugger, like a software cracker removes copyright protection.
There are other possibilities as well. For example, if the binary data contains code that requires connection to a server (for example, to supply the calculation of some function), that server can prevent any further access, even if the access password is entered, after the distress password is given. The data becomes inaccessible even if the coercer has the binary data.
Or, nobody has the data: http://monolith.sourceforge.net/ http://www.schneier.com/blog/archives/2006/03/monolith.html It seems clear that the data used to create the protected plaintext has to be only completely in the hands of the opponent, to prevent its use, or to mediate the exchange in some active sort of way. Perhaps tamper-resistant hardware like the crypto iButton could play a part here (it's FIPS-140 rated, under $75 for a single unit, and can be programmed in java). Sometimes it's better that you aren't able to do something... so that you can't be compelled to do it, like having a time-lock on a bank vault. The way to do that is tamper-resistant hardware and/or "trusted computing", so that you don't care (much) if the opponent acquires it, too. Elaborating on your idea of "the two keys decrypt different parts of the ciphertext", the iButton spits out keys that are used in a steganographic file system, so that the duress password gives one set of innocuous data and silently zeroizes the real stego key, while the real password yields the real key to the stegfs, and nobody can prove anything about the protected plaintext without that key -- that's crucial to deceiving the opponent that the duress password was indeed genuine, which prevents you from being punished for giving a duress password post-facto. Wiping the ciphertext gives away the gambit, but in cases where one doesn't care about that then it wouldn't be a bad idea. Couple this with a dead-man's switch; you have to use the ibutton every two weeks or else it deletes the real key upon next power-up. Now you need merely do nothing for two weeks to defeat the opponent. If forced to use it, one uses the duress password, and opponent is defeated without him knowing. If the tamper-resistant hardware has a power supply and clock, it can zeroize itself after two weeks, instead of waiting for the next power-up, which is important if one wants to have a short window for attacking the hardware. Alternately, the system containing the ciphertext needs to be powered on and running an internal clock. Another method involves a tamper-resistant token a la SecureID, in which case keys generated in odd minutes are duress keys, and keys generated on even minutes are real keys. Or vice-versa of course. Those lacking tamper-resistant hardware could substitute a system running at a remote location for said hardware. A related link is the cryptography using simulated satellites, or something like that... Fast data-deletion is a good case where information-theoretic security is undesirable; one wants a small key (relative to the plaintext), so that zeroization is fast and requires little power by the embedded hardware under attack. This suggests ECC at the present.... -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]