December 2003 - cypherpunks-legacy

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

Re: anonymous mailing lists
by David Mazieres 17 Dec '03

17 Dec '03

iang(a)cs.berkeley.edu (Ian Goldberg) wrote: > Yesterday, Dave and I discussed at length a design for a new > remailer network... If you are thinking of revamping the mixmaster protocol, I have a couple of suggestions/requests. One basic philosophy motivating all of these ideas is that I would like to avoid requiring any "centralized control" or consensus about exactly what remailers should exist. This can be achieved by pushing a lot of configuration parameters into the anonymous messages, where the sender has control over them First, D-H (or RSA with short-lived keys) is an extremely good idea. Long-lived encryption keys (like the current mixmaster secret keys) should not be used for secrecy. However, it would also be good if you could avoid any man-in-the middle weaknesses. Specifically, with simple D-H, an active attack could be used to record all anonymous messages from A to B, and weeks later if B is compromised the messages could then be decrypted. Thus, when sending from remailer A to remailer B, B's identity must be proven with B's public key (either through RSA encrypting A's half of the D-H secret key and a challenge with B's key, or by having B sign his half of the D-H secret and a nonce). Moreover, since not every remailer will be known to every other, and since people may want to set up and test new remailers for a while before announcing them to the world, a strong cryptographic hash or MAC of B's public key should be embedded in the remailed-message itself. Thus, A can query B for its public key and verify the public key, then use this public key to know it is talking to the real "next hop". It would also be nice to avoid having every message go through every remailer unless the sender actually want's it to. In particular, a larger remailer network should not have to translate into more traffic for all the remailers, as it would be nice to have as large a network as possible. Thus, if, for instance, remailer A sends messages out every half hour, and A wants to send messages to B, C, and D--why not send the three useful messages to B, C, and D all in the same round, and just send garbage to all the other remailers. Of course, messages should be allowed to have as many next-hops as necessary, so that if you don't want A to know that a message's next hop is B, you can ask it to send the same message to C, F, and G as well as to B. That way, A won't know the real next hop. Now the next question is, when sending garbage to all the other remailers, should "all the other remailers" be defined by A or by the anonymous message itself. Here, A should definitely have some list of remailers it knows about. However, maybe at each hop a message should be able to supply 6-byte (IP address/port number) addresses of other remailers to which garbage should be send. If there appears to be a remailer at the address supplied, and that remailer is not already known to A, perhaps the new remailer should automatically be added to the list of garbage recipients (and then automatically deleted if it stops responding for 24 hours). In the event that A has a real backlog of messages for a particular destination B, it might make sense for A to hand some of those messages off to other remailers instead of just feeding them garbage. That way, even when one remailer is receiving a lot of mail it won't be immediately clear to it's operator which the preceeding hop is. Given all these features, of course, it would be necessary to have variable-length next-hop-descriptors instead of the fixed size and number currently in mixmaster. Is there some reason this can't be done? The total actual length of the 3-DES encrypted portion of the mixmaster message shouldn't be available to any but the last hop. Thus, is there something wrong with padding the message (or even just the 10K header portion of the message if you want to keep the message in two parts) with garbage to be 3-DES decrypted into more garbage at the next hop? Of course the padding should be done in such a way that the final hop does not know how much space the remailing headers originally took up, but this shouldn't be too hard (for instance the padding could go between the headers and the message data). Finally, another very useful feature would be some support for improved response blocks. Right now aliases like alpha.c2.org don't offer very much security because they have to go through Type-1 remailers. However, one could imagine mixmaster extensions to allow it to work for replies as well as anonymous messages. Imagine a nym server with just a 10K mixmaster header as a response block. The server would pad a received message to 10K, prepend the 10K mixmaster header, and send off the message. At each hop of the way, the message would get "decrypted" with some 3-DES key (and possibly a weird IV). However, couldn't the recipient then just "encrypt" the message to recover the plaintext? Of course, this might undesireably weaken the replay prevention, but there's got to be a good solution for response blocks somewhere near what we currently have for mixmaster. David

1 0

REMINDER: SAFE Forum Cybercast - Monday July 1, 12 noon - 6 pm EDT
by Bob Palacios 17 Dec '03

17 Dec '03

