December 2003 - cypherpunks-legacy

Re: GAK/weak crypto rationale?
by Andrew.Spring＠ping.be 17 Dec '03

17 Dec '03

>intercepts requested and authorized in the past year. As I recall, the >number was quite small - around 12K [?]. Someone had found this out >through an FOIA request, perhaps, (my recollection of it is poor). It was I think it's about 1200. >not a large number, anyway. I must conclude that the actual number of >intercepts is much, much larger than they are saying, and that they must >be getting what they perceive to be good intel from all this snooping. > A more cautious conclusion would be would be that the importance (to the LEA's) of the busts made with crypto is much larger than the numbers suggest. You could interpret that a lot of ways: I suspect that high-profile career-enhancing cases are highly dependent on wiretaps.

4 4

remailer abuse
by Greg Broiles 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Remailers exist (at least mine does) to make possible the dissemination of unpopular views. "Unpopular" depends on context; so does "abuse". The line between "unpopular" and "abuse" is difficult to draw. On the one hand, the recent "Mr. Pedophile" message seemed intended to make the recipient uncomfortable or offended probably because of illegitimate reasons (purportedly, pedophilia). Other messages which cause complaints seem to be responses to something that the "victim" has done or said somewhere else. It's tempting to say that a message which lays out in logical fashion coherent arguments explaining why the "victim's" original message is wrong is likely to cause discomfort or embarassment but is legitimate, while a message which says, to quote from a complaint message I received this weekend, "Fuck you asshole. I hope you choke on your son's sperm." isn't legitimate even though it may also cause discomfort or embarassment. So I guess it's not so much a message's effect upon its recipient (or its intended effect) which is legitimate or illegitimate as it is the message's means of doing so. And that seems really tough to judge, where a remailer operator doesn't know the context in which a message is sent. (I do think it's possible that the "Mr. Pedophile" message was sent by another child or teenager intending to torment the target, not by an actual pedophile. It's possible that the sender was the target himself. It's also possible that the sender was an actual pedophile or a child-hostile adult, but that's not the only plausible explanation. People do strange, strange stuff.) In a situation where person A uses system X to send messages to person B who uses system Y, I'm not sure what B can expect from the system operator of system X. (I'm thinking about net custom here, not law.) If A wants to send messages to B, but B doesn't want to receive them, should A be forced to stop sending? Does X have an obligation to make A stop? Does X have an obligation to modify his system such that messages from A to B are automagically suppressed? Does X have an obligation to refuse service to A (and forego payment for service from A) if A won't stop sending to B? Is the answer different if B doesn't want the messages because they (are likely to) contain profanity? or because they are from a person of the wrong religion? or because they're hostile or argumentative? As a first response I'm likely to say that if A knows (or should know, or can guess and be pretty certain of the result) that B doesn't want to get a particular message, A shouldn't send it. But then I realize that there are a number of exceptions - what about if A's message to B is in response to a spam or otherwise inappropriate message from B? what about where B owes A money? or if B has said something ridiculous or stupid and A is writing to correct B? I think that there wouldn't be many inappropriate posts sent to the C-punks list, for example, if everyone who thought a post was inappropriate (not just factually arguable, or uninteresting) sent a message to that effect; the impact of just a few hundred such messages in reply to a single message would likely be burdensome enough to make the sender think twice before sending again. But that inconvenience is anticipated by (and motivates) the senders of those hundreds of messages. I still don't think it's wrong to send the messages. I guess my point is that eliminating "abuse" is pretty much impossible because abuse is in the eye of the beholder. I don't think we need to rely on the mercy or good graces of the net at large, though - remailers will likely prove to be as difficult to eliminate as spammers have been. The net is too big to be centrally policed, and individual providers often have an incentive to tolerate behavior otherwise frowned upon because they're being paid to do so. (and if they begin content filtering they may lose any sort of quasi-common-carrier status they might enjoy now, viz _Cubby v. Compuserve_, etc.) Even if the United States adopts rules requiring messages be identified as to the sender, it won't be possible to eliminate overseas remailers - and I imagine that folks would just start up pseudonymous remailers. (I've worked on some prototype code and will deploy a pseudonymous remailer - where people get names like "fjones(a)pseudo.goldenbear.com <Frank Jones>" instead of "an12345(a)pseudo.goldenbear.com <Anonymous Sender>", in order to divert or confuse anti-anonymous policies or programs.) I think adopting a submissive or apologetic stance with respect to the operation of a remailer is a mistake. What we do is protected by the First amendment, supports a 200+ year tradition of anonymous political speech in America, provides a valuable service to a worldwide community, and can help avoid the very abuse they are accused of facilitating. The child who was the target of the "Mr. Pedophile" message(s) should have been taught how to use remailers and how to maintain his privacy on the net so that, if he really is the victim of some sort of random child stalker, it won't happen again. There's no reason why any child should post to the net under their real name, or why their messages should be traceable to their physical bodies. If we're concerned about protecting kids from bad people who might reach them via the net, we need to teach kids how to send untraceable and unreplyable messages; how to send messages and do business on the net without allowing hostile or unscrupulous people to track them down; and how to make good choices about revealing personal information only to people who have a good reason to know it. People who are the targets of abusive messages or are concerned about abusive messages are some of the people who need remailers and need pro-privacy network tools the most. Giving in to a knee-jerk anti-privacy reaction only reinforces the erroneous notion that security is created by an enforced lack of privacy. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMK/ZRn3YhjZY3fMNAQHQkQQAmLlRGcwEbJyhb9dYm3dx/BoRj0NBTUr3 MOmRkP2+AtdCKL8gcaWhnY9TeXHj7enezo5TF8ooqvcOLEha29mL9Q+G08t2pkoM SGHr79Yr38syc6Mf+1pXAN7T1Dn600xgnJsDmrFFoQI5H0ZSeA6oLT3ShzhWpsJ/ 3FuNvR7TyLg= =nsOZ -----END PGP SIGNATURE-----

2 1

Re: Elliptic Curve Public Key Crypto available
by Andrew Loewenstern 17 Dec '03

17 Dec '03

> Previous to the availabilty of 100 MHz processors this method of > public key crypto was ridculously slow. The only versions were > laboratory curiosities implemented in ASIC hardware. Code, if it > exists, is not in the public domain. What about NeXT's Fast Elliptic Encryption (FEE)? Their research guy, Richard Crandall, came up with major speedups to elliptic curve encryption. In fact, there was a simple cryptosystem that shipped as a demo with NeXTSTEP 2.0. What was most interesting about this system was that it didn't store any keys anywhere; your public/private key pair was generated _on the fly_ from your passphrase every time you encrypted or decrypted....on a 25mhz 68040 too... and it was fast! It wasn't that great of an implementation (you _really_ need a lot of bits of entropy in that passphrase, and you can't change your passphrase without changing your PK), but it shows how fast NeXT's speedups are. And this was in 1990... I'm not sure if the speedups are patented, but you could try a literature search. If it really is fast then it could mean good things for servers that need to do a lot of enrcyption/decrption for interaction with clients. andrew

