December 2003 - cypherpunks-legacy

Re: crypto and bagpipes [NOISE]
by jim bell 17 Dec '03

17 Dec '03

At 01:01 PM 6/29/96 -0700, Michael Myers wrote: >>Perry E. Metzger wrote: >>| vinnie moscaritolo writes: >>| > >>>Mr Brooks, the piper, > (...) >>| > >>>claims he wasn't playing a musical >>| > >>>instrument, but practising with a weapon! >>| > >>> >>| > >>>The imagination boggles if his claim is successful! >>| >>| No one who has heard sustained bagpipe playing can deny the fact that >>| bagpipes are indeed an instrument of war, with no legitimate place in >>| peaceful everyday society. >>| >>| Perry > >Of course...when bagpipes are outlawed... Do you mean the FULL-AUTO "Assault Bagpipes," the ones that produce more than one "toot" per blow? Or the more "responsible" (but still dangerous!) semi-auto bagpipes, where you have to blow each time you want a toot. Jim Bell jimbell(a)pacifier.com

3 2

Re: fbi botches intel "ecspionage" case
by jim bell 17 Dec '03

17 Dec '03

At 12:25 PM 6/29/96 -0700, Vladimir Z. Nuri wrote: > >"economic espionage" (ecspionage?) is in full swing as being >promoted as the new bogeyman to justify spending billions of >dollars to our intelligence agencies, both military and >the FBI. >we already have a very good example where this has >backfired. I was watching Nightline on Tues night or >so in which there was info about how the FBI helped >get an informant into Intel in a *very* sensitive >position, where he was able to film the pentium chip >plans. he said he sold them, as I recall, >to iraq, syria, china, etc. [snip] >I was thinking about all the objections I had to the >FBI ecspionage treatment that were never raised on the >program: >1. there was an implicit assumption that merely having >the plans to the chip would allow other countries to somehow >slaughter us in economic competition. but INTEL has spent >billions of dollars on physical infrastructure without which >the plans are virtually useless. it would take other countries >years to get the kind of equipment necessary to produce the >pentium, by which it might actually be yesterday's technology >that no one cares about any more. It's worse than this. I can recall talk of a big problem WITHIN INTEL trying to tranfer the process to produce a part between (as I recall) two Intel semiconductor fabs, Fab IV and Fab V, which are buildings only a couple hundred feet apart! And obviously, this was done with the full cooperation of everyone within Intel, and did not require the interfacing with any other company. The idea that you can just steal the "plans" for a chip and build it yourself is crazy. >2. we have a tradition of separation of church and state in >this country, and also separation of the public government >and private industry. suddenly we have the FBI saying they >want to infiltrate companies to deal with economic espionage. >well, these companies have their own policy, and what do >they gain by having a government agency working inside them? >in the above case I note, it led to exactly the *opposite* >of what was intended: the theft of *highly*sensitive* plans >by an FBI mole. I was even more disgusted with the FBI: I kept hearing them claim, "We did not authorize him to break the law." Huh?!? Maybe they didn't, this time, but does this mean, implicitly, that this country has sunk so low that the FBI thinks it has the legal authority to "authorize" somebody to break the law????? Jim Bell jimbell(a)pacifier.com

2 1

Cookies anyone?
by vanished＠alpha.c2.org 17 Dec '03

17 Dec '03

While rummaging around in my cookie jar, I found this message--along with some cookies. :Netscape HTTP Cookie File :# http://www.netscape.com/newsref/std/cookie_spec.html :# This is a generated file! Do not edit. Rather than bring down my system by experimenting, I thought I'd ask the list, "What happens if I delete this file?" and "What happens if I delete (edit) the cookies?" This may have been discussed before, but until now I never checked for cookies. Thanks for your consideration of this matter. Vanished

4 3

Hardware RNG
by Jack Mott 17 Dec '03

17 Dec '03

I just recently built a hardware RNG, I just wanted to see what you guys think of it, here is how it works: Got a geiger counter plugged into the game port Weak radioactive source next to it (dont worry wont fry you) Use a PRNG string to do create an RC4 S-box Cycle through the S-box in a tight loop, each time checking to see if the geiger counter got a hit, if it did, record that number in the S-box as our first byte, do this 100 times, and we have 100 random numbers. With my radioactive source and geiger settings, you can grab 100 random numbers in about 8 seconds, and the S-box will make a complete cycle between 1000 and 350,000 times between geiger hits, depending on how long between hits. any thoughts? It seems to work well, no basic stat analysis reveals any pattern, and physicists have backed me up on radioactive decay being 'the great randomizer'. seeya -- thecrow(a)iconn.net "It can't rain all the time" RSA ENCRYPTION IN 3 LINES OF PERL --------------------------------------------------------- #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

1 0

Re: Cookies anyone?
by Alan Olsen 17 Dec '03

17 Dec '03