SECURITY AND FREEDOM THROUGH ENCRYPTION FORUM MONDAY JULY 1, 1996 STANFORD, CA 9:00 am - 3:00 pm PDT / 12:00 noon - 6:00 pm EDT / 1600 - 2000 GMT On July 1, 1996 in the heart of California's Silicon Valley, members of Congress and prominent computer industry leaders and privacy advocates will meet to discuss the need to reform U.S. encryption policy. The SAFE Forum will bring together members of Congress, privacy advocates, cryptographers, and industry leaders for a discussion on the need to reform U.S. encryption policy. If you can't attend the SAFE Forum in person, you can still participate by attending the cybercast of the event. The cybercast will include still photos of the conference, a RealAudio broadcast of the forum, and a telnet chat room for netizens to discuss the event and cryptography issues. Just visit the SAFE Forum web site on Monday for the necessary links: http://www.crypto.com/safe/ (You will need to be a copy of RealAudio installed on your computer. Visit http://www.realaudio.com/ for a FREE copy of Real Audio). The SAFE Forum Cybercast is brought to you with the help and support of: MediaCast (http://www.mediacast.com/) and AudioNet (http://www.audionet.com/) --------------------------------------------------------------------------- Event Information * Location: Kresge Auditorium at Stanford University, Stanford, California * Date: July 1, 1996, 9:00 am - 3:00 pm Program: 9:00 - 9:15 Welcome Rep. Anna Eshoo (D-Ca), co-host Rep. Tom Campbell (R-Ca), co-host Sen. Patrick Leahy (D-Vt) (by satellite) Jerry Berman, Center for Democracy and Technology 9:15 - 10:15 The Need for Locks and Keys on the GII: An Encryption Overview Marc Andreessen, Netscape Communications Lori Fena, Electronic Frontier Foundation Eric Schmidt, Sun Microsystems Craig Mundie, Microsoft Corporation 10:15 - 10:30 Technology Demo: The Need for Locks & Keys -- Packet Sniffing on the Internet (Cylink Corporation) 10:30 - 10:45 Break 10:45 - 11:45 How U.S. Encryption Policy Fails to Meet User Needs Herbert Lin, National Research Council Jim Omura, Cylink Corporation Tim Oren, CompuServe Incorporated Phil Zimmermann, PGP, Inc. Todd Lappin, Wired Magazine -- Introducing "Stories of Real-Life Encryption Users" 11:45 - 1:00 Lunch 1:00 - 1:45 The Cryptographers' Report: "Forty Bits Is Not Enough" Matt Blaze, AT&T Whitfield Diffie, Sun Microsystems Bruce Schneier, Counterpane Systems Eric Thompson, Access Data Tom Parenty, Sybase Technology Demo: The Genie is Out of the Bottle -- A World Wide Web Tour of Good Cryptography Available Outside of the United States 1:45 - 2:45 Addressing Law Enforcement Concerns in a Constitutional Framework Ken Bass, Venabel, Baetjer, Howard and Civiletti Cindy Cohn, McGlashan & Sarrail Michael Froomkin, University of Miami Law School John Gilmore, Electronic Frontier Foundation Grover Norquist, Americans for Tax Reform Nadine Strossen, American Civil Liberties Union Daniel Weitzner, Center for Democracy and Technology 2:45 - 3:00 Conclusion Members of Congress expected to participate include: * Rep. Anna Eshoo (D-CA) * Rep. Tom Campbell (R-CA) * Rep. Zoe Lofgren (D-CA) * Sen. Conrad Burns (R-MT) * Sen. Patrick Leahy (D-VT) (by satellite) --------------------------------------------------------------------------- Sponsors Of The SAFE Forum: America Online American Civil Liberties Union Americans for Tax Reform AT&T Audionet Business Software Alliance Center for Democracy and Technology Center for National Security Studies Commercial Internet eXchange CompuServe Incorporated Computer and Communications Industry Association Computer Professionals for Social Responsibility Cylink Corporation Digital Secured Networks Technology EDS Electronic Frontier Foundation Electronic Messaging Association Electronic Privacy Information Center Information Technology Association of America IEEE - USA ManyMedia MediaCast Media Institute Microsoft Corporation National Association of Manufacturers Netcom Online Communication Services Netscape Communications Corporation Novell, Inc. Oracle Corporation Pacific Telesis Group Pretty Good Privacy, Inc. Prodigy, Inc. Progress and Freedom Foundation Rent-a-Computer Securities Industry Association Software Publishers Association Sun Microsystems, Inc. Sybase, Inc. Voters Telecommunications Watch Wired Magazine --------------------------------------------------------------------------- CORRECTION An earlier Policy Post listed Matt Blaze with Lucent Technologies. That information was incorrect; he is with AT&T Research. ---------------------------------------------------------------------------

1 0

MD5 breaks, etc.
by Perry E. Metzger 17 Dec '03

17 Dec '03