2 1

Cypherpunk Certification Authority
by Aleph One 17 Dec '03

17 Dec '03

Since now Netscape allows for user defined certification authorities I would like to hear some ideas for a Cybpherpunk CA. Probably run by one of the respected member in the group such as Sammer, Perry or Tim. I would like to hear some discussion about creating the certificates based on the web of trust of your PGP key, etc. Any takers? Aleph One / aleph1(a)dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01

12 13

Re: Certificate Authorities?
by Jeff Weinstein 17 Dec '03

17 Dec '03

We are looking at adding the ability for enterprise security administrators to lock various parts of the Navigator configuration so that the user can not change them, including stuff relating to trust and certificates. This functionality will not be in 2.0, but we do consider it important for certain customers. --Jeff P. Rajaram wrote: > Yes. But... > I deal with the security infrastructure for a large corporation. > I want only security administrators to configure the list of acceptable CAs. > I specifically do not want our users to be able to add new CAs > to the list of trusted "approved" CAs. > > The concern is that some users who are not crypto enthusiasts may be > "social engineered" into adding a very liberal CA to their list. > Once this happens, the browser's signature verification capability > is totally compromised. > > This is one of the reasons why PGP has not been adopted by many large > companies. In response, Viacrypt now seems to have a product that > can restrict user modifications to the public keyring. > > -raj -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw(a)netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.

2 3

Re: Returned mail: User unknown
by aba＠dcs.exeter.ac.uk 17 Dec '03

17 Dec '03

