December 2003 - cypherpunks-legacy

Re: Breaking Legal News.... (fwd)
by Tim May 17 Dec '03

17 Dec '03

At 7:18 PM -0700 8/22/97, Greg Broiles wrote: >>The American legal system has spun out of control. I don't argue that she >>should not have the right to sue...everybody does. But a judge can quickly >>dismiss a case on a matter of law. > >According to the Mercury-News, the suit has been dismissed. > ><http://www.sjmercury.com/news/breaking/docs/016909.htm> Thanks for this info. I looked at it. Believe me, when I wrote my article this morning (Friday morning) I did not know this was happening. I wonder if Alan still thinks there is merit to the case? --Tim May There's something wrong when I'm a felon under an increasing number of laws. Only one response to the key grabbers is warranted: "Death to Tyrants!" ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^1398269 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

Re: Emergency File Wipe Algorithim
by Christian Wettergren 17 Dec '03

17 Dec '03

Someone proposed that one could wipe the memory before power-down, for example during 1 second or something like that. Unfortunately, that wont help, unless I misread the paper. It is effectively the same as if the key had been stored in the cell for 1 second less, nothing else. The only way I can see how to avoid generating "imprints" of more or less static data is to make them non-static. Start circulating them around. One way that springs to mind for keys are to do something like inverting the meaning of the key every x milliseconds. Like this; /* pseudo code */ char master_key[KEYSIZE]; int meaning = ZEROS; void encryption(char *input, char *output); /* implicit master_key */ int using_key = FALSE; main() { input_from_keyboard(master_key); timer(100 ms, flipem()); /* calls flipem every 20 ms */ main_loop(); /* occansionally using encryption() */ } void flipem() { if (using_key) /* risk of never being able to flipem() */ return; /* some kind of semaphored section */ using_key = TRUE; master_key = inverse(master_key); meaning = (!meaning); using_key = FALSE; } void encryption(char *input, char *output) { char real_key[KEYSIZE]; /* must be on stack */ copy_key(real_key, master_key); if (meaning == ONES) invert(real_key); /* recovering real content */ encrypt(input, output, real_key); write_random_key(real_key); /* so "real" key doesn't become imprinted as well. */ } Do don't care about the plaintext in the above. Nor stack content vrey much. Nor about coding style.

1 1

Identity Agnostic Online Cash
by cman＠communities.com 17 Dec '03

17 Dec '03