1) On the question of MD4, it has been demonstrated that one can generate multiple documents with the same hash -- an example was given in a paper a while back of two contracts, identical but for the dollar sum agreed two, with identical MD4 hashes. That demonstrates that MD4 is useless. 2) Hans Dobbertin on May 2nd released a short paper that circulated widely on the net describing collisions in the MD5 compression function. Several people have asked me for references on this. I cannot give you anything -- all I have is postscript of the document, which had not been published in any journal when I last checked. However, the result is widely known. MD5 is *not* something that should be trusted going forward, and I hope the next version of PGP uses SHA-1. Perry

1 0

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

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Subject: Re: rsync and md4 To: perry(a)piermont.com, ogren(a)cris.com Cc: markm(a)voicenet.com, Andrew.Tridgell(a)anu.edu.au, cypherpunks(a)toad.com > > "David F. Ogren" writes: > > 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. > > Does the phrase "birthday attack" mean anything to you? But this isn't a birthday attack. Its a comparison between one specific file and one randomly chosen one. > > 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. > > I'm afraid you are totally wrong here. MD4 has been completely > broken. I wouldn't trust it for anything. In fact, MD5 is no longer > trustworthy, either -- it was broken recently. Stick to SHA. > Unless you are aware of some attack that I'm not, this is the most current information on MD4 and MD5: MD4 has had successful attacks on limited rounds. It has _not_ been completely cracked. MD5 has not been broken. A weakness has been shown, but collisions still cannot be developed. So checksums should still be secure. Additionally, in this case we are more concerned with the chance of random collisions than intentional collisions. In fact, I was probably wrong to suggest MD5. It _is_ more secure, but speed is his first priority, not security. SHA1 is a good hash algorithm as far as security goes (I've used it myself), but it's over three times slower than MD4. - -- David F. Ogren | ogren(a)concentric.net | "A man without religion is like a fish PGP Key ID: 0x6458EB29 | 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 - -- David F. Ogren | ogren(a)concentric.net | "A man without religion is like a fish PGP Key ID: 0x6458EB29 | 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 iQEVAwUBMddOi+SLhCBkWOspAQHLTgf7BsDpCO2nhxsHYOunVv8abXWgITexhM/Z vmYWaz2Lgu3tBYZHXIG7B2ijTikZ7u8RgMGd9esipjFxOks1bHRQwYbVbWeDUDb3 O0c5TmPPmZt/7PscUEw1D3hhtj8HeGmn9pfu0y/I54OnMIJzbvNMICpMtLLDXJCu PhpUoAfamyRdWl9OYAvZ3LBMLBdGagzCh/jPxCQ9gEBq0aYMkxF1/qlfIMdmegow H/uL+TRgN5roTIKDZPGPZWYbdLbf0NT00avPz5qKaA5BkOpxYgeRKtoBHdYC5krH O2NZGZqb5LRKgxW9+IvCWoUoJQTB6IXP+YDU7p4pbn/Y/QORSHzqGA== =WA0Y -----END PGP SIGNATURE-----

2 1

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

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- > > "David F. Ogren" writes: > > > I'm afraid you are totally wrong here. MD4 has been completely > > > broken. I wouldn't trust it for anything. In fact, MD5 is no longer > > > trustworthy, either -- it was broken recently. Stick to SHA. > > > > > > > MD4 has had successful attacks on limited rounds. It has _not_ been > > completely cracked. > > Could you please quit spewing inaccurate information? > > Dobbertin completely cracked MD4 already, and found MD5 collisions in > a document circulated on May 2nd that mean it isn't far behind. > > The comments you are making are dangerous because they encourage > people who don't know better to think that hashes which are known > unsafe are safe. Please quit posting until you start monitoring the > field enough to have accurate sources of information. > I stand by my statements. I have followed the current developments regarding MD5 with interest, and am using SHA1 in the program that I am currently authoring because of its MD5's weaknesses. However, MD5 (and MD4) have not been completely cracked. The problems that you bring up have to do with situations where an active attacker develops a slightly different pair of documents with the same hash. Although this is highly undesirable characteristic for a hash function, and shows a weakness in the function that may eventually lead to its being completely cracked, it does not mean that a fraudulent document can be created from an already signed document. This is an old argument and I don't want to get into it here. However, there a lots of people that who still think MD5 can be safely used to a) sign documents that you create yourself, and b) sign documents that you have made cosmetic changes to. Irregardless, this argument is moot. This thread is titled "rsync and md4". It is a discussion about which hash function suits this particular purpose and he is not particularly concerned with resistance to deliberate attack. In this case MD4 will function adequately. - -- David F. Ogren | ogren(a)concentric.net | "A man without religion is like a fish PGP Key ID: 0x6458EB29 | 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 iQEVAwUBMddp3uSLhCBkWOspAQEI1Qf/VLg6ak6Y/VfbynFhCcA69RZKAQ/C6pCx DMdz3OFitOwQM/csjTPBs7jue/3ArIQ+jevBOjp/NyAoJ4U8+Np4yv7ksmpEjTKq EWq4DcvAB7MgpgJ72A92tO55vQo8AjYPmcZT2LhqeiTg+R6yL437T4gqS0ZSs7Ud 7e1anp7m72shSel6OKsxtfgiyVDlVi6mdtpXlLegWxcZhPaRYaZen3mHJ3JdxCpc EsQupdrNVxBGMuxKeBwlkjCxD1TbqFpHTodh0oapEDScjpzTMmQeHYavmboI+Pys 32jt1PI9JEPIDracYcI3ovkgvR5VmMlKhAPDXcYbr2MWeBbVRDOaJw== =9dqv -----END PGP SIGNATURE-----

