[IP] more on Can you be compelled to give a password?

[Travis H.]

On 8/8/06, Ed Gerck <edgerck at nma.com> 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 majordomo at metzdowd.com