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: SSL Cert Prices Notes
On Mon, 7 Aug 2006, John Gilmore wrote: Here is the latest quick update on SSL Certs. It's interesting that generally prices have risen. Though ev1servers are still the best commercial deal out there. The good news is that CAcert seems to be posistioned for prime time debut, and you can't beat *Free*. :-) Startcom (http://cert.startcom.org/) also does free low assurance certificates. Their CA has already been accepted for the next major release of the Mozilla products and, unlike CAcert, has undergone an independent audit. See also http://www.hecker.org/mozilla/ca-certificate-list for Mozilla's list of CAs and their status. -d - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL Cert Prices Notes
John Gilmore wrote: Date: Sun, 6 Aug 2006 23:37:30 -0700 (PDT) From: [EMAIL PROTECTED] Subject: SSL Cert Notes Howdy Hackers, Here is the latest quick update on SSL Certs. It's interesting that generally prices have risen. Though ev1servers are still the best commercial deal out there. The good news is that CAcert seems to be posistioned for prime time debut, Based on my experience with CAcert, that statement strikes me as a bit optimistic. And yes, I am a CAcert assurer (currently ranked #151) and I follow all the mailing list discussions etc. But AFAICS, prime time is a ways off for CAcert. and you can't beat *Free*. :-) SSL Certificate Authorities VerificationSubdomains Too Low HighLow High Verisign$399$995 Geotrust$189$349$599$1499 Thawte $149$199$799$1349 Comodo / instantssl $49 $62.50 $449.95 godaddy.com $17.99 $74.95 $179.99 $269.99 freessl.com $69 $99 $199$349 ev1servers $14.95 $49 CAcert FreeFreeFreeFree Have you looked at StartCom? https://cert.startcom.org/ Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
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?
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: SSL Cert Prices Notes
On Mon, Aug 07, 2006 at 05:12:45PM -0700, John Gilmore wrote: The good news is that CAcert seems to be posistioned for prime time debut, and you can't beat *Free*. :-) You certainly can, if slipshod practices end up _costing_ you money. Has CAcert stopped writing certificates with no DN yet? Has CAcert stopped writing essentially unverifiable (or, if you prefer to think of it that way, forensics-hostile) CN-only certificates on the basis of a single email exchange yet? Has CAcert stopped using MD5 in all their signatures yet? Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
compressing randomly-generated numbers
Hey, I was mulling over some old emails about randomly-generated numbers and realized that if I had an imperfectly random source (something less than 100% unpredictable), that compressing the output would compress it to the point where it was nearly so. Would there be any reason to choose one algorithm over another for this application? I recall talking to a CS prof once who said that LZW compression was optimal, which seemed and still seems really odd to me because optimal compression would generate a null output file. So surely he meant asymptotically optimal, or e-close to optimal, or something like that... anyone know? Obviously I will avoid any fixed-content headers and magic numbers by using a raw implementation of the algorithm, not reusing, say, gzip. Plus, I will be running as though the RNG was providing me with an infinitely long string, not reading everything into memory and trying to compress. It seems as though the Burroughs-Wheeler Transform (bzip2 et. al.) gets the best compression of the standard utilities... is it suitable for infinite length strings? Is there anything better? -- 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]