[whoops mispelled cpunks on cc line 1st time, sorry for 2 copies] Perry Metzger <perry(a)piermont.com> wrote: > Gary Jeffers <gjeffers(a)socketis.net> writes: > > Well, I just used MIT's PGP 2.6.2 with 3 different users' public > > keys to encrypt 3 different files. In all 3 files, the first 3 > > characters were the same (an umlauted A, then an i with an up arrow > > over it, and then a heart). This beginning 3 character string is > > apparently the infamous PGP RSA signature. The signature that says > > to spooks' programmed encryption sniffers - "HEY! I'M PGP - GIVE ME > > A LOOK!." > > As if they couldn't figure it out anyway. It isn't an "RSA signature" > by the way. Read format.doc sometime. Yeah, that's what stealth does, removes the boiler plate stuff saying, various things, such as pgp version number, rsa encrypted message, conventional idea block, and as Perry says, it's all in pgformat.doc in the PGP docs directory. > > When are the PGP designers and coders going to get serious and de- > > velope STEALTH PGP inside PGP itself!? > > Never, I hope. It would dramatically lower the utility of the > system. Can you imagine how disgusting it would be to try decrypting > something if you have a dozen keys outstanding? Not to mention how > hard it would be to deal with figuring out that you should even try to > decrypt things in the first place. I reckon it would be a very nice utility, built into pgp as an *option*, some countries it isn't legal to use PGP, and it hasn't been ruled out that the US may not be the next to join the list, all this GAK stuff, son of Clipper, it is a distinct possibility that the law enforcement lot might outlaw other crypto wiht mandatory GAK. Then stealth features for PGP become important for incorporating into stego, of course you can argue that well stealth should be part of the stego app then. It shouldn't be a problem unless it was enforced, as an option I see no problem with it, and lots of possible future advantages even. I'm trying to work on stealth2.1, modifing Henry Hastur's stealth util to added Hal Finney's algorithm for improving the stealthiness (it's not enough to just strip the headers as stealth1.x does, the fact that the RSA encrypted header is always < N, the rsa modulus gives the game away with a few messages to analyse for statistical purposes, ie if you see a lot messages < N, where N is by definition not an even power of 2, and possibly even N is known, or suspected from keyservers). I've been delaying releasing it because I was worrying about ran no generators being good enough, but I think I might have convinced myself that it is not even necessary to use ran no generators, I'd appreciate it if some folks with a bit of crypto expertise could cast their eye over the description below. > > So what, -that "only a few companies" will be discovered to be using PGP > > through the RSA signature!? Those few companies are the seeds for the > > vast numbers of companies that would follow them in using PGP over the > > Internet. The RSA signature is the flag that allows the spooks to easily > > net the bold first companies. The RSA signature is greatly impeding the > > spread of PGP use over the Internet. PGP MUST BE STEALTHED!! > > It isn't an RSA signature. Its a bunch of magic numbers. > > Look, get real already. If someone sees a bunch of random numbers in > mail sent by me, its going to be pretty obvious what the hell is > inside anyway. Yeah, but you wouldn't do it that way. I reckon this is what you'd do: % pgp -es duress % pgp -es msg % stealth < msg.pgp > msg.stl % cat msg.stl >> duress.pgp % pgp +makerandom=1234 noise % cat noise >> duress.pgp % pgp -a duress.pgp % mail someone < duress.asc The pgp +makerandom=<size> <file> is an undocumented feature of pgp > 2.6 (not sure exactly when it got added, Colin Plumb pointed it out when I asked him about ran nos for stealth). So what this means is that you are using PGP it's self to hide a stegoed message. This would be good for the guy from FACTnet (forgotten his name) who just got hit by the CoS, he could hold out for a while, then give up his key, the duress message would appear, and the real message would be explained by having a script to do this on his HD, and having long since burned the disk with a script to do the above on it: % pgp -es msg % pgp +makerandom=4567 noise % cat noise >> msg.pgp % pgp -a msg.pgp % mail someone < msg.asc ie the idea is that you pad your message to a fixed size for the express purpose of hampering traffic analysis (of the type of my, Alice did have a lot to say to Bob that day). It would be even better cover if the thing had gotten sent through a remailer, as this kind of thing is expected of type I remailer traffic (before mixmaster which does the packetizing for you). So the duress message really looks like this: +---------+---------------------------+--------------------+--------+ | pgp hdr | IDEA encrypted duress msg | stealthed real msg | noise | +---------+---------------------------+--------------------+--------+ the IDEA block has a length field, but you can increase the length without damage to include the following stealthed stuff as the underlying stuff which is IDEA encrypted will know it's length on decryption, and the following junk will just be discarded. So, Alice and her secret key ring (encrypted) gets nabbed by the Charlie (CoS?), and coerced into divuling her passphrase. And if and when it is noticed that the message was longer than it ought to be (CoS that smart? substitute the NSA and they'd notice for sure), Alice explains away the junk on the end by pointing them to the fact that all of her messages where exactly (say) 16k long, and that she was using a the noise only script, and that the message really is this: +---------+---------------------------+-----------------------------+ | pgp hdr | IDEA encrypted duress msg | noise | +---------+---------------------------+-----------------------------+ Now we come to arguments about why you might want this built-in to PGP. Well it provides plausible deniablity as you have no extra software which might look incriminating unless you managed to dispose of it first, if it comes as stock. Also the 2nd reason for built-in at least for stealth is if it needs good random number source, but as I said, I'm not sure it needs a random no generator. So comments please, this has been around a few times already, but here's the algorithm for manipulating x which is the RSA encrypted component of the header of an RSA+IDEA encrytped PGP message: (this is a description of my implementation of Hal's algorithm as described on his www page: http://www.portal.com/~hfinney/) consider random no x, RSA modulus N 1 < x < N (that used to say 0 <= x < N, but 0, and 1 being RSA fixed points, 0, 1, and N won't be generated by PGP presumably? I think this shouldn't matter as the keyspace of N is so large that the probability of a 0 or a 1 specifically is nothing to worry about I think.) Hal's algorithm was to convert x to being in the range: 0 <= x' < lim where lim which is the next power of 2 above N * 2^surety, and surety is 64, 64 seems big enough? The recover operation is: x = x' mod N and the create operation is: 1) scale = int( (lim-1) / N ) + 1 2) scale2 = 2^int( log2( scale ) + 1) ie scale2 = next power of two over scale 3) r = MD5( 0, x ) ie MD5 digest of x, as x is an RSA encrypted random session key misc other info, and more random padding to bring up to be close to N in size. It strikes me that we already have a random number, and that provided MD5 can not be inverted (which it is not possible, as it is compressing, and looses info, and the brute force to find which of all the possible y's (0 < y < N) MD5 digests come out to be x. I would have thought it likely that this would be evenly distributed, and that the cost would be enormous? 4) r = MD5( r, rand() ) it will fail some of the time, so in this case repeat with another random number, Istirred it in first but perhaps you would only do it if it failed. Or perhaps it is enough to MD5( r, r ) ie stir r into itself to generate another ran no? So long as there are no rare cycles? Presumably either impossible or infinitessimally small probability. 5) r = r mod scale2 6) if (r > scale) goto 4) 4),5) & 6) are designed to generate an evenly distributed random number in the range: 0 <= r <= scale 7) x' = N * r + x 8) if (x' > lim) goto 4) an example, with small numbers, and surety set to 8, x = 7, and manufactoring the ran nos manually: lim = 2^( int( log2(N) + 1 ) + surety ) = 2^( 4 + 8 ) = 4096 1) scale = int( 4096 / 13 ) + 1 = 316 2) scale2 = 2^( int( log2( scale ) ) +1 ) = 2^(8 + 1) = 512 3) say MD5( x ) = 0x00000000000000000000000000001234 4) say MD5( x, rand ) = 0x00000000000000000000000000001235 = 4661 (base 10) 5) r = 4661 mod scale2 = 4661 % 512 = 53 6) if ( 53 > 315 ) - it's not 7) x' = N * r + x = 13 * 53 + 7 = 696 8) if (696 > 4096) - it's not) so x' = 696 reversing: x = x' mod N = 696 mod 13 = 7 when 6) is true, ie r > scale which will happen half the time on avg with the first ran no, and so on like a coin flip, the chances of many coins flipping the wrong way diminishes rapidly with number of flips. when 8) is true, ie x' > lim, x' can only be > than lim when x = N - 1, and given that x = N - 1, the probability is less of x being in N * scale <= x < lim but this will only occur with probability: 1 1 -------- < ----- 2^surety scale I think. So you'd have to collect one mess of messages to even catch one sample, let alone enough messages to have a statistical proof of steganography being present. Pls check the maths a bit, the above describes the software implementation of Hal's algorithm which he has on-line, on his page: http://www.portal.com/~hfinney/ But the main question I'd like to get verification on is if it is safe to use the MD5 of the RSA encrypted message to perform the operation. I'm essentially doing: x' = N * f(MD5(x)) + x where f(y) is a function which converts from range 0 <= y < 2^128 to a range 0 <= f(y) < scale. Is that safe? x is random, and will be different even for a repeat encryption of the same file, as PGP is using a random IDEA session key. So are there any brute force attacks on that which would be cheaper than attacking 128 bit IDEA? PGP's random number generator also makes extensive use of MD5, so I'm taking the use of MD5 as secure as a given. If it is thought to be dangerous for some reason (it is after all some kind of signature on it's self, presume that you know N, and x' but not x, the question is can the equation be brute force reversed in a less than 128 bit brute force attack. I'm neglecting to consider the rand() calls, which I'm not expecting to add security, but are just a mechanism to stir the value with to get more random nos, as occasionally the alogrithm needs more than one, if the first fails, etc. If people reckon it's insecure, then it would be ideal to include the stealth functionality into PGP, so that integral use of PGPs ran no routines can be made. I was previously using an MD5 digest of PGPs randseed.bin for this, but you can't stir it (well you could but that would considered a security risk diddling with PGPs files), and not stirring means you have no improvement over the above, in the event that that your system is captured with the known plaintext. If you stirred it there would be no proof of that being the message in the file. Even unstirred, if the N * f(MD5(x)) + x is no good, the inclusion of a digest of the randseed.bin would be a big improvement. It seems rather messy to have all of the keyboard sampling stuff, for PGP keys duplicated for this. Hope the x' = N * f(MD5(x)) + x construct is secure as this will avoid the issue. Adam

