December 2003 - cypherpunks-legacy

Re: Spoofing HTTP server certificates
by Bill Stewart 17 Dec '03

17 Dec '03

At 12:52 AM 10/2/95 -0400, Greg Miller <gmiller(a)grendel.ius.indiana.edu> wrote: > Since there has been a lot of talk about the "man in the middle" >attack on the secure web servers, has anyone actually considered the >processing time required to fake a certificate from scratch? > I haven't really familiarized myself with how the certificates >are generated, etc, but it's my understanding that they are signed with RSA. While I haven't seen Verisign's various public keys posted to the net, and didn't see them anywhere on their web page, I assume they're at least 508 bits long, and the ones for better-than-personna certification (or at least Class 3) ought to be ~1024 bits long, unless they're limiting themselves to 512 bits to support software that's limited by ITAR stupidity (which would be a shame, but is certainly possible.) For the moment, breaking a 512-bit key remains hard, though maybe within the NSA's reach. It's probably one of the next big factoring challenges after the RSA-130 number is taken out by the General Number Field Sieve folks. The better fake, which is much more possible, is to build a chain of certifications (trivial) and convince your victim to accept them instead of the real ones (more doable, especially if some vendor's software isn't written carefully, or is written carefully but requires the user to think about what he's reading.) #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

2 1

European Email Police (fwd)
by Duncan Frissell 17 Dec '03

17 Dec '03

This may be of interest to cypherpunk folk (yanked from the UK Electronic Telegraph: http://www.telegraph.co.uk) P. Madden =============================================================== The Electronic Telegraph Monday 2 October 1995 The Front Page Plan to police e-mail seems certain to fail By Adrian Berry, Science Correspondent A EUROPEAN Commission plan to police the use of secret codes in electronic mail appears certain to fail. To detect criminals, the commission is seeking legal powers to prevent people from using secret codes on the Internet which it cannot crack. Nature magazine says this would "effectively end the Internet's status as an unregulated medium for the free flow of information". The plan would require any person or company encrypting e-mail messages to leave the "secret keys" to read them in the hands of a law enforcement agency. But Dr Peter Lammer, managing director of Sophos, the Abingdon-based supplier of encryption software, said: "This plan would never work because people wishing to evade it could legitimately use layers of encryption. "Suppose I send a secret file. I would first encrypt it with my own system. I would then obey the law by encrypting it a second time with the European-approved system. "Even when the government agency had decrypted the message using the keys they had been given, they would still find that the message was totally unintelligible because of the second layer of encryption." In France, it is illegal to use any kind of encryption, and police can arrest the authors of any e-mail which they cannot understand. Codes are used by a vast range of financial companies, sending money orders and sensitive commercial details. Reply to Electronic Telegraph - et(a)telegraph.co.uk Electronic Telegraph is a Registered Service Mark of The Telegraph plc

1 0

Re: FORGED CANCELS of posts on n.a.n-a.m
by dlv＠bwalk.dm.com 17 Dec '03

17 Dec '03

In article <modemacDFr0qB.IyK(a)netcom.com>, Rt. Rev. Modemac writes: >Dr. Dimitri Vulis (dlv(a)bwalk.dm.com) wrote: >: The National Alliance are not the first despicable racist net.abusers who forge >: cancels for other people's articles critical of them on n.a.n-a.m. Ken Arromdee >: has condemned one such forger, the graduate student Pyotr Vorobiev from Lehigh >: University's Mechanical Engineering and Mechanics Department (+1 610 758 4100) > >When Scientology began cancelling posts by their critics on >alt.religion.scientology, Homer Wilson Smith wrote a program called >"Lazarus" to track for cancels. The idea is simple: whenever a cancel >message appears, Lazarus announces it on the newsgroup. > >Mayhap a Lazaraus-type program can be put into effect on >news.admin.net-abuse.misc? Many other newsgroups are affected by such net.abuse (Vorobiev-style forged cancels based on contents); I just saw some messages on forged cancels in soc.culture.jewish and soc.culture.german. I think running Lazarus-like programs in _all_ newsgroups would be an extremely Good Idea. Alas, the time when people used to contribute their time and equipment for the public good of the net seems to be over. Peraps I'm just dreaming; or perhaps Dave Hayes will like the following idea enough to implement it. Also, I think it's a matter of time before some Cancelpoodle figures to put 'light' into the Path: of its Vorobiev-style forged cancels; then they will not be seen by lighlink.com where Lazarus now runs. This needs to be addressed. Anyway, here are my thoughts on this proposal: There would be a collection (at least 5 or 6) of cancel-watchers (sort of like the deamons that now watch misc.test) all over the world. They should be well-connected (preferrably, one hop away from sites like uunet, howland.reston.ans.net, etc). Each watcher would look at incoming articles in "control", and whenever it sees a cancel, it would replace its own uucp name in the path by something like ellipsis (to keep it confidential) and forward the cancel to a central cataloguer (singly or in batches). E.g., is a watcher at xyzz123.uucp saw a cancel with the header Path: xyz123!howland.reston.ans.net!someplace it would send it to the cataloguer with the Path: replaced by Path: ...!howland.reston.ans.net!someplace The cataloguer would wake up every few hours (for example), group the collected cancels by message-ids of the cancelled articles, and e-mail reports to the (distinct) addresses (other than "usenet@*" or "news@*") mentioned in the "From:", "Sender:", "Authorized:", and "X-Cancelled-By:" headers, and quoting the entire cancel and the Path's as seen at different sites by the cancel-watchers. This way, if the cancel is forged, its author will learn within hours that it has been fraudulently cancelled and will automatically receive enough Path: samples from all over the world to see where it was posted, by comparing the Path headers in several copies of cancels. A user or an entire site should be able to "opt out" of having its cancels reported by sending a command to the cataloguer. There should be a limit of, say, no more than 100 such notifications sent to a site in one batch (to prevent too much traffic in the event of really massive forged cancellation). I don't have the resources to do this right now, but I would be happy if some civic-minder netters took this proposal and ran with it. --- Dr. Dimitri Vulis Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

2 1

SAI_cya
by John Young 17 Dec '03

17 Dec '03

10-2-95. W$Japer: "Internet Users Spooked About Spies' New Role." Web Review reported last week that the company in charge of assigning domain names, Network Solutions Inc., had been acquired by Science Applications International Corp., a closely held company which has many former intelligence and defense officials on its board. Web Review raised questions about whether SAIC is acting as camouflage for the government. Users of the Internet, which was originally created as a communications medium for Defense Department researchers, are reacting to the news with hostility. "I don't want a spook corporation, particularly a private spook corporation, to be anywhere near a control point on the global cooperative Internet," says James Warren. SAI_cya (8 kb)

1 0

Re: DNS Security ( was Re: NetScape's dependence upon RSA down...)
by kerowe＠ncsa.uiuc.edu 17 Dec '03

17 Dec '03

At 1:58 PM 10/1/95, Donald E. Eastlake 3rd wrote: >DNS security is an important point. People not aware of efforts in this >area may want to check out draft-ietf-dnssec-secext-05.txt which has >more or less passed working group last call and is being considered by >th Security Area Directory / IESG. Reference code is also available >(see message pasted at end below). > >Donald But the proposed DNS extension itself does not deal with CRL and Key Compromise Lists. Ken. ------------------------------------------------------------- Kenneth E. Rowe (kerowe(a)ncsa.uiuc.edu) Senior Security Engineer (217) 244-5270 (Office) / Security Coordinator (217) 244-0710 (NCSA IRST) National Center for Supercomputing Applications *** email ncsa-irst(a)ncsa.uiuc.edu for computer incident response ***

2 1

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, which is available at: ftp://ftp.csua.berkeley.edu/pub/cypherpunks/premail/premail-0.33.tar.gz 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)extropia.wimsey.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{"bsu-cs"} = "<nowhere(a)bsu-cs.bsu.edu> cpunk hash ksub"; $remailer{"c2"} = "<remail(a)c2.org> eric pgp hash reord"; $remailer{"penet"} = "<anon(a)anon.penet.fi> penet post"; $remailer{"ideath"} = "<remailer(a)ideath.goldenbear.com> cpunk hash ksub reord"; $remailer{"hacktic"} = "<remailer(a)utopia.hacktic.nl> cpunk mix pgp hash latent cut post ek"; $remailer{"flame"} = "<remailer(a)flame.alias.net> cpunk mix pgp. hash latent cut post ek reord"; $remailer{"rahul"} = "<homer(a)rahul.net> cpunk pgp hash filter"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord"; $remailer{"syrinx"} = "<syrinx(a)c2.org> cpunk pgp hash cut reord mix post"; $remailer{"ford"} = "<remailer(a)bi-node.zerberus.de> cpunk pgp hash ksub"; $remailer{"hroller"} = "<hroller(a)c2.org> cpunk pgp hash mix cut ek"; $remailer{"vishnu"} = "<mixmaster(a)vishnu.alias.net> cpunk mix pgp hash latent cut ek ksub reord"; $remailer{"crown"} = "<mixmaster(a)kether.alias.net> cpunk pgp hash latent cut mix ek reord"; $remailer{"robo"} = "<robo(a)c2.org> cpunk hash mix"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{"spook"} = "<remailer(a)spook.alias.net> cpunk mix pgp hash latent cut ek reord"; $remailer{"gondolin"} = "<mixmaster(a)gondolin.org> cpunk mix hash latent cut ek ksub reord"; $remailer{"rmadillo"} = "<remailer(a)armadillo.com> mix cpunk pgp hash latent cut"; $remailer{"ncognito"} = "<ncognito(a)gate.net> cpunk"; $remailer{"precip"} = "<mixmaster(a)mix.precipice.com> cpunk mix pgp hash latent cut ek reord"; $remailer{"ecafe"} = "<remail(a)ecafe.org> cpunk"; $remailer{"wmono"} = "<wmono(a)spook.alias.net> 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. Use "premail -getkeys pgpkeys(a)kiwi.cs.berkeley.edu" to get PGP keys for the remailers. Fingering this address works too. News: the remailer list has been rewritten, and the new version is live! It should be more accurate, reliable, and faster than before. Penet is back up! Enjoy. remailer email address history latency uptime ----------------------------------------------------------------------- syrinx syrinx(a)c2.org --+-+++----+ 52:32 100.00% ecafe remail(a)ecafe.org *--********# 7:37 99.99% alumni hal(a)alumni.caltech.edu *##*#**+#*## 2:47 99.99% hacktic remailer(a)utopia.hacktic.nl *********+** 9:56 99.98% gondolin mixmaster(a)gondolin.org --+****+*--+ 2:04:31 99.98% robo robo(a)c2.org #+###**+#*## :59 99.98% replay remailer(a)replay.com +**+*-++*++* 11:35 99.95% bsu-cs nowhere(a)bsu-cs.bsu.edu #*#+###***-# 8:29 99.95% mix mixmaster(a)remail.obscura.com -++---+---++ 1:35:11 99.94% flame remailer(a)flame.alias.net *****++**+** 23:08 99.93% portal hfinney(a)shell.portal.com ## ##*+#*## 2:03 99.79% crown mixmaster(a)kether.alias.net ---+ --+-+- 1:18:05 99.70% ideath remailer(a)ideath.goldenbear.com -.-.---.--- 10:24:01 99.68% extropia remail(a)extropia.wimsey.com -.---.----- 8:06:45 99.54% rmadillo remailer(a)armadillo.com ++ +++++ ++ 43:52 99.08% vishnu mixmaster(a)vishnu.alias.net *+--*+ +** 20:36 98.79% c2 remail(a)c2.org ++++++ +++ 47:07 98.74% spook remailer(a)spook.alias.net ----------- 3:27:18 98.64% penet anon(a)anon.penet.fi - ++-++--++ 2:43:34 98.63% hroller hroller(a)c2.org #+###* **# :57 92.70% rahul homer(a)rahul.net **#****+### 2:05 99.52% wmono wmono(a)spook.alias.net **** 7:37 87.49% ford remailer(a)bi-node.zerberus.de **+*#***+ 6:37 68.05% 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

`Hack Microsoft' challenge is NYT Computer News Daily's top story
by Rick Busdiecker 17 Dec '03

17 Dec '03

See http://nytsyn.com/live/Lead/275_100295_074418_19095.html MICROSOFT BECOMES NEW TARGET OF HACKING CHALLENGE (10/2) By HEATHER GREEN c.1995 Bloomberg Business News BERKELEY, Calif. -- Microsoft Corp. has been chosen as a new target for computer hackers. Community Connexion, an Internet service provider that last week promised a free T-shirt to anyone who found a flaw in Netscape Communications Corp.'s software, extended the challenge Friday to include holes in Microsoft products. . . . The article quotes Sameer and includes the URL http://www.c2.org/hackmsoft/ -- Rick Busdiecker Please do not send electronic junk mail! net: rfb(a)lehman.com or rfb(a)cmu.edu PGP Public Key: 0xDBD9994D www: http://www.cs.cmu.edu/afs/cs.cmu.edu/user/rfb/http/home.html send mail, subject "send index" for mailbot info, "send pgp key" gets my key A `hacker' is one who writes code. Breaking into systems is `cracking'.

3 2

Re: X.509, S/MIME, and evolution of PGP
by Carl Ellison 17 Dec '03

17 Dec '03

>Date: Wed, 27 Sep 1995 15:22:08 -0700 >From: Bill Stewart <stewarts(a)ix.netcom.com> Bill, >I'd always heard X.509 public key certificates were a hierarchical, evil, >anti-WebOfTrust ISOism. But Netscape is now doing them, and talking S/MIME, >so I sat down to read the specs, and they're really not all that bad. I was all set to scream, when I read this first sentence. Then I read on. >(Technically, I've only read PKCS#6 and RFC 1422, and not the real ISOisms...) >Yeah, they've got lots of clunky ASN.1 Ambiguous Encoding Rules and X.500 >Silly Name Format, but those can be lived with, and the X.500 may be possible >to simply ignore in most cases. At this point, I realized that we agree in evaluation but not in weighting. Twice now, I have had to deal with X.509 certificates in real code and it is excruciatingly painful -- especially for someone, like me, with some background in performance engineering and much background in software engineering. ASN.1 is not merely ambiguous, it is actively wrong as part of a design methodology. It encourages people to define structures in the BNF style -- and they do (witness X.509). When you translate this into C or PASCAL structures by an automatic translator, you end up with structures whose definitions are nested so deeply that even with short field names you would have variable names which occupy a substantial part of a line of text. However, ASN.1's BNF-ness encourages people to use longNamesWithEmbeddedCapitals -- so you end up with variable names which turn routine C function calls into multi-line, unreadable blocks. You also end up with too much code. I recently had to deal with X.509 certs for an authentication application (a firewall proxy). The proxy was about 30KB of code prior to the ASN.1. The ASN.1 code, just to do packing and parsing, was over 100KB (.o file sizes, in both cases). You also end up with too many bytes being transferred. I worked out an example of ASN.1 abuse -- defining a triple-DES key structure for encrypting and transmittal -- as a raw C structure (following long established practice and performance engineering (an array of unsigned char, with offsets for each key and the IV)) and as ASN.1 (following modern ASN.1 practice). The raw C structure was 32 bytes long. The ASN.1 structure was 86 bytes. Worse was the code dedicated to structure definition and packing/unpacking. In the raw C case, it took 48 ASCII characters to define the structure and its offsets (including comments) and nothing to pack/unpack. With ASN.1, it took 55085 characters of definition, pack and unpack code. This is a factor of 1148 in source code expansion. -------------------------------- I could go on at length, and have in other fora. Not only is ASN.1 clearly the work of Satan, the Distinguished Name definition is more than a victim of ASN.1 generality, it is a clear reason for the unpopularity of systems which use it. Do you remember when X.400 names started showing up in e-mail (e.g., with Lotus Notes). How many of those names do you see now? It didn't work. The concept is flawed -- but it lives on in X.509. [It reminds me of a flaky grad student's idea of a way to do things -- elevated to standard before people had the chance to try it and discover how completely bogus it was.] It is possible to implement something which reads and writes ASN.1 -- but it is ugly, it inflates your code and it hurts your runtime. I would like to see as many hold-outs against ASN.1 and Distinguished Names as possible. PGP is one such. TIS/MOSS has learned its lesson (from PEM days) and is making all of the ASN.1 and DN stuff (X.509) optional. With luck, the X.509 parts will die away (although MOSS was retarded so strongly in the PEM days that it may never recover -- may never acquire the market share to make it a force). I would strongly encourage others to join the battle. This might not be easy. It is clear that there is an ASN.1 juggernaut. It is taking over all sorts of standards. I believe I know why. It makes the job of the standards writer easier. However, I also believe it needs to be fought...not merely to save future S/W development efforts from the waste and abuse which ASN.1 creates, but also to take a stand against the process by which non-implementors get together on standards committees and come out with standards which preclude good software architectures -- and who, in a kind of old-boy-network, endorse other standards (e.g., the ISO set) as part of their own. Such a design process is destructive. - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme(a)tis.com http://www.clark.net/pub/cme | |Trusted Information Systems, Inc. http://www.tis.com/ | |3060 Washington Road PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2| |Glenwood MD 21738 Tel:(301)854-6889 FAX:(301)854-5363 | +--------------------------------------------------------------------------+

2 2

One-Time-Pad generation from audio device
by Rev. Mark Grant 17 Dec '03

17 Dec '03

Over the weekend I hacked up a one-time-pad generator from the random number code I've been writing for Privtool, which uses noise from the audio device to generate random numbers. The code basically reads in a 512-byte block from /dev/audio, then takes the MD5 of that block to generate 16 bytes of the OTP. The raw audio data I'm getting is not particularly random and will compress by 3:1 using gzip or compress, so I'm assuming that using a 32:1 ratio here via MD5 will give a truly random output (it's certainly uncompressible). Before I release the source code to the Net, can anyone give me any good reasons to believe that this won't produce physically random output, or make suggestions on how to test, or improve, the generated output ? There's a #define which can be used to easily increase the amount of data fed into the MD5, but at the moment it will only generate about 1 MB per hour on a Sparcstation (limited by the audio input rate), so I don't want to increase that if I don't have to. Mark

3 3

Introducing Johnson-Grace
by Publisher Program 17 Dec '03

17 Dec '03

Dear Web Publisher: You may have never heard of Johnson-Grace Company, but you have probably seen the benefits of our image compression technology in America Online and Apple's eWorld. "ART" compression substantially speeds up image transfers. In fact, ART formatted images transmit three times faster over conventional telephone lines than old-style GIFs and JPEGs. The immediate benefit is dramatically more compelling online content. Many of the hottest areas on AOL and eWorld are taking advantage of ART technology, including ABC, Business Week, The Smithsonian, NY Times, and 800-Flowers. Now, Johnson-Grace is able to offer the same benefit to Web publishers. To help you immediately reap the rewards of ART image compression on your Web site, Johnson-Grace is offering publishers the latest copy of our ART Press(TM) on a FREE trial basis for the remainder of calendar 1995. ART Press lets you easily convert your images to the ART format with its unique Web and online publishing features. For example, our proprietary Splash(TM) feature displays a full-size image in roughly one second; the image then becomes sharper as more detail is received and decompressed in additional layers, producing a high-quality final image within seconds. To get your free trial copy of ART Press, simply sign up for the "Johnson-Grace Publishers Program," a new program designed specially for Web and online publishers. At the foot of this email is an enrollment form. Just fill it out and email or fax it back to us. We'll send you the software right away (usually within 24 hours). For even faster results, just sign up online through the Johnson-Grace Web site (http://www.jgc.com/) Besides receiving ART Press, another prime benefit of joining our Publishers Program is that you will be automatically notified when any new versions of the software become available. Here are two more benefits: * FREE Technical Support -- For the remainder of calendar 1995 you will receive free expert technical advice on using ART Press. Support is available by email or by phone. * FREE Image Compression -- To help you get started with ART Press, Johnson-Grace will compress your original images into the ART format free of charge. Simply provide them to us in BMP, TIFF, or PICT format, and we'll do the rest. We've devised a method for allowing both ART and non-ART images to be accessed from your Web site depending on whether or not an ART-enabled browser is being used. Johnson-Grace and some of the larger browser companies have introduced a new extension to HTML, the X-ALTSRC attribute in the <IMG> tag. (<IMG> is the standard tag used to insert images into a Web page.) It indicates to ART-enabled Web browsers that an ART image is present. When an X-ALTSRC attribute is found, ART-enabled browsers will automatically use the ART image named in it, bypassing a SRC attribute it may find naming a GIF (or JPEG) image. Browsers that do not recognize the X-ALTSRC attribute will ignore it and read the SRC attribute instead, so there's no risk of incompatibility with these "old-style" browsers. Currently, AOL's built-in TurboWeb browser as well as other Web browsers including GNN and TeacherSoft recognize this new HTML attribute, representing a community of well over three and a half million users. As announced by Netscape, Johnson-Grace will be one of the first companies to provide a free plug-in for Netscape 2.0 which will allow Netscape users to take advantage of the ART format. This plug-in will be delivered as a "virtual bundle" so that support for the ART format will be automatically added to the browser the first time an ART image is encountered. Additionally, Johnson-Grace is in discussions with all the other major Web browser companies to include ART technology in their products. We expect broad support by the end of the year. Check out the Johnson-Grace Web site (http://www.jgc.com) to learn more about how to use ART's triple-speed advantage on your Web site. You'll also find a host of other useful information there designed specifically for publishers. In the months ahead, look for Johnson-Grace to provide additional "Instant Publishing" capabilities for Web and online service publishers. For example, later this year you'll see news of ART speech compression technology that will enable publishers to author interleaved sound and images for real-time playback at 14,400 bits per second. Think about what real-time sound can do for your Web pages! If you have any questions about the program, feel free to email techsupport(a)jgc.com. You can also call Tech Support at (714) 759-0700, or fax us at (714) 729-4643. Best regards, Geoff LeBlond VP, Licensing Johnson-Grace Company Enrollment for Johnson-Grace Publishers Program Please provide the following information to enroll in the Johnson-Grace Publishers Program Name: Title: Company Name: Company Address1: Company Address2: Company Address3: Company Address4: Telephone Number: Fax Number: email Address (email address is required to process your request) : Version of Software needed [ ] Windows [ ] Macintosh [ ] Both Type of Publisher (select one) [ ] Newspaper, Magazine, or Newsletter [ ] Merchant [ ] Company (e.g., product and sales information) [ ] Government or Non-Profit Organization [ ] Other (please specify) : Target Audience (check all that apply) [ ] Web [ ] Online Service(s) [ ] Both Web Site Information (1) Home Page Location (URL): (2) Launch Date: (3) Webmaster e-mail address: Note: By sending this registration form to Johnson-Grace Company, you agree to follow the following Publishers Program restrictions. (1) Do not use a trial version of ART Press after the end of the trial evaluation period. (2) Only Web and online service publishers -- defined as companies, organizations, or entities that offer content or information for display on the Web or on an online service for commercial purposes -- may qualify to participate in the Johnson-Grace Publishers Program. (3) Do not distribute copies of the program (all users must enroll), or attempt to reverse engineer the program. (4) Report any problems with the program to the Publisher Support Hotline at internet address techsupport(a)jgc.com, fax 714-729-4643, or telephone 714-759-0700 (ext. 215 or ext. 230).

2 1