Blind signatures with DSA/ECDSA?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here is the blind DSA signature based on MacKenzie and Reiter, http://www.ece.cmu.edu/~reiter/papers/2001/CRYPTO.pdf, in graphical form. Recall that a DSA public key is p, q, g, y; private key x; signature on hash h is: Choose k < q r = g^k mod p mod q s = rx/k + h/k mod q Output (r,s) Here is the blind signature protocol, with Alice, the recipient, on the left and Bob, the signer, on the right: Alice (recipient) Bob (signer) - Choose k2 < q z2 = 1/k2 mod q Send r2 = g^k2 mod p <--- Choose k1 < q r = r2^k1 mod p mod q Send a=E(r/k1 mod q) and b = E(h/k1 mod q) and ZKP --> Check ZKP Choose d < q^5 Send c = a '*' x*z2 '+' b '*' z2 '+' E(d*q) <--- s = D(c) mod q Output (r,s) Here, E() and D() represent encryption and decryption in a homomorphic encryption system like the Paillier encryption. Only Alice knows the private key, but Bob is able to multiply encrypted values by scalars (indicated by '*' above) and to add encrypted values (indicated by '+' above). ZKP sent by Alice in the 2nd step is a zero knowledge proof that the two encrypted values are known and are < q^3. (Actually the values are less than q but the standard ZKP for this has some slop in it, which is OK for this purpose.) Bob operates on the two homomorphic encryptions of r/k1 and h/k1. He multiplies the first by x/k2 and the second by 1/k2 and adds them to get rx/k + h/k mod q (where k = k1*k2), exactly as required for the signature. Then he adds the large multiple of q to fully hide his secret x value. One interesting thing about this protocol is that it may escape the Chaum blind signature patent, US 4759063, for two reasons. First, the Chaum patent covers three step blinding, while this is a four step process. In the regular Chaum blind signature there is no need for the initial step where the signer sends an initial r2 value. That step is crucial here; k2 must be fresh for every signature or the signer's key is leaked. Second, the Chaum patent describes the signer's operation as performing a public key digital signature operation. This is in fact how the Chaum blind signature works; the signer does do an ordinary RSA signature operation. But in this case, the signer performs a completely different transformation, working with two homomorphically encrypted values in an unusual way. This is not a conventional digital signature operation. Therefore this type of blind signature should escape the patent. Of course the patent expires in a little over a year so it is largely moot now anyway. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFAirIcHIAd9K7kkjIRAk/nAJ0cIxTYSudiKd0rrXv/T1kUuMHbjQCfSaya NmVhsnuT/jBeqf5eVIx2FaI= =x3ps -END PGP SIGNATURE-
Re: [IP] One Internet provider's view of FBI's CALEA wiretap push
> underground railroad would have worked better, but your still black. Obviously you don't know about whitening properties of moder ciphers! Seriously, today the distingushing marks among classes, tribes and castes are far more informational than physical. So today crypto *can* make you white, or better to say discoloured. = end (of original message) Y-a*h*o-o (yes, they scan for this) spam follows: __ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25ยข http://photos.yahoo.com/ph/print_splash
Duress, Watermarking, a simple design
Specificiation For A Duress File System. Disguised as a Watermark Annotation Management System Maj. Variola (ret), the OsamaSoft Corporation --- Background: To deter torture, physically *destroy* your data. If you can't destroy it, you need a *duress* system. It will at least buy some time. Specs for a duress system: Adversary can't know if there's more data You can reveal multiple passphrases to satisfy the Adversary (incl. false data) The former requires stego, otherwise the Adversary could tell that there's more data. The latter requires that your stego'd info doesn't interfere with other stego'd data. Simple Multiple-Use Implementation: Treat the cover media as a block-sized filesystem. The user must specify (and keep track of) the index of the block to embed the payload. To extract data, only a passphrase (not index) is needed if a checksum accompanies data in each occupied block. Multiple blocks can be embedded using the same passphrase, they are all decoded when that passphrase is supplied. (I don't think its possible to store allocation info *in* the file without giving away the presence of more occupied blocks!) Usage: As a watermarking system, anyone can embed any type of watermark in a "block" so long as block occupations are tracked globally. eBay could stego-watermark images in the upper left quadrant, individuals get to use the upper right. Each could use their own watermarking tools. As a collaborative tool, if the annotations are all plaintext this could be like writing comments on the back of a JPG. With the convenience of keeping them with the image. As a duress file system, the watermarks are secret data. They are compressed, encrypted, then embedded in the given block of the cover media. It would be smart to use boring annotations in some blocks so that its not unusual to use the tool with the cover media. (One should also use layers of increasingly sensitive info to give up gradually, as well as plausible fakes.)
Re: cop-proof disk drives
On Sat, 24 Apr 2004, Bill Stewart wrote: > That's really overkill. Computers these days have enough > horsepower to run file system encryption in the CPU. That's true, but it's possible to get access to the key in memory. Once the machine is compromised, the keys are leaked. It's true that when the machine is compromised the plaintext data may be leaked, but it's more difficult to inspect and transfer couple gigs of data than just the key and then come and haul away the machine. Or to compromise the encryption software itself. It's much more difficult to do that with a hardware unit (and much more difficult if the case was eg. spot-welded - you still can get inside using power tools, but not without visibly damaging the case). Another advantage of a pure-hardware solution is independence on software, thus no risk of present nor future incompatiBILLities. > If you want to get fancy about rubber-hose prevention > and avoid the except-for-terrorism clause in the 5th amendment, > you could do something with secret-sharing with your > unindicted co-conspirators (oh, wait, they don't bother with > indictments these days, do they?) so that all of you > need to cooperate in a challenge-response thing > to restart some of the services. I'd suggest a m-of-n scheme because of reliability issues. It won't be good to lose all data because one of the co-conspirators died in a car crash. > Or you could hide that little 802.11 widget on the shelf > that stores one of the keyfiles you need to > access the secure drive. Once UWB's widely available, > it'll be better for that (lower power - harder to detect.) A 802.11 standalone data storage unit (I think they're on sale already) hidden under the floor, over the ceiling, or between the drywalls could do the job nicely. > Just make sure that your system _is_ restartable after > power failures, because those are a much more likely event > than cop invasions. Reliability vs security is a big dilemma. Maybe a good approach could be forgetting the key if the machine is moved without telling the processor guarding the key that it should stop watching a movement sensor for a given time interval, or after entering a wrong (or kill-) PIN? A power blackout then won't affect the operation, but switching the equipment off and hauling it away would destroy the keys. Same as an attempt to bruteforce the access code, or opening the machine case by force.
Re: [IP] One Internet provider's view of FBI's CALEA wiretap push
On Fri, 23 Apr 2004, A.Melon wrote: > Are there any publicly available documents that detail interrogation > protocols and what brainwave patterns and bloodflow look like during truth > telling and lying? Preferably something that gets into how to consciously > alter brainwave patterns and bloodflow with this application in mind... There is other possibility how to "beat" interrogation - suitable only for some subsets of situations, when the organization design is prepared for this. Tell them all. Tell them the truth. Make sure in advance that you can afford to do it without telling them what they need/want to know - design the system the way you won't be *able* to know the information that could endanger the "important" parts of your system/organization.
Re: [IP] One Internet provider's view of FBI's CALEA wiretap push
Major Variola writes... > If you physically destroy the keys or the data, there is little to gain by > torturing you or your family. That is superior to gambling that your > deeper duress levels are convincing to the man with the electrodes. Are there any publicly available documents that detail interrogation protocols and what brainwave patterns and bloodflow look like during truth telling and lying? Preferably something that gets into how to consciously alter brainwave patterns and bloodflow with this application in mind... A document with a thorough discussion of various depressants on such an interrogation process would also be most interesting. We all know that no lie detector is not perfect, but trying to convince captors that I'm part of a minority of subjects -- those who appear to be lying when they're not -- is not my idea of fun.
Re: cop-proof disk drives
That's really overkill. Computers these days have enough horsepower to run file system encryption in the CPU. (If you remember 5-10 years ago, computers in those days had enough horsepower to run disk compression in the CPU, and CPU speed has increased a lot faster than disk throughput since then.) Build the system with an inactivity timeout for /home if you want. Swap space has the advantage that it doesn't need to preserve state across system reboots, so you can run an encrypted swap partition that generates a random key at boot time. If you want to get fancy about rubber-hose prevention and avoid the except-for-terrorism clause in the 5th amendment, you could do something with secret-sharing with your unindicted co-conspirators (oh, wait, they don't bother with indictments these days, do they?) so that all of you need to cooperate in a challenge-response thing to restart some of the services. Or you could hide that little 802.11 widget on the shelf that stores one of the keyfiles you need to access the secure drive. Once UWB's widely available, it'll be better for that (lower power - harder to detect.) Just make sure that your system _is_ restartable after power failures, because those are a much more likely event than cop invasions.