1 0

Re: "Got a subpoena?"
by Jeff Hupp 17 Dec '03

17 Dec '03

On 30 Nov 95 at 12:56, Jay Campbell wrote: : >> "finessing" laws will become more important. In short, they WILL have : >> a subpoena--then what? : > : > Then they'll find out that I don't have any information that : >could help them, anyway. : : What about a court order to (a) start comprehensive logging, and (b) not : tell anyone under penalty of ______ . And at that point, you shut down the remailer and log each and every bounce. Now, they could get an order forcing you to run a remailer ~ but that would open up a whole new can of worms i.e. can you be forced, under court order, to commit a crime? -- JHupp(a)gensys.com |For PGP Public Key: http://gensys.com |finger jhupp(a)gensys.com Autocracy is based on the assumption that one man is wiser than a million men. How's that again? I missed something.

2 1

Re: Digital Fingerprinting
by Peter Trei 17 Dec '03

17 Dec '03

> Finding the mail mixed in there is evidence that supports the "charge" > but surely can be rebutted. When I was practicing in a small town c. > 1984, people would be summoned (sent a paper telling them to show up) to > court for illegal dumping if their mail was found with other trash, old > refrigerators, etc., in a creek somewhere. Those charged could always > put on proof that Billy Bob's garbage service picked up their trash ... > The sentence was almost always to go and pick up some multiple of the > garbage found and take it to the landfill. This was Stockbridge, in MA, right :-? That's what we did, and drove back to the church, had a thanksgiving dinner that couldn't be beat, went to sleep and didn't get up until the next morning, when we got a phone call from officer Obie. Said "Kid, we found your name on an envelope at the bottom of a half a ton of garbage, and just wanted to know if you had any information bout it". I said "Yes Sir Officer Obie, I cannot tell a lie, I put that envelope under that garbage." (c) Arlo Guthrie Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