4 6

List of reliable remailers
by Raph Levien 17 Dec '03

17 Dec '03

I operate a remailer pinging service which collects detailed information about remailer features and reliability. To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu There is also a Web version of the same information, plus lots of interesting links to remailer-related resources, at: http://www.cs.berkeley.edu/~raph/remailer-list.html This information is used by premail, a remailer chaining and PGP encrypting client for outgoing mail. For more information, see: http://www.c2.org/~raph/premail.html For the PGP public keys of the remailers, finger pgpkeys(a)kiwi.cs.berkeley.edu This is the current info: REMAILER LIST This is an automatically generated listing of remailers. The first part of the listing shows the remailers along with configuration options and special features for each of the remailers. The second part shows the 12-day history, and average latency and uptime for each remailer. You can also get this list by fingering remailer-list(a)kiwi.cs.berkeley.edu. $remailer{"extropia"} = "<remail(a)miron.vip.best.com> cpunk pgp special"; $remailer{"portal"} = "<hfinney(a)shell.portal.com> cpunk pgp hash"; $remailer{"alumni"} = "<hal(a)alumni.caltech.edu> cpunk pgp hash"; $remailer{"c2"} = "<remail(a)c2.org> eric pgp hash reord"; $remailer{"penet"} = "<anon(a)anon.penet.fi> penet post"; $remailer{"flame"} = "<remailer(a)flame.alias.net> cpunk mix pgp. hash latent cut post reord"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord ?"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{"ecafe"} = "<cpunk(a)remail.ecafe.org> cpunk mix"; $remailer{"amnesia"} = "<amnesia(a)chardos.connix.com> cpunk mix pgp hash latent cut ksub"; $remailer{'alpha'} = '<alias(a)alpha.c2.org> alpha pgp'; $remailer{'nymrod'} = '<nymrod(a)nym.jpunix.com> alpha pgp'; $remailer{"lead"} = "<mix(a)zifi.genetics.utah.edu> cpunk pgp hash latent cut ek"; $remailer{"treehole"} = "<remailer(a)mockingbird.alias.net> cpunk pgp hash latent cut ek"; $remailer{"nemesis"} = "<remailer(a)meaning.com> cpunk pgp hash latent cut"; $remailer{"exon"} = "<remailer(a)remailer.nl.com> cpunk pgp hash latent cut ek"; $remailer{"vegas"} = "<remailer(a)vegas.gateway.com> cpunk pgp hash latent cut"; $remailer{"haystack"} = "<haystack(a)holy.cow.net> cpunk mix pgp hash latent cut ek"; $remailer{"ncognito"} = "<ncognito(a)rigel.cyberpass.net> mix cpunk pgp hash latent"; $remailer{"lucifer"} = "<lucifer(a)dhp.com> cpunk mix pgp hash"; $remailer{"jam"} = "<remailer(a)cypherpunks.ca> cpunk mix pgp hash latent cut ek"; catalyst(a)netcom.com is _not_ a remailer. lmccarth(a)ducie.cs.umass.edu is _not_ a remailer. usura(a)replay.com is _not_ a remailer. Groups of remailers sharing a machine or operator: (c2 alpha) (flame replay) (alumni portal) Use "premail -getkeys pgpkeys(a)kiwi.cs.berkeley.edu" to get PGP keys for the remailers. Fingering this address works too. Note: The remailer list now includes information for the alpha nymserver. Last update: Mon 1 Jul 96 6:47:34 PDT remailer email address history latency uptime ----------------------------------------------------------------------- flame remailer(a)flame.alias.net +++++__.-++- 10:04:50 100.00% alumni hal(a)alumni.caltech.edu #######*+*## 1:13 100.00% ecafe cpunk(a)remail.ecafe.org ####*#+--##* 14:24 99.98% replay remailer(a)replay.com *********+** 4:18 99.98% nemesis remailer(a)meaning.com +**** 23:43 99.98% c2 remail(a)c2.org ++++++++-+++ 51:58 99.97% portal hfinney(a)shell.portal.com +#######+*## 1:24 99.95% haystack haystack(a)holy.cow.net *-+#++++###+ 9:25 99.94% exon remailer(a)remailer.nl.com ++*******+** 5:49 99.94% lead mix(a)zifi.genetics.utah.edu ++++++++++++ 39:16 99.94% nymrod nymrod(a)nym.jpunix.com ** ****#+#-# 12:31 99.92% mix mixmaster(a)remail.obscura.com __.-_.-.--- 18:42:17 99.88% treehole remailer(a)mockingbird.alias.net +++ -..+++-+ 5:28:11 99.24% amnesia amnesia(a)chardos.connix.com ----------- 4:20:06 99.22% penet anon(a)anon.penet.fi __ _-..... 44:52:17 99.20% extropia remail(a)miron.vip.best.com --.-------- 5:15:59 97.93% ncognito ncognito(a)rigel.cyberpass.net -.___.-._ 22:24:17 97.35% alpha alias(a)alpha.c2.org ******-+++** 38:56 96.99% jam remailer(a)cypherpunks.ca * 19:19 96.68% lucifer lucifer(a)dhp.com +++ 56:06 95.20% vegas remailer(a)vegas.gateway.com #**-#*** 16:52 60.55% History key * # response in less than 5 minutes. * * response in less than 1 hour. * + response in less than 4 hours. * - response in less than 24 hours. * . response in more than 1 day. * _ response came back too late (more than 2 days). cpunk A major class of remailers. Supports Request-Remailing-To: field. eric A variant of the cpunk style. Uses Anon-Send-To: instead. penet The third class of remailers (at least for right now). Uses X-Anon-To: in the header. pgp Remailer supports encryption with PGP. A period after the keyword means that the short name, rather than the full email address, should be used as the encryption key ID. hash Supports ## pasting, so anything can be put into the headers of outgoing messages. ksub Remailer always kills subject header, even in non-pgp mode. nsub Remailer always preserves subject header, even in pgp mode. latent Supports Matt Ghio's Latent-Time: option. cut Supports Matt Ghio's Cutmarks: option. post Post to Usenet using Post-To: or Anon-Post-To: header. ek Encrypt responses in reply blocks using Encrypt-Key: header. special Accepts only pgp encrypted messages. mix Can accept messages in Mixmaster format. reord Attempts to foil traffic analysis by reordering messages. Note: I'm relying on the word of the remailer operator here, and haven't verified the reord info myself. mon Remailer has been known to monitor contents of private email. filter Remailer has been known to filter messages based on content. If not listed in conjunction with mon, then only messages destined for public forums are subject to filtering. Raph Levien

