Re: [IP] more on Can you be compelled to give a password?
On 8/8/06, Travis H. <[EMAIL PROTECTED]> wrote: Or, nobody has the data: http://monolith.sourceforge.net/ http://www.schneier.com/blog/archives/2006/03/monolith.html Grr... remind me not to read the comments on old blogs, it's irritating to see so much misrepresentation... The monolith model is being misrepresented. The problem is this: User A publishes fileA.mono, a file of apparently randomly-generated bytes. That's all the information you have. Has he, or has he not, infringed copyright? You must be answer this question before "going after" him. So you do some research, and find (among other things), user B's fileB.mono and user C's fileC.mono, both apparently randomly-generated. fileB.mono XOR fileA.mono yields a copyrighted work. fileC.mono XOR fileA.mono to produce something in the public domain. Now, who has committed what crime? Things get even more complicated with more files, and they need not bear ".mono" extensions. What is fileA.mono XOR fileB.mono XOR fileC.mono? Now add in ten thousand more files... I bet with the proper combinations you can create just about anything, and anyone at any time may create a file that when combined with another, is infringing. That is, Mallory may have published fileM.mono, and fileM.mono XOR fileC.mono is infringing; who is guilty of infringement, or framing the other user? Remember timestamps are trivially forged and lost during some copy operations, so you don't know who published first. You also don't know how they came up with their files, as bits don't have color. -- "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]
Re: [IP] more on Can you be compelled to give a password?
On 8/9/06, Ed Gerck <[EMAIL PROTECTED]> wrote: A debugger cannot decrypt without the key, which is produced only with the access password. Ah okay. By the way, an interesting link from Schneier's blog, mentions copyright and randomly-generated numbers: http://ansuz.sooke.bc.ca/lawpoli/colour/2004061001.php -- "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]
Re: [IP] more on Can you be compelled to give a password?
Travis H. wrote: So the opponent then knows the password given to him is not valid, and might continue to search for a current one. Not likely for the same data. After all, the data is protected by a password that "expired". And/or step through the program with a debugger, like a software cracker removes copyright protection. A debugger cannot decrypt without the key, which is produced only with the access password. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [IP] more on Can you be compelled to give a password?
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]
Re: [IP] more on Can you be compelled to give a password?
Ariel Waissbein wrote: Please notice that a second "distress" password becomes useless if the would-be user of this password has access to the binaries (that is, the encrypted data), e.g., because he will copy them before inserting the password and might even try to reverse-engineer the decryption software before typing anything. So I'm not sure what is the setting here. 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. 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. Another possibility is to combine the above with threshold cryptography. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [IP] more on Can you be compelled to give a password?
Hi, Please notice that a second "distress" password becomes useless if the would-be user of this password has access to the binaries (that is, the encrypted data), e.g., because he will copy them before inserting the password and might even try to reverse-engineer the decryption software before typing anything. So I'm not sure what is the setting here. Cheers, Ariel Ed Gerck wrote: > List, > > the Subject says it all. This might be of interest > here, for comments. > > > The answer is definitely NO even for the naive user, > just requiring the tech-savvy for set up. Several > examples are possible. > > John Smith can set two passwords, one for normal use > and the other when in distress. The distress password > may simply announce that the data is expired or, more > creatively, also make the data unreadable. > > John Smith can also set two passwords, one of them > unknown to him but known to a third-party (that > John S does not have to trust) that is subject to > a different jurisdiction /or rules /or is in another > place. John Smith may comply with any demand to > disclose his password but such a demand may not be > effective for the third-party. > > John Smith can have the data, encrypted with a key > controlled by his password, sitting on some Internet > server somewhere. John S never carries the data > and anyone finding the data does not know to whom it > belongs to. > > John Smith can also use keys with short expiration > dates in order to circumvent by delay tactics any > demand to reveal their passwords, during which time > the password expires. > > Of course, this is not really a safe heaven for > criminals because criminal activity is often detected > and evidenced by its "outside" effects, including > tracing. > > Cheers, > Ed Gerck > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [IP] more on Can you be compelled to give a password?
List, the Subject says it all. This might be of interest here, for comments. The answer is definitely NO even for the naive user, just requiring the tech-savvy for set up. Several examples are possible. John Smith can set two passwords, one for normal use and the other when in distress. The distress password may simply announce that the data is expired or, more creatively, also make the data unreadable. John Smith can also set two passwords, one of them unknown to him but known to a third-party (that John S does not have to trust) that is subject to a different jurisdiction /or rules /or is in another place. John Smith may comply with any demand to disclose his password but such a demand may not be effective for the third-party. John Smith can have the data, encrypted with a key controlled by his password, sitting on some Internet server somewhere. John S never carries the data and anyone finding the data does not know to whom it belongs to. John Smith can also use keys with short expiration dates in order to circumvent by delay tactics any demand to reveal their passwords, during which time the password expires. Of course, this is not really a safe heaven for criminals because criminal activity is often detected and evidenced by its "outside" effects, including tracing. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