At 04:34 PM 6/29/96 -0700, vanished(a)alpha.c2.org wondered what happens if he tosses his cookies: >While rummaging around in my cookie jar, I found this message--along with some >cookies. > >:Netscape HTTP Cookie File >:# http://www.netscape.com/newsref/std/cookie_spec.html >:# This is a generated file! Do not edit. > >Rather than bring down my system by experimenting, I thought I'd ask the list, >"What happens if I delete this file?" and "What happens if I delete (edit) the >cookies?" If you edit the file, Netscape may no longer be able to read the file correctly. (Bookmarks are similar in this respect. Netscape code is pretty picky about things like line termination and the like.) If you toss your cookies, Netscape will probibly bring you more cookies, but they will be different cookies than the last batch. Beware of burned cookies, fortune cookies (espicially ones with "Good Times" written on them), raisin cookies (especially if the raisins move), Brownies under the age of consent, and the cookies from dusty vending machines (Especially the hairy green ones). > >This may have been discussed before, but until now I never checked for cookies. You might also read the cookie recipie at http://www.netscape.com/newsref/std/cookie_spec.html . I hear it was written by a disgruntled Mrs. Fields employee. >Thanks for your consideration of this matter. You are welcome. Have a nice day. --- Alan Olsen -- alano(a)teleport.com -- Contract Web Design & Instruction `finger -l alano(a)teleport.com` for PGP 2.6.2 key http://www.teleport.com/~alano/ "We had to destroy the Internet in order to save it." - Sen. Exon "Microsoft -- Nothing but NT promises."

1 0

Re: Crack for DOS
by frantz＠netcom.com 17 Dec '03

17 Dec '03

Bill Stewart wrote: > Blowfish is new, so perhaps there are flaws that 10-20 years of analysis > will find. But it's pretty good - it's small, fast in software, > and has an annoyingly slow key-schedule which makes it difficult to > use brute-force crackers on. It's got variable key lengths. This comment about "annoyingly slow" key setup made me think of pipeline hardware to set up the keys. Now with blowfish, key setup requires running the Blowfish algorithm 521 times in setting up the key, so the pipeline will require 521 stages if you want a new key for every "real" decryption. Ignoring chip size restrictions, this pipeline will increase the chip real estate by 521 which will have approximately the same economic effect on the cost of cracks as extending the key by 9 bits. For CBC cypher systems, brute force attacks will require at least two decryptions (one for the initialization vector, and one for the first block of the message). however, these decryptions can take place in parallel (for the first block of the message) so they do not change the above argument. However if the design calls for more than the first block, then the pipeline can run slower and becomes a smaller portion of the cost of the system. Of course if you are using Blowfish with anywhere near its full 448 bit key, brute force attacks are simply not practical. ------------------------------------------------------------------------- Bill Frantz | The Internet may fairly be | Periwinkle -- Consulting (408)356-8506 | regarded as a never-ending | 16345 Englewood Ave. frantz(a)netcom.com | worldwide conversation. | Los Gatos, CA 95032, USA

1 0

New&Improved MiddleMan
by MiddleMan Remailer 17 Dec '03

17 Dec '03

Hello Everyone, Due to several requests, I have been working on an improved middleman remailer. Actually it's quite simple. I was able to improve the reliability and robustness of the remailer dramatically by changing $config{"numshuf"} = 3; to $config{"numshuf"} = 2; in the .premailrc file for the middleman remailer. Exhaustive testing demonstrated that no code changes to middleman itself were required. The only variable that demonstrated the most profound performance difference is shown above. I invite others to test the remailer for reliability and report back to me. If it works, I'll go public with it once again. Here is the public key for middleman. Please note the slight name change from middle-man to middleman. One less keystroke if you know what I mean. I invite your comments. middleman middleman(a)nym.jpunix.com d020c2e68f1861098812ffaadd6e8a7d 2.0.3 -----Begin Mix Key----- d020c2e68f1861098812ffaadd6e8a7d 258 AAS/9+NieAH945N1PYtLzSxnhUxVrfPR/OIAcQDM 61v5WGfpgXAltjMRQ0PHaBibeuER2/JhF5uDh4tu nypppGDshlrajeX/RuXMN38UPRMZPDKwNzP2oddB l/nTy6rxcdRUclBfzzoERUUay9RSiScbpnfvcm3g R2Qgv3taGiAf+wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQAB -----End Mix Key----- middleman-admin(a)nym.jpunix.com

1 0

Re: anonymous mailing lists
by Alex de Joode 17 Dec '03

17 Dec '03

Hal sez: : Wei Dai did some nice statistical analysis of this type of attack : sometime a year or two ago. Even with countermeasures such as you : suggest, if they are not perfect, so some information leaks correlating : incoming and outgoing messages, Wei showed that it was possible to : deduce the owners of the nyms surprisingly quickly. : The countermeasures do work - if you get and send exactly 50 pieces of : 4K byte email every day, no matter what, then correlations don't exist : - but they are expensive to do perfectly. For now we have much worse : weaknesses; none of the current return-address systems are really safe, : other than posting encrypted mail to newsgroups (and even that may be a : problem if they suspect who you are and are monitoring your computer : link to see if you download certain messages). Use ssh or any other link encryptor, or fetch the whole newsgroup using uucp. -- -AJ-

1 0

In From the Cold
by jya＠pipeline.com 17 Dec '03

17 Dec '03