An early draft of a paper based on my comments at the Crypto '95 rump session is available at: http://www.communities.com/paper/agnostic.html Here's the abstract: Abstract: One of the unique aspects of Chaum's blind signature scheme for anonymous transactions is that it is practiced entirely by the side that wants to be anonymous. In a customer-bank relationship, the customer's software practices the technology, not the bank's. Chaum's patent on blind signatures cites as prior art a non-anonymous signature scheme that differs significantly only in steps taken by the "customer" side. An open standard for electronic cash would then allow a bank or other cash issuer to remain agnostic with respect to customer's software blinding or not blinding. Since the bank's software would be practicing technology cited as prior art by Chaum in his patent, and would have a substantial non-infringing use, I argue that the bank would not need to license Chaum's patents, provided the bank itself only provided non-blinding customer software. Here's a review of the talk by Hal Finney... :-) One of the more interesting talks I thought was from cypherpunk Doug Barnes, on "identity agnostic" electronic cash. This is basically an idea for creating a Magic-Money-type electronic cash server without violating Chaum's cash patent. What you do is to run the server and publish a spec it will follow. All the server does is do an RSA signature on the raw data it receives and decrement the user's account accordingly. The user has a choice of doing blinding or not on the signature. Chaum's patent covers the blinding, so if the user wants to do that he should be sure to license the patent or live somewhere it doesn't apply (or ignore it if he figures he's too small potatoes for them to care about). But the server isn't responsible for checking all this. It just does RSA sigs, which is prior art as far as Chaum's patent goes. Users can blind or not, it doesn't care. It is "identity agnostic" as Doug says. The implication is that with an RSA license you could run this kind of bank (online cash) and ignore Chaum's patents, while a horde of end users violate the patents but take safety in numbers and get anonymity. Lawyers like to go after big targets but the servers aren't violating anything.

1 0

Re: Acceptable NIS&T restrictions
by Bill Stewart 17 Dec '03

17 Dec '03

At 12:54 PM 9/4/95 -0400, Pat Farrell commented on the NIST's latest proposals for their September meeting on export controls and software with built-in government access to keys (GAK). I'll generally use the terms GAK or master keying rather than escrow, since escrow is a legal term that implies both the willingness of both parties to use it, and also that the escrowed material be delivered only when certain criteria are satisfied, which is out of the scope of almost any proposals I've seen labelling themselves "key escrow", particularly the Clipper system. Material with > and indentation are from the NIST paper; material with just > and 0-1 spaces is Pat's. 64 bits of keyspace is of course hopelessly inadequate for financial transactions - crackerboxes have been designed that allow very rapid breaking of single-DES or short-key RC4, and a useful platform needs to accommodate high-value transactions such as customers access to stockbrokers as well as more limited-value transactions such as credit cards where a $1000 cracking cost makes crime not pay well. The Administration argues that the limitation makes up for the possibility that users may find ways to evade GAK; but users can already do that now. > "Avoiding multiple encryption -- How can the product be > designed so as to prevent doubling (or tripling, etc.) the > key space of the algorithm?" >CME has been suggesting DES | TRAN | DES | TRAN | DES >for years. Can they really _avoid_ (i.e. prevent) this? (CME is Carl Ellison at TIS; tran is a simple transposition system.) Sure - if the software always tacks in master keys any time it does a symmetric-key encryption, and won't/can't decrypt without it, then DES+GAK | DES+GAK | DES+GAK is just as vulnerable to someone with the master key as single DES+GAK - it just takes three separate phases of key forfeiture to decode. (yes, I left out the tran phase; anybody going to that much work is using something other than the built-in encryption, at which point they might as well use non-government-approved encryption themselves.) Does it triple the key space? For people without the master key, yes, though maybe they get some known plaintext. For people with the master key, it depends on your definitions, and maybe _they_ put in some known plaintext that they don't give outsiders, but it probably doesn't lose them much. > "Disabling the key escrow mechanism -- How can products be > made resistant to alteration that would disable or > circumvent the key escrow mechanism? How can the "static > patch" problem be avoided? How can this be tested?" > >This is easy in hardware. Is it even possible in software? Probably. Consider the sort of master-key system where part of the session key isn't transmitted - maybe you do something like hash the user portion of the session key with the hash of the program and feed it to the KeyMaster's public key to get the session key. By the time you put all of that into Pretty Good PatchAround, you might as well just use PGP. > "Practical Key Access -- How can mechanisms be designed so > that repeated involvement of escrow agents is not required > for decryption for multiple files/messages during the > specified access period?" >At least this has a chance of being real. We need to have a suggestion >for expiration times for the escrowed keys. This was a huge problem with the >initial Clipper. Information can't be destroyed, only forgotten, so time-limitation is tough. What you can do is limit the scope of messages that can be decrypted by one trip to the keymaster - the Feds are looking for some mechanism so that any limits like this won't require multiple trips for one bunch of wiretapping. >Is there a reasonable middle ground between long term keys such >as PGP uses, and the ephemeral keys of a D-H exchange? What's reasonable? Some potential models for a PGPng would be - Use separate keys for signatures/keysigning and messages, so you could change your message key frequently while leaving your signature (or at least key-signature) key stable. (This tends to need an extra layer in the web of trust, since you now have two tiers for yourself, but no biggie.) - Diffie-Hellman kind of mechanism to encrypt the keys, with published g, p, g**x mod p, x changing frequently, RSA or DSS or whatever to sign the keyparts - this works better with a more interactive key negotiation so you can use a new x every time (e.g. request directly from the user, though that's difficult for email, or a keyserver that maintains a set of keys to be doled out.) > "Certified escrow agents -- Can products be designed so that > only escrow agents certified by the U.S. government (domestic, > or under suitable arrangements, foreign) are utilized? > What should be the criteria for an acceptable U.S. escrow agent?" The technical and political questions are quite different. Technically, you could have the software require a hierarchical-style certificate for the key-master keys with a US Government CA wired in. It's not totally foolproof - patching the CA is easy unless you've got some sort of checksum on the software. But it's a start, and it's simple enough that either the US could authorize separate versions for France or certify the French government's key-master agency. Also, there's a need for escrow/keymaster agents to be negotiable per-message - since escrow inherently requires the trust of all parties, and probably contractual agreements as well, and government-enforced keymastering may require satisfying multiple governments, parties will persumably have different lists of acceptable keymasters. >We all know that Tim's Flakey Key Escrow Service is most likely not >"an acceptable US escrow agent." But since CKE is a good thing, what >are the characteristics of an acceptable service to us? As far as the political criteria go, I believe the traditional formulation is along the lines of "I am not now, nor have I ever been, a member of...." :-) Establishing criteria is difficult, and depends on whether the whole system will be defined by laws passed by Congress or only by organizational policy; there are also issues of control between the Commerce Department, NIST, NSA, and the State Department. For Commercial Key Escrow, or commercial key-backup services, the criteria are "whoever can be trusted to provide the services the customers want". In this case, of course, the service most customers want is to be left alone, or, failing that, to have the government's Master Key system provide minimal risk to the security of the actual transactions - 64 bit keys are not enough security for any high-valued financial transactions, though they may suffice for credit cards. One required characteristic would appear to be either sufficiently deep pockets to collect judgements for violations of trust or a sufficiently high reputation that violations of trust are not expected. Most of the commercial market for key escrow or backup services fits into three categories - backups for the owner/sender of a file (which they can provide themselves, using techniques like PGP's Encrypt-to-Self option, or file backups with secret-sharing), acknowledgements of transmission (signed hashes would do), and dispute-resolution issues (verifying the contents of a message which may require information from both parties or ephermeral session key information.) Most can be provided by the kind of services currently provided by companies like bonding agencies, emergency backup and offsite storage companies, etc. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Fecundity, evolution, & extenction (references)
by Jim Choate 17 Dec '03

17 Dec '03

Hi, If you are interested in the subject of evolution and the various theories that are competing for pre-imminence then check out: The Origins of Order: Self-organization and selection in evolution S.A. Kauffman ISBN 019507951-5 $32.00 Beyond Natural Selection R. Wesson ISBN 0-262-73102-9 $14.95 Embryos, genes, and evolution: The development-genetic basis of evolutionary change R.A Raff, T.C. Kaufman ISBN 0-253-34790-4 The evolution and extinction of the Dinosaurs D.E. Fastovsky, D.B. Weishampel ISBN 0-521-44496-9 ____________________________________________________________________ | | | Participation requires more than just bitching! | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http:// www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

1 0

Re: Basic Public key algorithms.
by Bill Stewart 17 Dec '03

17 Dec '03

At 01:01 PM 9/2/95 CDT, droelke(a)rdxsunhost.aud.alcatel.com (Daniel R. Oelke) wrote: >After doing quite a bit of poking around, I am somewhat discouraged >in my attempts to find a simple *pure* public key encryption method, >without a lot of other stuff wrapped around it. Pure public-key is usually not very useful, since it's rather slow for encrypting big messages by itself. PKP has the patents to all public- key systems until mid-1997, and for RSA until some time like 2001, and Schnorr for longer. Unfortunately, RSAREF (except for one version where they slipped) requires non-commercial users to limit themselves to the published interface or get explicit permission, and the published interface always throws in DES with a random key for encryption. Since you're talking embedded systems, you're probably commercial and high enough volume that the cost for licensing RSA is probably low enough. >What I need is to encrypt between 45 and 55 bits of information >using a public key algorithm in an embedded environment. 45-55 bits may be tough, depending on the constraints of your environment - most public-key systems need 768-1024 bits of key to be reasonably secure, and need to send an output field at least that long to be decodeable. If that's not a problem, you've got some choices. For instance, you could use Diffie-Hellman to create a shared secret, and just XOR that with your material (have the workstation generate a master x, g, and p, and store g**x in your embedded system; choose a random y each time, and send g**y mod p and the first |M| bits of (g**xy mod p) xor M. To do that, you need to store g**x, g, and p, possibly in ROM, and enough code to do modular exponentiation and random number generation; hopefully your system will have some kind of quasi-physical source of randomness. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Q: PGPfone where
by microbody＠wirepool.ruhr.de 17 Dec '03

17 Dec '03

Hello, guys! I just want to know where to get PGPfone outside the USA. Ciao! /\/\icroBod\/ |\?/| SoziBits <---- Anschlaege Drogen Waffen / \______/ | I | Falken im Netz RAF ETA KGB LSD XTC BND

1 0

Shooting the taggers
by Wazoo MixMaster 17 Dec '03

17 Dec '03

Tim May wrote: > And yet can J. Random Businessman defend his property against this > defacing? Nope. The cops say "Let us handle crimes." But they don't. > > There's a solution for taggers: snipers. There appears to be a wonderful market for long-range nonlethal stun weapons. I wonder, if a tagger is marking your building, would it be legal to stun him from a distance and then call the cops? Rape can be argued to be deserving of serious punishment of some kind, but would tagging deserve death when a nonlethal option exist? Could not the woman stun the rapist and then call the cops? -THE LIE

1 0

(NOISE) Re: e$: More fun with cash: Senate Bill 307
by Bill Stewart 17 Dec '03

17 Dec '03

>I had heard that it was the Columbians, branching out from the cocaine >business with those fancy new copy machines, which are supposed to be >able to duplicate the blue & red threads in US currency paper. But if the government was _serious_ about supply-side drug-trade reduction, wouldn't they _encourage_ this sort of thing? After all, that way the Colombians can make as much money as they do today without the bother of hauling all that white powder into the US? :-) (Sure, it's a cypherpunk topic, after all real crypto is mainly about economics and threat analysis :-) >See, when the GOVERNMENT spends money, it creates jobs; whereas >when the money is left in the hands of TAXPAYERS, God only knows >what they do with it. Bake it into pies, probably. Anything to >avoid creating jobs. -- Dave Barry #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Re: Shooting the taggers
by John Smith 17 Dec '03

17 Dec '03

>>>There's a solution for taggers: snipers. >From: Jonathan Wienke <JonWienk(a)ix.netcom.com> >Speaking as a father and as someone who has been followed by gang members >on numerous occasions after witnessing a gang assault and providing >information to the police, I am in agreement with Tim May. You agree that the solution for taggers is snipers? You agree that children who paint graffiti should be shot, perhaps killed? >I don't want my >child to be corrupted or assaulted by worthless, predatory scum. There >would be much less gang crime if private citizens could cane or otherwise >deal with gangsters when they caught them in the act, pour encourager les >autres, like. Your own child gets a ride home with a crowd of high-spirited troublemakers, and on the way home they bash in J. Cypherpunk's mailbox with a baseball bat. JC appears on his porch and rakes the car with his AK-47, killing all on board. Is this justified? "John ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1