3 3

Re: Questions/Comments on ecash protocol
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

At 22:40 12/2/95, Michael Froomkin wrote: >thank you for the sterling analysis. I for one am following this with >enormous interest, even though some of the details are lost on me right now. [Well done, Ian!] [...] >1) What information about Charlie/customer is encoded onto the coin? None. >(There must be some, right, since the serial number is blinded?) Since the >bank doesn't know what serial number it is signing, it needs to put info >about Charlie onto the coin so that it can track him down if he double >spends. Lacking such info, the bank can refuse to honor a double-spent >coin, but has no way to know who the double-spender is. Since an online clearing protocol is being used, the bank has no need to identify double spenders. The bank will simply refuse to honor a double spent coin. In fact, cancelling a payment in this protocol is done by just depositing the coin yourself. >3) Is there a way [how hard is it] for charlie to extract a coin and >either > (i) copy it and/or > > (ii) send it to David [3rd party] in such a way >that David could insert it into David's MTB software and then spend it to >Sam without Sam or the Bank noticing that anything was wrong. If Charlie >and David do this, David now has a coin that is from his point of view >both payee and payor anonymous, although Charlie has a risk that David >will double-spend and expose Charlie to the bank's wrath. I can't help the feeling that I am missing something whenever you bring up this question. Assuming it could be done. What would David gain? He as the payor is anonymous to Sam either way. Sam still would have to be worried about being identified, since if Charlie gives David access to Charlie's wallet, it is safe to assume that Charlie will give David (and the mint) access to his blinding factor. Which in turn would reveal Sam as the payee. The protocol you suggest gives the parties exactly what they would have if they just used Ecash "out of the box": full payor anonymity, no payee anonymity. So why bother? <insert standard disclaimer here> -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred.

2 1

Zensoren ueber Alles
by tallpaul＠pipeline.com 17 Dec '03

17 Dec '03

