December 2003 - cypherpunks-legacy

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