1 0

Re: Hardware RNG
by jamesd＠echeque.com 17 Dec '03

17 Dec '03

At 06:23 AM 6/30/96 -0700, Timothy C. May wrote: > 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). If he has more than eight bits of timing resolution, such biases will have no affect. He is using his non uniformly distributed random number to select a uniformly distributed pseudo random number. Provided that the does not attempt to get more entropy out than he puts in, the result should be a uniformly distributed truly random number. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0

FTS2000 Security Info and RFP
by Mark O. Aldrich 17 Dec '03

17 Dec '03

The URL's for FTS2000 RFP, Security Policy data, and assorted sundries are: http://post.fts2k.gsa.gov/ (the official government stuff) http://204.70.134.242/policy/ (This appears to be an MCI server and I don't know if they know that this stuff is online) Enjoy. ------------------------------------------------------------------------- |Just as the strength of the Internet is |Mark Aldrich | |chaos, so the strength of our liberty |GRCI INFOSEC Engineering | |depends upon the chaos and cacophony of |maldrich(a)grci.com | |the unfettered speech the First Amendment|MAldrich(a)dockmaster.ncsc.mil | |protects - District Judge Stewart Dalzell| | |_______________________________________________________________________| |The author is PGP Empowered. Public key at: finger maldrich(a)grci.com | | The opinions expressed herein are strictly those of the author | | and my employer gets no credit for them whatsoever. | -------------------------------------------------------------------------

1 0