>From initial reports, the challenge to CompuServe did not come from the German government. It did not come form the German Parliament. It did not come form the German judiciary. It came from one (repeat one) prosecutor in one (repeat one) city. I also suspect the U.S. journalists who reported the news may not know the difference between a "prosecutor" and a "procurator." It is a significant differnce in many legal systems. (Not to slag U.S. journalists too hard because I myself don't know which of the two Germany has.) The news reports on New York City television focused exclusively on the "sexual" character of the banning, without directly mentioning that other groups were also banned. "But," wrote Jonathan Oatis of Reuter in an article available on the Clarinet news feed, "many more span a host of topics, including Barney the dinosaur of children's television, Estonian politics and the New York Yankees baseball team." Also included in the reports of news groups banned is the clari.news.sex feed containing articles routinely filed by the Associated Press and Reuter. It has also been reported that self-help recovery groups were banned because the groups also had the word "sex" in the name. (In order to save the victims it was necessary to destroy them!) How did the 11 o'clock news here in New York handle the story? Two of the three channels stated that CompuServe banned "chat rooms," not news groups. The third got it right and reported on internet groups. The two channels who spoke of the "chat room" ban also stated that the rooms were banned because they contained "explicit" sexual images or graphics "depicting" sexual topics. What can we infer? No single thing directly save for the inaccuracy of the reports. But certainly even national-level tv editors are not yet sufficiently informed about the internet to know the difference between chat rooms and news groups. I'd say that this level of ignorance rather impacts on their ability to do their job in a professional fashion. (It also points to our collective failure to adequately inform them.) Second, the editors -- whether under pressure of deadline, personal psychological bias, or more sinister things -- can't pick up the idea that the verbal ("chat") and the visual ("explicit" sexual images) are two different things. Third, the sexual hysteria of the editors themselves significantly erodes their ability to perform their jobs in an objective fashion. CompuServe also got off easy under initial press inquiry. One spokesman for the company announced they were required to do it. He also stated that there was no way to cut the German customers off from the groups will making the groups available to other CompuServe customers. Based on other news reports, I conclude that CompuServe lied in both areas. (BTW, this is the first time I recall using the word "lie" on any post to the cypherpunks list.) I also infer that CompuServe did not "roll over" on this issue. The evidence shows, I think, that CompuServe is merely using one German prosecutor (or procurator) as an excuse to implement their own desired and previously prepared policy. CompuServe had, I think, several actions open. First, if the news reports that it was not "forced" to do anything by the single German, it could simply not have done anything. Second, it could have appealed the decision by the prosecutor to the courts (or submitted accurate information to the procurator and demanded that he consider it.) Third, it could have narrowly targeted the banned groups to alt.binary groups dealing with sexual issues. Fourth, it could have easily used software to cut off the feed to Germany. It did none of these things. It cut off all customers to an enormous number of groups. It inferrentially violated property rights (i.e. contracts) to customers promised internet access and now provided only a crippled version thereof. And it lied about the whole thing. Interestingly, none of the classic cypher-nasties were behind CompuServe's decision. The "big statists" in Washington didn't tell CompuServe to do it. The "hell with private property rights" bureaucrats didn't force CompuServe to do it. Nor did the taxman. The taxmen historically rarely do; they do not seek to ban "sin;" they tax it. The Treasury Department's Bureau of Booze, Butts & Bazookas (aka Bureau of Alcohol, Tobacco, and Firearms) is not behind this country's anti-booze, anti-butt, or anti-bazooka movement. They just tax all three. (They may kill you if you buy, transfer, or manufacture your bazooka without paying the US$ 200 (?) excise tax, but they're not out there in the forefront of those pushing gun control.) Additional facts that will be forthcoming in the future will point, I believe, to two things behind CompuServe's decision. The two leading causes will, I predict, be: First, the growing abstract systemic fear in this society produced by a society in crisis. This is a fear unnaturally re-directed at things like PGP and anonymity by various political poo-bahs to both deflect the citizens' fears from real causes and to rechannel that fear into areas where the same poo-bahs can claim credit for doing the "something" in "something has to be done." Second, the growing sexual hysteria within large sections of the population that does not exist in an abstract form and is not being artifically rechanneled but rather appealled to. CompuServe, in a rather brilliant move, managed to handle both groups, and blame a foreign force to boot. But while brilliant tactically, I do not believe they will succeed in continuing their policy. --tallpaul

2 1

Re: Guerilla Internet Service Providers (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > From owner-cypherpunks(a)toad.com Mon Jan 1 17:53:37 1996 > Message-Id: <199601012332.PAA10533(a)desiree.teleport.com> > Subject: Re: Guerilla Internet Service Providers > To: cypherpunks(a)toad.com > In-Reply-To: Your message of Mon, 01 Jan 1996 13:41:13 PST. > <v02120d09ad0e047046b5(a)[192.0.2.1]> > Date: Mon, 01 Jan 1996 15:32:37 -0800 > From: Felix Lee <flee(a)teleport.com> > Sender: owner-cypherpunks(a)toad.com > Precedence: bulk > > Lucky Green: > > Some site in physical space has to host the nntpd, the ftpd, and the httpd. > > That site will be subject to search, seizure, and arrest and conviction of > > owner. > > but if it turns out that 30% of home PCs have to be seized to prevent > dissemination of dangerous-information-X? > > though we're not quite there yet... eg, it's a little expensive to run > your own httpd 24 hours/day. > -- > If you live in the Austin, TX area I will setup a dedicated slip for you at only $100/mo.

3 2

Payment Systems
by rah＠shipwright.com 17 Dec '03

17 Dec '03

--- begin forwarded text From: "John Hemming CEO MarketNet" <JohnHemming(a)mkn.co.uk> Date: Tue, 12 Sep 1995 15:38:00 PM PDT To: www-buyinfo(a)allegra.att.com Mime-Version: 1.0 Subject: Payment Systems For the edification of those concerned we have issued our first Electronic Cheque today. The browser now has been tested linking signed instructions directly to the web. The browser, however, is still being developed to resolve the problems with shortage of space in Windoze DGROUP. There is a copy of the browser at ftp://193.119.26.70/mktnet/pub/echeque.zip (or something similar) we would recommend waiting a while before you take it however and to take the horse.zip as well because of the DGROUP issue). The only form that will accept Echeques at the moment is http://193.118.187.107/load ordflow The trick in this form (if you are using our browser) is that it allows payment either by ECheque or by credit card and only generates the signed instruction for echeques. The signed instruction is then sent to our servers encrypted with 128 bit RC4. ttfn John --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

NOISE.SYS /dev/random driver for DOS, v0.3.3-Beta
by wlkngowl＠unix.asb.com 17 Dec '03

17 Dec '03

The leatest version is ready to be examined. Much rewriting. Send a message with the subject "send noise033" and an automated responder should eventually send you a uu-encoded Info-Zip file with a compiled version of the driver, assembler source-code, and pgp-sig. Again, comments & criticism would be appreciated. Help is especially needed trying to find IRQs to sample for sources of randomness. Finding a good way to sample mouse or video scan lines would also be a help.... etc. --Rob

2 1

PGP duress code, and stego (was Re: PGP in UK - snooped unSTEALHed?)
by aba＠dcs.exeter.ac.uk 17 Dec '03

17 Dec '03

erm darn, I posted a huge post which should have the above subject, but instead came out with the subject line: Re: Returned mail: User unknown due to typo, could someone replying please correct that, if following up, I won't bother posting it again in respect of those who actually pay for their mail feed per k. It had a lot of questions which I'd really like people to look at, skip back a few, and take a read, it's for the implementation of stealth2, Henry Hasturs stealth util. Adam

1 0

NSA says strong crypto to china??
by Jeff Weinstein 17 Dec '03

17 Dec '03

This is a quote from an article by Paul Vallely in The Independent, London, which can be found here: http://nytsyn.com/live/News3/006_010696_101827_2723.html > What one government regards as harmful material is an instrument of freedom > and democracy to another. Officials at the US National Security Agency have > suggested that Internet encryption technology - a sophisticated method of > encoding information - be deliberately exported to Chinese dissidents to > help them in their fight against their government - even though its export > is otherwise banned under US arms control regulations. Does anyone know of real documentation of this "suggestion" from the NSA? It quite telling, though no surprise to any of us I'm sure, that they would think that strong crypto should be a tool of freedom in china, but not in this country. Maybe they should get Microsoft to insert subliminal directions for downloading PGP into a future episode of "My Computer Family". :-) --Jeff Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw(a)netscape.com - http://home.netscape.com/people/jsw/ Any opinions expressed above are mine.

7 6

Whitehouse responds to Zimmermann pardon letter
by an215712＠anon.penet.fi 17 Dec '03

17 Dec '03

---------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. If you reply to this message, your message WILL be *automatically* anonymized and you are allocated an anon id. Read the help file to prevent this. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi.

1 0

NIST conference summary in CDT
by K. M. Ellis 17 Dec '03

17 Dec '03

The Center for Democracy in Technology policy posting no. 24 provides a pretty good summary of the NIST conference. If anyone is interested, e-mail me privately and I can forward it to you. -=Kathleen M. Ellis=- kelli(a)zeus.towson.edu Geek Code v3.0 http://zeus.towson.edu/~kelli/ GAT dx s++:- a-- C++ uu+++ P+ L++ E- W++ N K W--- O- M- V-- PS+++ PE- y+>+(-) PGP+>++ t+ 5 x+ R tv b+++ DI- D--- G e h* r+ z** Diverse Sexual Orientation Coll.Towson State University DSOC(a)zeus.towson.edu

1 0

When they came for the Jews...
by Duncan Frissell 17 Dec '03

17 Dec '03

********* Citing ``the rapidly expanding presence of organized hate groups on the Internet,'' a leading Jewish human rights group [the Simon Wiesenthal Center] on Tuesday began sending letters to hundreds of Internet access providers and universities asking them to refuse to carry messages that ``promote racism, anti-Semitism, mayhem and violence.'' But Cooper said the ``unprecedented potential and scope of the Internet'' gives people ``incredible power to promote violence, threaten women, denigrate minorities, promote homophobia and conspire against democracy.'' He cited the posting of instructions for making explosive devices, including recipes for Sarin nerve gas and bombs similar to the one that destroyed the Federal Building in Oklahoma City last April 19. *********** In reading the above from today's NYT, I was interested to see the expansion of the protected classes who are not to have unkind things said about them on the Nets. Aside from the usual list of suspects, I noted that *democrats* were also to be protected. I thought that "conspiring against democracy" (something I do daily) was classic political speech and and activity that even the drafters of the American Constitution practiced from time to time. I guess I'm going to have to watch my attacks on democracy if I don't want to get my Net access cut off. DCF "I favor discrimination on the basis of race, creed, color sex, age, alienage, previous condition of servitude, recent interstate travel, handicap, sexual or affectional preference, marital status, Vietnam-era veteran status (or lack thereof), occupation, economic status, and anything else I can think of."

14 15

DC-C'punks meeting
by pfarrell＠netcom.com 17 Dec '03

17 Dec '03

Sorry to waste list bandwidth for the 600 folks too far away to care about this... The next DC-area c'punks meeting will be September 16, it will be at the Digex headquarters offices in Beltsville, probably starting about 3:00 PM. Digital Express Group 6800 Virginia Manor Road Beltsville Maryland 20705 (301) 847-5000 Directions to DIGEX >From the Washington Beltway (I495) in Maryland, take Route 1 North. drive on Route 1 a few miles, maybe as many as three or four. You will see a Ritz Camera Center. Turn left onto Ritz Way. At the second street, turn Right onto Virginia Manor Road. You are now near 6800 Virginia Manor Road. Digex is the last building on the Right. If you need more information, email me, or see my http://www.isse.gmu.edu/~pfarrell/dccp page. Pat Pat Farrell grad student http://www.isse.gmu.edu/students/pfarrell Infor. Systems and Software Engineering, George Mason University, Fairfax, VA PGP key available via finger or request #include standard.disclaimer

1 0

Re: Netscape to patch shareware version
by carolann＠censored.org 17 Dec '03

17 Dec '03

As fast as it takes to FTP it over there. I have copies of every server Netscape's got, although I haven't unpacked them or used them. Will this take up another 75 megs on the HD? Lover Always, Carol Anne.....dreaming of her own web server someday. >| Meanwhile, in an as yet unannouced move, the company said it would place >| its commercial browser online for free downloading. [..] THe commercial >| version, sold only in the U.S. contains an unbreakable 128-bit >| encryption scheme. >Ok, any bet on how long it will take? > >/Christian -- Member Internet Society - Certified BETSI Programmer - Webmistress *********************************************************************** Carol Anne Braddock (cab8) carolann(a)censored.org 206.42.112.96 My Homepage The Cyberdoc *********************************************************************** ------------------ PGP.ZIP Part [017/713] ------------------- M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M MF=O0H+*%(-S%&>S%+FS&<LS%3(Q&#W1"<]2%`H^;,]^1C$'HBN8PX$4SYAU^ MPGD<Q0ZLA0D+,`MCT!LA**4M[-JPAK9F?40!AJ,CW"'%DR#:'9?Q)3[%<DQ` ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/

1 0

Re: Scientology tries to break PGP - and
by keelings＠wu1.wl.aecl.ca 17 Dec '03

17 Dec '03

Incoming from Henry W. Farkas: > [snip] > When the safety is finally removed from the gun at your head (sorry for > the drama) you hand over your alternate secret key. If decrypted with the > "alternate" or "fake" secret key, the encrypted file is wiped until it > reaches a marker; the remainder of the file is displayed. If you use your > "primary" or "real key", the extraneous text is simply stripped. I would just like to point out that, when a LEA comes to you to get at the contents of your computer, (s)he is not going to patiently wait while your system wipes the offending evidence off your hard disk. The first thing they do is make a copy of everything, so they can work from the copy. Besides, you do have backup tapes laying around all over the place, don't you? -- "Remember, obsolescence (Win95) isn't an accident; it's an art form!" keelings(a)wu1.wl.aecl.ca s. keeling, aecl - whiteshell labs

1 0

Secure Device 1.4 (secdr14.zip)
by gjeffers＠socketis.net 17 Dec '03

17 Dec '03

Dear fellow Cypherpunks, Could someone send me Secure Device 1.4 (Secdr14.zip) ? My ftp software won't accept the huge directory path needed to point at the package on U.S. servers. I am an American citizen at an American site who knows the export regulations. Thank You, Gary Jeffers

1 0

p-NEW digital signatures
by Kent Briggs 17 Dec '03

17 Dec '03

I've been experimenting with discrete logarithm digital signatures. Schneier describes a scheme call p-NEW on page 498 of "AP" (2nd ed). It has the advantage of not requiring an inverse calculation via the extended Euclid algorithm. The signature is shown as: r=mg^(-k) mod p s=k-r'x mod q The verification equation is m=(g^s)(y^r')r mod p r'=r mod q. If p is a strong prime then q=p-1 and r'=r. The public key is y=g^x mod p. x is the private key. k is a random number less than q. m is the message being signed. I'm confused about the negative k value in the r equation. This would lead to 1/g^k which is a fractional number. It seems the equation should be: r=mg^(q-k) mod p Or, I can rearrange both equations like this: r=mg^k mod p s=-k-rx mod p To avoid using negative numbers in the mod function, I can calc s as: s=q-((k+rx) mod q) I tried this with some small integers and the numbers work out. The s calculation will be quick since there is no exponentiation. Most of the time spent in signing a message will be the r calculation. However, the the verification equation [m=(g^s)(y^r)r mod p] has two exponentiation calculations and will take more time. Since a message is only signed once but could be verified many times, I could precompute rg^s during the signing: r=mg^k mod p s=q-((k+rx) mod q) z=rg^s mod p s is discarded and the signature is r and z. The verification is: m=zy^r mod p This slows down the signing but speeds up the verification. Here's the $64K question: Does this compromise the signature's security? Kent Briggs kbriggs(a)execpc.com CIS: 72124,3234

2 1

Re: Netscape to patch shareware version
by Marshall Clow 17 Dec '03

17 Dec '03

>| Meanwhile, in an as yet unannouced move, the company said it would place >| its commercial browser online for free downloading. [..] THe commercial >| version, sold only in the U.S. contains an unbreakable 128-bit >| encryption scheme. > >Hurray! We did it! We did it! :-) Indeed. Congratulations to Damien, Adam, and all the other people who contributed cycles to the "Cypherpunks Key Breaking Ring". > >| Netscape said it received word last week that the State Department had >| cleared that version for release on the Net, but only within the U.S., >| owing to current export laws banning the export of encryption schemes >| stronger than 40 bits. THe company could provide no details by press >| time on how it would ensure that the 128-bit version wouldn't leak beyond >| U.S. borders. > I suspect Netscape will do the minimum so that they will not be held liable. >Ok, any bet on how long it will take? > Less than 3 hours. >| The cypherpunks forced a situation where Net users now have better >| encryption available to them. I'd say this is a big win. > >The power of the Net is actually quite astonishing at times. The >plotting in Ender's Game isn't all that unrealistic after all. (Oh, >well, ruler of the world is a bit of still. ;-)) > Demosthenes

1 0

fcpunx subscribe
by Wendy Fu 17 Dec '03

17 Dec '03

endWendy Fu, Network Manager St. John's University School of Law 8000 Utopia Parkway, Jamaica, NY 11439 E-Mail Address: wfu(a)sjulaw.stjohns.edu Phone: (718)990-1666

2 1