June 28 the NYT and Wash Post reported on a new report on intelligence: In From the Cold: The Report of the Twentieth Century Fund Task Force on the Future of U.S. Intelligence. This report supplements and differs somewhat from the three released earlier this year by the Brown Commission, Representative Combest's Committee and the Council on Foreign Relations. It recommends greater emphasis on economic intelligence and less on military support as well as reduction of covert operations. Here's an excerpt from the Foreword: The Task Force discerned basic problems that merit far greater attention. Foremost among them is the intelligence community's increasing preoccupation with military priorities since the Soviet Union's collapse, which has coincided with a decline in the usefulness of intelligence to civilian policymakers. To help strike a more equitable balance between the military and civilian needs of the government, the Task Force proposes specific recommendations for strengthening what it perceives to be four pervasive shortcomings: 1) the atrophying analytic capabilities of the intelligence community and U.S. foreign policy agencies; 2) the lack of productive and effective interactions between the intelligence community and civilian officials who make foreign policy decisions; 3) a clandestine service whose costs have too often exceeded its benefits; and 4) poorly organized, unfocused, and often mediocre economic intelligence efforts. The full volume is 275 pages, composed of introductions, the main 21-page report and three extensive and detailed background papers of 248 pages. The introductions and main report are at: http://pwp.usa.pipeline.com/~jya/infrom.txt (60 kb) INF_rom ---------- In From The Cold: The Report of the Twentieth Century Fund Task Force on the Future of U.S. Intelligence. With Background papers by Allan E. Goodman, Gregory F. Treverton and Philip Zelikow The Twentieth Century Fund Press, New York, 1996. $5.95 ISBN 0-87078-392-0 To order by telephone: 1-800-552-5450

1 0

Re: rsync and md4
by Andrew Tridgell 17 Dec '03

17 Dec '03

> The odds of a certain file having a certain hash are one in 2^128. But, > the odds of any two files having the same hash (the "Birthday Attack") is > just one in 2^64. The birthday paradox doesn't apply in my case I believe. Its not an all-to-all comparison. One file is "given" by the user. I'm definately not a crypto-expert, however, so I could be wrong. > That's good, because MD4 collisions can be produced in a matter of > minutes. But if you're not concerned about attacks, then MD4 is probably > more than you need. I'd like to know more about this. > You could, but why bother? If you've got a 14.4 or faster modem, you can > send a lot of hashes in a short time. The real load won't come until you > try to download an altered file. You'd have to read the tech report on rsync. It does not download the whole file when a checksum mismatch is found, that would be next to useless. It effectively creates binary diffs of the two files, without direct (local) access to both files. As far as I know this is a new type of algorithm. In practice the hashes and checksums dominate the data that is sent over the link. They total about 1/30 of the total file size for the default settings. > MD4 is not strong- people can deliberately produce files with the same > hash in a matter of minutes. MD5 is secure for now, but it seems to be > gradually falling to cryptanalysis, and should be phased out of use before > it breaks. IMO the best hash algorithm is SHA1 (which is an updated > version of the original SHA). Do a web search for "FIPS PUB 180-1" for the > specs. Do you have references to the md4 collision stuff? The situation I have is a bit unusual so its just possible some of the results may apply. > For what you're doing it sounds like you don't need a cryptographically > secure hash function. If you're not concerned about people deliberately > trying to defeat the system, then just use a 32-bit CRC. It already uses a 16 bit hash as a first level filter and a 32 bit "rolling checksum" as the 2nd level. The 2nd level fails about 25 times on a 25MB test file I've been using. The failure rate goes as the square of the file length. When the 2nd level fails it is detected by the md4 hash which has to be much stronger. Cheers, Andrew

2 1

(no subject)
by Paul Rahe 17 Dec '03

17 Dec '03

1 0

arcfour
by Steve Reid 17 Dec '03

17 Dec '03

A few questions about RC4... I understand that RC4 is like a one-time-pad, in that a key can not be used more than once. What about adding a different salt to the key for each encryption? Would that be sufficent, even if the salt (but not the rest of the key) were known to an attacker? Is there any way to identify and weed out weak keys? Does anyone have any sample data I can use to test an RC4 implementation? A key and the first few bytes of the stream should be sufficent. Thanks... ===================================================================== | Steve Reid - SysAdmin & Pres, EDM Web (http://www.edmweb.com/) | | Email: steve(a)edmweb.com Home Page: http://www.edmweb.com/steve/ | | PGP (2048/9F317269) Fingerprint: 11C89D1CD67287E68C09EC52443F8830 | | -- Disclaimer: JMHO, YMMV, TANSTAAFL, IANAL. -- | ===================================================================:)

2 1

Re: Hardware RNG
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 1:26 AM 6/30/96, Jack Mott wrote: >I just recently built a hardware RNG, I just wanted to see what you guys >think of it, here is how it works: > > Got a geiger counter plugged into the game port >any thoughts? It seems to work well, no basic stat analysis reveals any >pattern, and physicists have backed me up on radioactive decay being >'the great randomizer'. First, have fun playing with it. Second, watch out for subtle statistical biases. While radioactive decay is unpredictable (so are a lot of things, by the way), there are all kinds of biases that reduce the apparent entropy. Detector "dead time" is a classic one (basically, the detector can't detect counts during a post-pulse recovery time...probably not a problem at low count rates, but an example of how subtle things can sneak in). --Tim May Boycott "Big Brother Inside" software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- 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, Licensed Ontologist | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

[Fwd: Doubleclick]
by Eric Murray 17 Dec '03

17 Dec '03

[Multiple forwards deleted] [short-attention-span summary: someone's using Netscape cookies as a way to target-market browser users. Since I hate being targeted, I came up with a hack "fix" to prevent it, see below] > >Date: Wed, 26 Jun 1996 19:42:00 -0700 > >From: Scott Wyant <scott_wyant(a)loop.com> > >Subject: COMMENT: Cookie dough > > > >(I originally posted this to a library science listserve, and was asked to > >post it here. I hope it is of some interest to ADV-HTML readers) > > > >This list has seen discussion about the little "cookie" that a Netscape > >server hands to your browser. Have you wondered how someone might use it to > >make some money? > > > >Here's how. > >(This will take a while, but I think it's worth it.) > > > >Using Find File, look for a file called cookie.txt (or MagicCookie if you > >have a Mac machine). Using a text editor, open the file and take a look. > > If you've been doing any browsing, the odds are about 80/20 that you'll find > >a cookie in there from someone called "doubleclick.net." > > > >If you're like me, you never went to a site called "doubleclick." So how did > >they give you a cookie? After all, the idea of the cookie, according to the > >specs published by Netscape, is to make a more efficient connection between > >the server the delivers the cookie and the client machine which receives it. > >But we have never connected to "doubleclick." > > > >Close MagicCookie, connect to the Internet, and jump to <www.doubleclick.net> > > Read all about how they are going to make money giving us cookies we don't > >know about, collecting data on all World Wide Web users, and delivering > >targeted REAL TIME marketing based on our cookies and our profiles. > > > >Pay special attention to the information at: > ><www.doubleclick.net/advertising/howads.htm> > > > >You'll see that the folks at "doubleclick" make the point that this entire > >transaction (between their server and your machine) is "transparent to the > >user." In plain English, that means you'll never know what hit you. > > > >So what's happening is, subscribers to the doubleclick service put a "cookie > >request" on their home page FOR THE DOUBLECLICK COOKIE. When you hit such a > >site, it requests the cookie and take a look to see who you are, and any > >other information in your cookie file. It then sends a request to > >"doubleclick" with your ID, requesting all available marketing information > >about you. (They're very coy about where this information comes from, but it > >seems clear that at least some of it comes from your record of hitting > >"doubleclick" enabled sites.) You then receive specially targetted marketing > >banners from the site. In other words, if Helmut Newton and I log on to > >the same site at the exact same time, I'll see ads for wetsuits and > >basketballs, and Helmut will see ads for cameras. > > > >If you log in to a "doubleclick" enabled site, and it sends a request for > >your "doubleclick" cookie, and you don't have one, why each and every one of > >those sites will hand you a "doubleclick" cookie. > > > >Neat, huh? And you can bet they're going to be rolling in the cookie dough. > >Me, I edit my cookie file each and every time I go to a new site. (Despite > >the dire warning at the top of the file, you can edit it with no adverse > >consequences.) > > > >Oh, and one other thing. If you edit your cookie file BEFORE you connect to > >"doubleclick," and then jump around at the site, you'll notice that they > >DON'T hand you a cookie. I probed the site pretty carefully, checking the > >MagiCookie file, and nothing happened. > > > >Until I closed Netscape. The LAST thing the 'doubleclick" site did was.... > >You guesed it. They handed me a cookie. So much for making the > >client-server negotiation more efficient. (In fairness, that cookie may > >have been in memory until I closed Netscape -- I can't tell for sure.) > >Scott Wyant > >Spinoza Ltd. > > My own experiments shows that simply removing the cookie file (~/.netscape/cookies) works to "fix" this, as long as you don't have old netscape config files lying about (then it pops a dialog asking if you want to nuke the old config, and uses the old cookies file). Netscape (version 3.0b for Linux) doesn't recreate the cookies file. Of course this "fix" means that I'm not able to take advantage of whatever cookies might offer me, but since I can't control them and never see them there's probably not a lot that they do that I'll miss. I think that Netscape should add a configuration to the browser so that paranoid privacy fanatics like me can disable cookies or better yet control which ones that we'll accept. -- Eric Murray ericm(a)lne.com ericm(a)motorcycle.com http://www.lne.com/ericm PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03 92 E8 AC E6 7E 27 29 AF

1 0

Re: Cookies anyone?
by jfricker＠vertexgroup.com 17 Dec '03

17 Dec '03

At 04:34 PM 6/29/96 -0700, vanished(a)alpha.c2.org wrote: >While rummaging around in my cookie jar, I found this message--along with some cookies. > >:Netscape HTTP Cookie File >:# http://www.netscape.com/newsref/std/cookie_spec.html >:# This is a generated file! Do not edit. > >Rather than bring down my system by experimenting, I thought I'd ask the list, "What happens if I delete this file?" and "What happens if I delete (edit) the cookies?" > >This may have been discussed before, but until now I never checked for cookies. > >Thanks for your consideration of this matter. > >Vanished > Delete it at will. Cookies are small tidbits of information that server side CGI progs (and client side JavaScript progs) have saved. Cookies are generally used to identify web users when they return to a site. I've seen cookies named "lastvisit", "userid", and so on. If pathfinder.com creates a cookie, it is only visible to pathfinder.com (that's the theory anyway). Deleting the cookie.txt file will have no ill effects unless you are using one of those "build yer own Start Pages" at MSN or wherever. Altering cookies would send garbage down when the cookie is requested. If you would rather that cookies (and crumb trails) not be allowed simply delete any cookies present and make the nominal file read only. John.

1 0

Re: UK Crypto regs?
by jya＠pipeline.com 17 Dec '03

17 Dec '03

Adam, Thanks for forwarding that delightful report from Ross Anderson on the IEE TTP romp. His grimly comical description of the hauty evasiveness of governmental infosec turkeys fits the U.S. sessions on GAK. These power-drunk birds just aren't used to answering to an aroused, sober, informed public on the cluckers' no longer secretly enjoyed private stocks of if-you-gnu-what-we-brew inebriants. Pray British rabble-rousers continue to grieve the red-nosed authorities as have the colonials theirs. Is there more info on when the OECD report is due?

1 0

RNG
by David Lesher 17 Dec '03

17 Dec '03

> > I just recently built a hardware RNG, I just wanted to see what you guys > think of it, here is how it works: > > Got a geiger counter plugged into the game port > Weak radioactive source next to it (dont worry wont fry you) > Use a PRNG string to do create an RC4 S-box > Cycle through the S-box in a tight loop, each time checking to > see if the geiger counter got a hit, if it did, record that number in > the S-box as our first byte, do this 100 times, and we have 100 random > numbers. > Tony Patti just gave the DC 'Punks a great talk on this topic. He built a faster RNG he called RANGER -- it connects to the parallel port. Plans for it are available in Cryptosystems Journal.... -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

Updated type2.list/pubring.mix
by John A. Perry 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- There is an updated type2.list/pubring.mix available on jpunix.com. Of note is the new jam remailer and the return of middleman. Welcome aboard! BTW you may have noticed that I've started sorting the type2.list file. I think it looks nicer that way. The files are available by WWW from www.jpunix.com as well as anonymous FTP from ftp.jpunix.com. Please direct questions or suggestions to perry(a)alpha.jpunix.com. John Perry - perry(a)alpha.jpunix.com - PGP-encrypted e-mail welcome! WWW - http://www.jpunix.com PGP 2.62 key for perry(a)jpunix.com is on the keyservers. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMdaO8lOTpEThrthvAQH4JQP9HYP+TbIZ8VO1v5lvRUfJfM0GDlakuCaN WK1CWQyCY79QLUs9GAAIksim+VyvfS9g1pg7zrsmy5S4MgZRMAX5NkWTg/+BNqKk M8LnDBAU2hSPNzjmNUiO9KhAgoein7z3Dy91ZOuaPGRNf6GhE0i8QjPTKKL81lzz 75+oY9rObEQ= =oR/A -----END PGP SIGNATURE-----

1 0

MacPGP 2.6.3 released
by Zbigniew Fiedorowicz 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I have put FatMacPGP2.6.3 v 1.6 on my web page http://www.math.ohio-state.edu/~fiedorow/PGP for distribution in the US and Canada in accordance with ITAR. The distribution is encrypted and you have to read the file README.txt for instructions on how to decrypt it. Here is a description of the main features of FatMacPGP2.6.3 v 1.6 from the README in the distribution: Enclosed is version 1.6 of FatMacPGP 2.6.3. This is a Macintosh port of the international version PGP 2.6.3ia released 04.03.96. The underlying PGP cryptographic code is the same as in the international release, except that it uses the RSAREF1.0 RSA library instead of Philip Zimmermann's MPILIB, in order to conform with US Patents on RSA. Also the legal_kludge switch, which allows interoperability with infringing pre-2.6 versions of PGP, is disabled. FatMacPGP 2.6.3 will run in native mode on a Power Macintosh, and will also run on 68K Macintoshes having a 68020 CPU or better. It will NOT run on Macintoshes with only a 68000 CPU such as Pluses, SE's, Classics or PB100's. It contains all the enhancements and bug fixes of PGP 2.6.3ia such as 1) It allows recipients of a public key message to be read in from a file containing the list of recipients, one per line. (Unlike previous versions of MacPGP it will not crash if the number of recipients exceeds 5 or 7.) 2) When extracting multiple keys into an ascii file, the each key is put separately into its own block, neatly labelled with the key id and user ids. 3) Better support for 8 bit character sets, ie. characters you get by holding down the option key. 4) Userids can be automatically signed with your secret key when creating keys ('pgp -kg') or adding new userids ('pgp -ke'). This is controlled by the AutoSign flag in the Options menu. 5) The misfeature of the initial 2.6.3i release, which didn't allow softwrapped text to be treated as text has been removed. 6) When clearsigning messages, FatMacPGP 2.6.3 will add a "Charset:" headerto the signature block, explaining which character set was used for creating the signature. This will help the recipient of the message to select correct character conversion when verifying the signature. If he/she is using version 2.6.3i, PGP will automatically choose the correct character set, thereby eliminating a lot of "Bad signature" problems. In addition to the above FatMacPGP 2.6.3 has many enhancements and bug fixes relative to previous versions of MacPGP. 1) Unlike MIT MacPGP 2.6.2 contains native Power PC code. Consequently it runs typically about 1.5 to 2 times faster than the MIT version on PPC machines, and even faster for large keyrings or large keys. It also runs typically 10-20% faster on 68K machines. 2) It has a greatly enhanced AppleEvent suite. For instance, unlike the MIT version, it is not necessary to write data to temporary files before passing it to MacPGP for en/de/cryption or signing. FatMacPGP 2.6.3 accepts AppleEvent TEXT parameters up to 32K in size in memory and returns the processed data as a parameter to the reply AppleEvent. (See the accompanying documentation for further details.) 3) It has options for automatic hardwrapping and detabbing of text, which should make electronic transmission of clearsigned messages more reliable and increase interoperability with many DOS and Unix text processing programs. 4) It has an option for stealthifying PGP encrypted files, removing any trace of their provenance. The resulting files can't be distinguished from white noise and can be completely concealed by "stegoing" into graphics and audio files. (There is of course also an option for destealthifying.) 5) It has an option for using SHA1 as the hashing algorithm for PGP signatures, instead of MD5. (Dobbertin has recently made some dramatic progress towards cryptanalyzing MD5. If he is successful, this might call into question the reliability of PGP signatures under certain circumstances.) This is an experimental feature which is not compatible with earlier versions of PGP. (It is not compatible with the proposed standards of PGP 3.0 either. But 3.0 is supposed to be deliberately incompatible with all 2.x versions to avoid the RSA patent issue.) FatMacPGP 2.6.3 is distributed under the same license terms from MIT and RSADSI as the 2.6.2 release, since its functional core is virtually identical. Please read the license agreements prior to using the program. Distribution of this program may be subject to US government export controls. This release is not endorsed by Philip Zimmermann, MIT or anyone else. However full source code for FatMacPGP 2.6.3 is being released together with the executable (although in a separate archive). It is not difficult to verify that the cryptographic core is unchanged from the 2.6.2 version. Also the author is mentioned in Zimmermann's documentation as the primary developer of previous MacPGP versions. A few support files, such as sample AppleScripts and other extensions, to facilitate interaction with the Eudora mailer program and the BBEdit text editor are included. While they are fully functional and hopefully useful, they are primarily intended to serve as illustrations to other developers on how to integrate PGP with other Macintosh programs. Detailed documentation can be found in the document "MacPGP263_AppleEvents" in the Macintosh Documentation folder. Read the included document "Verifying PGP" for instructions on how to verify this copy of MacPGP. Beginners should first take a look at the document "Getting Started with MacPGP". A detailed reference manual to MacPGP entitled "MacPGP263_Manual" is enclosed in the Macintosh Documentation folder and the indispensible "PGP User's Guide" by Philip Zimmermann is in the Documentation folder. Sources for FatMacPGP 2.6.3 will be available shortly. Z. Fiedorowicz -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: mac Comment: MacPGP 2.6.3 iQCVAwUBMdbLNr1LYmqiC9QjAQEl/wP+JXpDvgQ9VgTmXsvjjfFp+zd4v8ZeIMmt 45WcfqqPvSUPVEXv225MyYHMO1zKDkcKej1swBpFZDz5GV1eZJvriqYuNqc4Z0g0 0w9syQ2i6U5AoF6MR8bPs9Apq2Og9dRbFbaNXZ9Ba6bCtPHXyfZS1qQpi06Mkpty Xh39nE3dv4s= =/3Xe -----END PGP SIGNATURE-----

4 3

Re: [Fwd: Doubleclick]
by Yanni 17 Dec '03

17 Dec '03

> There's a very obvious way to get their cookie put in your cookies > file without you explicitly going to their site. This is my favorite example... You work at a company. Evil co-worker there says...check out this webpage I just setup. You goto that page, the server gives you a cookie with confidential information. ( 4k can store a lot of data..:) )... Boss comes around and looks at your cookie file, notices confidential information. You get fired, sued, whatever.... > The server can send whatever it wants to you in the Set-Cookie: > header. Read the spec. Yes, but you know the server that sent it. A Set-Cookie header can't set the domain to be other than the domain that the cookie came from. The message that was copied to the list implied that one domain could set a cookie for another domain. That isn't true unless you have access the the persons cookie file. ( as you implied in your response, but which is beyond the scope of the original letter ). Regards, -jon Jon (no h) S. Stevens yanni(a)clearink.com ClearInk WebMagus http://www.clearink.com/ finger pgp(a)sparc.clearink.com for pgp pub key We are hiring! Check out... http://www.clearink.com/clearink/home/job.html

1 0

Re: FTS2000 and Encryption?
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 1:57 PM 6/30/96 -0400, Mark O. Aldrich wrote: >... The [FTS2000 follow-on contract - WSF] >security policy and RFP materials are on the 'net (I can't get to the web >right now, or I'd post the URL with this message). Please post the URL when you can. >From what I remember, >the RFP does state that all payload data will be encrypted by the >Government using NSA-approved crypto and that the vendors are not to >"worry about" what's in the payloads. All they have to do is carry it >from point a to point b. Given that FTS2000 supports X.25 Packet Assembly Disassembly (PADs), there is a wide field ahead for screwing up such useful features as 8-bit transparent characters and data forwarding (i.e. When does the PAD decide it has a complete packet and actually send it). Try running emacs without good data forwarding control. ------------------------------------------------------------------------- Bill Frantz | The Internet may fairly be | Periwinkle -- Consulting (408)356-8506 | regarded as a never-ending | 16345 Englewood Ave. frantz(a)netcom.com | worldwide conversation. | Los Gatos, CA 95032, USA

1 0

SEC lets California retailer trade stock on Internet
by Joseph M. Reagle Jr. 17 Dec '03

17 Dec '03

WASHINGTON, June 27 (Reuter) - A California company that sells energy-saving solar panels has received Securities and Exchange Commission approval to trade its stock over the Internet, extending the boundaries of off-exchange trading into cyberspace. The approval, the first the SEC has issued on stock trading over the Internet, was given earlier this week to Ukiah, Calif.-based Real Goods Trading Corp., through a ``no action'' letter. In such a letter, the SEC allows a petitioning company to perform what it requested to do, without fear of any enforcement action. In approving Real Goods' request, however, the agency imposed conditions in the interest of investor protection. John Schaeffer, president, chief executive and founder of the company said in an interview he hoped to get the new system operational ``within a couple of weeks.'' Schaeffer said that since 1991, his company has sold $4.6 million of its company's stock to the public through direct, small offerings and without having to pay fees to investment bankers. ``The 'off the grid' trading of our stock is a logical extension of our service to our customers, who will now be able to buy and sell our security without going through a broker,'' Schaeffer said. ``This is also consistent with our mission of creating independent energy alternatives for our customers,'' he added. Real Goods is currently traded thinly on the Pacific Stock Exchange, at a price range of between $5 to $7 in 1995. The stock closed at $7.25 on June 26. In its application, the company said its system would function as a passive Internet bulletin board that will provide the names, addresses, including E-mail, and phone numbers of interested buyers and sellers and number of shares offered for sale or desired to be purchased. Those participating may transmit the information through the company's World Wide Web site or by telephone, fax, mail or E-mail. Real Goods will then enter the data into the system. Real Goods posted a loss of $175,000 last year on sales of $15.3 million, Schaeffer said. ``We expect to be profitable this year,'' he said, adding he estimates sales to climb to about $20 million. Earlier this year, the SEC permitted Spring Street Brewery Co., of New York, to make an initial public offering over the Internet. The agency asked the company to suspend trading, pending review of legal implications of such a trading system. Spring Street subsequently said it planned to establish an online stock exchange through a unit. _______________________ Regards, Democracy is where you can say what you think even if you don't think. - Joseph Reagle http://rpcp.mit.edu/~reagle/home.html reagle(a)mit.edu E0 D5 B2 05 B6 12 DA 65 BE 4D E3 C1 6A 66 25 4E

1 0

Re: [Fwd: Doubleclick]
by Yanni 17 Dec '03

17 Dec '03

> [short-attention-span summary: someone's using Netscape cookies as a > way to target-market browser users. Since I hate being targeted, I > came up with a hack "fix" to prevent it, see below] Whatever. > > >Date: Wed, 26 Jun 1996 19:42:00 -0700 > > >From: Scott Wyant <scott_wyant(a)loop.com> Subject: COMMENT: > > >Cookie dough > > > > > >If you're like me, you never went to a site called "doubleclick." > > >So how did they give you a cookie? After all, the idea of the > > >cookie, according to the specs published by Netscape, is to make a > > >more efficient connection between the server the delivers the > > >cookie and the client machine which receives it. > > >But we have never connected to "doubleclick." Scott must have. Navigator is very picky about where a cookie comes from and what is put in the domain field of the cookie. Go read about the domain field in the Cookie spec. Then, write a CGI to play with setting/deleting cookies yourself. You will find out that it is actually almost an art to even get a cookie set. > > >Pay special attention to the information at: > > ><www.doubleclick.net/advertising/howads.htm> Maybe this scott wyant guy works for doubleclick? ;) > > >You'll see that the folks at "doubleclick" make the point that > > >this entire transaction (between their server and your machine) > > >is "transparent to the user." In plain English, that means > > >you'll never know what hit you. No sh*t. The cookie spec says that as well. > > >So what's happening is, subscribers to the doubleclick service put > > >a "cookie request" on their home page FOR THE DOUBLECLICK COOKIE. There is no such thing as a "cookie request". It is up to the browser to send the cookie and up to you to parse it out of the HTTP header. There is no way that the browser is going to send the cookie unless the domain and path matches. Go read the Cookie spec. > > >When you hit such a site, it requests the cookie and take a look to > > >see who you are, and any other information in your cookie file. > > >It then sends a request to "doubleclick" with your ID, requesting > > >all available marketing information about you. (They're very coy > > >about where this information comes from, but it seems clear that > > >at least some of it comes from your record of hitting > > >"doubleclick" enabled sites.) You then receive specially > > >targetted marketing banners from the site. In other words, if > > >Helmut Newton and I log on to the same site at the exact same > > >time, I'll see ads for wetsuits and basketballs, and Helmut will > > >see ads for cameras. Whatever. What are you saying doesn't make any sense if you knew what the heck you were talking about. > > >If you log in to a "doubleclick" enabled site, and it sends a > > >request for your "doubleclick" cookie, and you don't have one, why > > >each and every one of those sites will hand you a "doubleclick" > > >cookie. Whatever. > > >Neat, huh? And you can bet they're going to be rolling in the > > >cookie dough. > > >Me, I edit my cookie file each and every time I go to a new > > >site. (Despite the dire warning at the top of the file, you can > > >edit it with no adverse consequences.) Whatever. > > >Oh, and one other thing. If you edit your cookie file BEFORE > > >you connect to "doubleclick," and then jump around at the site, > > >you'll notice that they DON'T hand you a cookie. I probed the > > >site pretty carefully, checking the MagiCookie file, and > > >nothing happened. > > > > > >Until I closed Netscape. The LAST thing the 'doubleclick" site did > > >was.... > > >You guesed it. They handed me a cookie. So much for making > > >the client-server negotiation more efficient. (In fairness, > > >that cookie may have been in memory until I closed Netscape -- I > > >can't tell for sure.) Scott Wyant > > >Spinoza Ltd. No duh. Navigator doesn't fflush() the cookie file until you quit. It keeps it in memory for speed. > My own experiments shows that simply removing the cookie file (~/. > netscape/cookies) works to "fix" this, as long as you don't have > old netscape config files lying about (then it pops a dialog asking if > you want to nuke the old config, and uses the old cookies file). > Netscape (version 3.0b for Linux) doesn't recreate the cookies file. > Of course this "fix" means that I'm not able to take advantage of > whatever cookies might offer me, but since I can't control them and > never see them there's probably not a lot that they do that I'll miss. Who cares if you can't control them? They don't contain any information that you don't already know about! > I think that Netscape should add a configuration to the browser so > that paranoid privacy fanatics like me can disable cookies or better > yet control which ones that we'll accept. Navigator 3.0 has a preference. -jon (who has had more than enough real world experience with cookies) Jon (no h) S. Stevens yanni(a)clearink.com ClearInk WebMagus http://www.clearink.com/ finger pgp(a)sparc.clearink.com for pgp pub key We are hiring! Check out... http://www.clearink.com/clearink/home/job.html

2 1

Re: The Net and Terrorism
by frantz＠netcom.com 17 Dec '03

17 Dec '03

Thanks Tim for your essay. The only thing I would add is that terrorist attacks on pure information resources (e.g. the banking system) are likely to result in many fewer casualties than terrorist attacks on physical entities (e.g. major cities). Another way of saying it is, email bombs are preferable to snail mail bombs. ------------------------------------------------------------------------- Bill Frantz | The Internet may fairly be | Periwinkle -- Consulting (408)356-8506 | regarded as a never-ending | 16345 Englewood Ave. frantz(a)netcom.com | worldwide conversation. | Los Gatos, CA 95032, USA

1 0

Re: rsync and md4
by David F. Ogren 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- > On Sat, 29 Jun 1996, Andrew Tridgell wrote: > > > Now I'd like to calculate some probabilities of failure of the > > algorithm. The fundamental thing I need to know to do the calculation > > is the probability of a random piece of data of length n having the > > same md4 checksum as another given piece of data of the same length. > > MD4 is a hashing algorithm, but it can be used for checksuming. > > > > A first guess might be 2^-128 but I know that this sort of thing is > > rarely that simple. Is md4 that good? > > 2^-64. Are you sure? MD5 is a 128 bit hash, and the probability of collision with a specific random piece of data (of any length) should be 2^-128. I could be wrong, but do you have any explanation of why you think the answer is 2^-64. <snip> > > Why md4? I chose md4 because it seemed to be the fastest of the > > reputedly strong, publicly available checksum algorithms. Suggestions > > for alternative algorithms are welcome. MD4 is the fastest hash I am aware of. However, there has been some successful attacks against two rounds of MD4. Although this is not to suggest that MD4 is insecure, MD5 almost as fast (~1.3 times slower) and more secure. David F. Ogren | ogren(a)concentric.net | "A man without religion is like a fish PGP Key ID: 0xC626E311 | without a bicycle" - ------------------------------|---------------------------------------- Don't know what PGP is? | Need my public key? It's available Send a message to me with the | by server or by sending me a message subject GETPGPINFO | with the subject GETPGPKEY -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMdXI1fBB6nnGJuMRAQFghwP/W0ZzdAYcbsdsCcrA97cwfw4uwug8sJWd bjWD4Z+ski7kE4HN7bj2dRLFGke6EQZ8DiebnLIRPqGCxeyxdzotqcrsdKrgp+eN eMfjp0Y3wVwvrPn2kVI5M0iI9kpX8tvvLh7Kp3OBvHdsBTim4aPPuM8xR2SHLSgv /SYnhEBeYLA= =VPWe -----END PGP SIGNATURE-----

5 5