December 2003 - cypherpunks-legacy

Re: PC disk wipe software
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Responding to msg by bdavis(a)dg.thepoint.net (Brian Davis) on Tue, 10 Oct 10:47 AM >FYI the Justice Department requires degaussing a hard >drive before it can be declared surplus ... ----- The Washington Post, Oct 9, 1995. E-Mail That Comes Back And Bites. Even Deleted Messages Can Be Recovered for Court [excerpts] Computer sleuth John Jessen dredges computer files for electronic embarrassments that their authors thought were long gone. "Deleted" e-mail messages can pile up like little time bombs until someone such as Jessen arrives, carrying a court order and a stack of blank memory cartridges. "Can you really delete e-mail? Sure," Jessen said. "Does it happen as a common practice? No." Jessen is the founder of Electronic Evidence Discovery Inc., a Seattle company that since 1987 has been going after computer evidence in civil lawsuits. The nation's 25 million to 40 million users of e-mail are growing more comfortable with the medium. And more attorneys are recognizing e-mail's potential as a source of unguarded information about the companies they're suing. "People are very candid talking around the coffee machine." attorney Michael Patrick of Palo Alto, Calif., said. "They seem to behave the same way on the computer system. "They think they're speaking confidentially, so they're off the cuff," he said. "They're very often insulting. What they don't realize is it's all being recorded, and often those recordings are stored for a very long time. When you send a message, you lose control over where it goes." Many workers think their e-mail is private. It's not. Federal law allows employers to monitor employees' e-mail, and even if they don't, e-mail is fair game in lawsuits. When someone sues a company, the rules of discovery demand that the company produce all relevant business records. "The fact that they live in a computer rather than a file cabinet doesn't make any difference to the court," said Joan Feldman at Computer Forensics, another Seattle firm that specializes in this work. Often files retrieved include e-mail thought to have been erased long ago. It survives because the diligent computer system manager makes backup tapes of everything on the system every night, then stores those tapes for years. And so the files persist and multiply, aided by technological advances that continually add more storage capacity, more automatic backups and more redundancies to safeguard data from accidental erasure. "The computer is like a file cabinet tbat can open its own drawer, put a file on the copy machine and then slip the copy into another cabinet," Jessen said. "Sometimes I think it's alive." Jessen and Feldman augment their high-tech detective work by advising companies how to become less vulnerable to computer snoops like themselves: They recommend regular purges of old data, and they offer tips for avoiding e-mail blunders in the first place. Rule No. 1: Don't put anything on e-mail that you wouldn't want a jury to see. -----

4 5

Banque des Cypherpunks
by sdavidm＠iconz.co.nz 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- C'punks, What would a cypherpunk bank (being a bank the style of which some cypherpunks would not hate too much :-) look like? How could it be made safe to run? One avenue of safety - shepherding the idea through SEC etc scrutiny so as to render the venture completely legal seems to lack something of a c'punk flavour. After all, one idea that some of us are quite taken with is that strong crypto and the changes it brings are not only important (they are), nor good (as Tim has pointed out - it depends where you stand) but *inevitable*. So, how safe would a cp style bank be today? There seem to be a number of possible pressure points: the machine, the operators, the managers/directors, the owners, the assets, getting money out of the system and getting money into the system. The Machine The easiest way to shut down an ebank is probably to unplug the machine the software is running on and take it away. A variation of this is to cut off net/telecomms access, or even electricity. (In the US/UK/NZ etc this would not seem to be too difficult - lie to a judge about a bit of child porn and you can pretty much take what you like.) Restricting ourselves to legitimate securities/banking enforcement, however, it would seem to be enough to move the box to some appropriate offshore site away from the major markets for the bank's services. Obviously, there is no need to actively advertise the physical location of the processor... The Operators Even if the authorities of the target jurisdictions (US, Europe, Asia) can't reach the operators of the machine while they are tending to it, they could, presumably, make it difficult for those people to leave their jurisdictions once they had entered them - by, for instance, issuing arrest warrants, or holding trials in absentia. Again, if the physical location of the machine is sufficiently obfuscated, this attack can be foiled. The Managers/Directors Assuming the bank is some kind of artificial legal entity, it will require some other legal entity to control its actions. That controlling entity could be themselves an artificial legal entity - for instance, a corporate director of an offshore company. The Owners Assuming the bank itself is not a natural person, it will be owned by someone (at least one list member has indicated an interest in investing in some form of ebank). These owners could be the subject of pressure. Using the same technology that made the ecash anonymous, the ownership of the bank could be made similarly unknowable. The Assets A bank isn't going to last long if the SEC can just take its 'deposits'. Fortunately there are still a number of jurisdictions left where the bank's bank account should be safe. Getting Money out of the System Eventually Tim is going to want to turn his Blacknet earnings into USD to reinforce his security perimeter. How do we stop the Feds effectively making it illegal to receive cheques from Banque des Cp? Presumably, BCp instructs its banks to issue bank cheques, or get bank cheques from other banks. Receiving wire transfers from Citbank may be notifiably suspicious, but that just makes you one of millions... Getting Money into the System This strikes me as the most serious problem. If we differentiate between big ticket (wholesale pharmaceutical type) and small ticket (remailer stamp type) transactions, it might just be possible that the former could be managed without bringing down the wrath of the authorities on the customers (having failed to effectivley attack the bank). Essentially the idea is to route payments through enough appropriate jurisdictions that tracing back from the ebank to the customer is impossible (or, rather, unlikely). Sticking a Libyan bank in the chain could help, for instance... But small ticket transactions can't use this route. The easiest thing to do would be to accept credit cards - but it wouldn't take much to convince Visa and Mastercard not to let their services be used, if not turn over details of everyone who tried to buy ecash. Cheques, TTs etc seem too cumbersome to be marketable, and, once again, too easy to trace - at least at first glance. The problem stems, I think, from trying to satisfy two seemingly opposed requirements - the customer must be sure who they are paying, but the authorities must not know the customer is paying the bank. Any ideas? [Another problem occurs to me. Alice's Awsome XXX CD-Rom Shoppe accepts BCp's BlackCash[TM]. Simon from the SEC buys a CD with BlackCash. "Asian Teenage Leather Maidens" duly arrives, and Simon arrests Alice for dealing in unauthorised securities (and unauthorised dealing in securities etc)...] I think I'll stop before I talk myself out of the whole thing :-) Cheers Dm -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMHtVEVlo3j8JHzalAQHT9wP/TV0AN7o4/yfkKw3G4SPrZWUO+LUFdDnD a9v6OKUZZ8LrPQ/XORq3dvtOFtJ6GNiOPZkAWQQI9Rm792PcW4mdF+ppKynjgt0A olK/wFnbBVhYwoEOXvqaC+ZwCTbaewpydEi3OEPGRoXbpDaYxQkfAj7K0dPT21sz TjV5qM+rt+M= =dTqF -----END PGP SIGNATURE----- [Palmtop News Reader - Beta Version 3]

6 5

SUPERWIPE pgp a / uuencode
by gjeffers＠socketis.net 17 Dec '03

17 Dec '03

Dear Cypherpunks, I used "PGP - A" to armor SUPERWIPE 1.04R for the first 10 C'punks to request it. I assumed that all the users would be PGP 'enabled. In case anyone of you weren't, please make another request for SUPERWIPE & specify that it be sent with UUENCODE armor & I will resend it with the UUENCODE armor. Yours Truly, Gary Jeffers

1 0

Re: How to hold a key signing party?
by jpb＠miamisci.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 5:59 PM 10/10/95, you wrote: >Joe Block writes: > > What I have in mind is to have everyone who is planning on attending send > > me their key and its fingerprint.... > > > > This seems like a lot of work, which I don't mind, but if there is a more > > efficient method, I'd like to know about it. > >Doesn't make any difference to me, you nefarious agent of the Great >Man In The Middle you. > > > >[ You got to get up *pretty early in the morning* to put one over on >*me* like that. ] Each person at the party would confirm what their key signature was so the other attendees could check their handout. They then take the handout that they have personally checked the key signatures on home with them so that when they recieve the keys from yours truly they can compare the fingerprint they get with the fingerprint the owner claimed for the key, which they checked against the handout when they were at the party, yes? -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMHtiEWGnwFiC3O2NAQFo5ggArfaPrtROH9QmB0luwrliH92fEguQAekd EsY46cEt1tGP3wXzvbVf6ArzZf/cs60Rsj71ufGVmPytF88VNfo/av0LhCGtNKAh imTTcWaFvMsSnpEm3qAUAWSJK5WVVlkW7wV0ZEt8YVrX7QZCaXqq2rKzCPwSh3Ga VToHUDBbRESgEOkS1FxKluZiXa1Ym5P4Nwepno72TXvn/V2flc7iItV0WpLbaL4p abNwCP/haFViMeg8QbmMXP5+hojFnptK/v7Wc/D7XlRFB6CezAY/duHBwPsNueWI t4zegApZulk/nJ9da319etZ8OPMWIy0Li7cHlfvwd4/7kbsDmJoLJg== =1qlc -----END PGP SIGNATURE-----

1 0

MITM garbage
by don＠cs.byu.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Scott Brickner writes: >By "successful" I mean communicating without the MITM *interfering*. >Either the parties need to exchange a symmetric key without the MITM >eavesdropping, or exchange asymmetric keys without the MITM modifying >them. First of all, I think this "you can't prove there's no MITM, so might as well not use crypto at all" stuff that some people believe is garbage. Once you've successfully gotten your key out, Mitch can't expect to mount an effective MITM attack "against" you. [isolating someone else from you is a different story] In fact, Mitch can't really MITM anyone who has any kind of cryptocontact with the general public. Obtaining a single non-mitch public key cuts the attack down the middle. Being able to get your key out without it being intercepted also foils the attack, since one there is suspicion of a MITM attack, people are going to investigate. You can't erase crypographic evidence of MITM activity, either. So, once your keys are actually "out there", you can no longer be effectively attacked without leaving messy trails here or there. The other problem, of course, is how do you know you haven't already been MITM'd. You don't. You can't, unless you expose it by publishing your key to someone though a channel that can't be D.O.S.'d. Publishing a hash/sig of future posts is not terribly practical, because not only does the hash/sig have to be expected beforehand but what the hash is for has to be known as well. If I publish a detached signature of something (could be my key, or might not be) then Mitch will just have to make something up, make a sig for it, and publish THAT. Posting the source code to RC5, for example, after sending out a hash first means that Mitch will have to send out whatever it was he hashed in place of my hash, and then make HIS hash of RC5 code, then quickly follow up with the actual code that I was kind enough to mail to him. And since Medussa is by definition "in the middle" I don't ever realize that any of that happened. I suppose the "overloading the processors" works well if you can be sure you've overloaded it, which means not only that you know already what Mitch's power is, but you know of someone else (a group perhaps) that has even MORE power, such that Mitch will stick out in the timing. So, if you ask me, none of _those_ methods are very trustworthy considering the resources you have to have already assigned to Mitch - after all, keeping a 24 hour Medussawatch on you and your whole ISP is tough work. Going _through_ Mitch is not easy. >The chance of failure is minimized by diversity in the channels used to >try to bypass the MITM. I agree-On the other hand, it's not terribly difficult to go _around_ Mitch. I mean, just how many of the following things has Mitch done: Watch all the ISP's in town and all the phone lines you can use to call them. Filter your work/school ISPs. Filter all your net-using neighbors, co-workers, and friends' accounts. etc. All it takes is to get one non-Mitch public key. Of course, once the MITM gig is up, the option of locking you in a room since 1983 will make Mitch the "new you", meaning there is no longer a middle. (Fortunately, though, Bob was MITM'ing Mitch at the same time, and now you're both out of the loop and Bob has the goods now, cuz what's Mitch gonna do about it?) >you can't afford a failure, you *do* need a channel over which you have >nearly complete control. The simplest such channel is a physical >meeting, during which you exchange public keys. If the MITM threat is How do you know you're not giving your key to Mitch. And how do you know that Mitch isn't headed over to Alice's later on to pretend to be you and give Alice "your" key? Don "Medussa for short" -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBMHtC+sLa+QKZS485AQEEmwL+NbEoXoeJPEBKGFev8gLWBCIoniyXS4o5 YyyGnkfTjsc/DimbU15z++d/fcihUzwK/dLKBXub3fdxcna9m9YyLNEdo8QyhPNb /Wp6PKq9SdfMb6uCzgoVwg7PrtTZzZEe =jN+h -----END PGP SIGNATURE----- <don(a)cs.byu.edu> fRee cRyPTo! jOin the hUnt or BE tHe PrEY PGP key - http://bert.cs.byu.edu/~don or PubKey servers (0x994b8f39) June 7&14, 1995: 1st amendment repealed. Junk mail to root(a)127.0.0.1 * This user insured by the Smith, Wesson, & Zimmermann insurance company *

2 1

Re: Man in the Middle Revisited (but not for the last time)
by tcmay＠got.net 17 Dec '03

17 Dec '03

I suspect I'm not the only one getting weary of going around and around on this issue, so I'll confine my response to just one point: At 3:37 AM 10/11/95, Bryce wrote: >> Who any of these entities "really" are is irrelevant to me. (I don't even >> know if Hal Finney, who I met once a few years ago, is the "real" Hal >> Finney, nor do I really care.) > > >Well and good, Tim, but you *do* care if the entity calling itself "Hal >Finney" is being surrounded by the Man in the Channel ("Mitch") and all >of your communications with that entity are under Mitch's control. For >example, you may choose to enter a contract with the entity calling >itself "Hal Finney", and provide some sort of consulting service to it >in exchange for 10,000 cyberbucks. If Mitch is actually in control >then he could easily steal both the output of your consultation *and* >Hal's 10,000 cyberbucks and leave the two of you hating each other. Nope. au contraire, negatory. I *do not* care if the entity calling itself "Hal Finney" is being surrounded by an MITM. Only "Hal Finney the Key" can read messages I encrypt to the public key I got from him long ago, so if the "Hal + MITM" can do so, they are effectively one and the same. (Not really, in some other senses, but far beyond anything simple crypto can handle.) --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

Elementrix POTP
by liberty＠gate.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hello again cypherpunks: Sorry to continue "beating a dead horse" here, but I forwarded a few C-punks' messages regarding the Elementrix "Power One-Time Pad" to this person, and I thought you might be interested in her (somewhat cryptic <g>) response. Forwarded message follows: ______________________________________________________________________ >Date: Tue, 10 Oct 1995 20:34:53 +0200 >From: Maia Aron <maia(a)elementrix.co.il> >To: liberty(a)gate.net >Subject: Re: POTP > > >Hi, it took me a little while to respond; we've been getting a lot of >inquiries following the Interop show. > >The short answer is: everything that people are guessing we are, including >the guesses mentioned in the cypherpunks info you attached, is not what we >are. I.e., it's not an autokey cipher, it's not like DES, there is no way >to track relationships between yesterday's and today's ciphertexts. The >encryption is not done by using an encryption algorithm. > > Unfortunately, and we really mean unfortunately, we can only reveal what >"it is" to people who agree to a non-disclosure arrangement while we're >patent pending. Otherwise we would have no problem revealing the whole >method. So far, every international expert who has reviewed the method >agrees (after many, many hours and days of trying to find holes) that POTP >really does what we say it does. > >You can share this with whomever you'd like. Sorry I can't say much more. > > > >Regards, > >Maia Aron >Vice President, Marketing >Elementrix Technologies Inc. >850 Third Avenue >New York, NY 10022 > >phone: 212-888-8879 >fax: 212-935-3882 >email: maia(a)elementrix.co.il ______________________________________________________________________ End of forwarded message. So, I guess we know what they *aren't*, but not what they *are*...Is this the first example (in modern history) of encryption that's *not* done by using an encryption algorithm, or am I just missing something? JMR -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Freedom isn't Freeh iQCVAwUBMHrisW1lp8bpvW01AQEauQQAlFI8Xu3w1Zjo53rnejjp/UqVw9f9Gdfa I4/bHqnpsJHI+W+HPbCzjWHV30lNJzMW1wWDBNpqNmjOr5jYmYJN7x0SX8QrXmCT sZlrM0Pc+Pzc9OvsB/tw8T0bwXWPMi5b3qu5jQwHp5e+aujCdQRSr7digJscVhEN i+WwbMEPFa8= =Psa8 -----END PGP SIGNATURE----- Regards, Jim Ray Ray's Corolary to Murphy's Law: "You will be spared _NOTHING_." -- Peter C. Ray [my dad]. ----------------------------------------------------------------------- PGP key Fingerprint 51 5D A2 C3 92 2C 56 BE 53 2D 9C A1 B3 50 C9 C8 Key id. # E9BD6D35 James Milton Ray <liberty(a)gate.net> IANAL ----------------------------------------------------------------------- Help Phil! email zldf(a)clark.net or see http://www.netresponse.com/zldf _______________________________________________________________________

4 3

MITM evasion MITM evasion
by anon-remailer＠utopia.hacktic.nl 17 Dec '03

17 Dec '03

Two years ago, I pointed out that getting a single message past the man in the middle isn't good enough; you have to convince your readers that the key they received on one channel is more accurate than the key they're receiving on all the other channels. But if they'll believe that, they may also believe the man in the middle's announcement that the key in your name on all the keyservers is wrong, and the correct key is the one he's putting out. Can't win either way, but it's still important to get the key out. My current key is 0x54696D4D; the fingerprint is 4D 65 44 75 53 61 21 2F 41 73 55 64 85 6D 21 7F. .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)sensemedia.net | anonymous networks, digital pseudonyms, zero 408-728-0152 | knowledge, reputations, information markets, Corralitos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

3 2

PKP Lawsuit progress report
by rschlafly＠attmail.com 17 Dec '03

17 Dec '03

I have a lawsuit against Public Key Partners and RSA Data Security. (Schlafly v. PKP & RSA, Case C-94-20512 SW PVT.) (1) PKP has been ordered dissolved by an arbiter. The MIT patent returns to RSA Data Security, and the Stanford patents go under the control of Cylink. I am happy to report that my lawsuit contributed to this outcome. (2) I will soon be deposing: Whit Diffie Ralph Merkle Martin Hellman Ron Rivest I will be asking all the obvious questions. My purpose is to break their patents. Does anyone have anything special for me to ask? If so, please send me your ideas. (3) There will be a hearing on the patent validity (and a couple of annoying technical legal issues) at 10:00 am, Dec. 6, 1995, in the court of Judge Spencer Williams, Federal Bldg, 280 S. First St, San Jose CA 95113. The US court clerk is at 408-291-7783. It is open to the public. Roger Schlafly rschlafly(a)attmail.com

1 0

Checksums for current release versions of Netscape Navigator
by Jeff Weinstein 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This file contains checksums for the Netscape Navigator 1.12 and 1.22 distributions and patch files that are available on the Netscape ftp site under the directory ftp://ftp.netscape.com/netscape/. This file has been digitally signed using PGP to assure its authenticity. The version of PGP which was used to create the digital signature on this document was obtained from http://bs.mit.edu:8001/pgp-form.html/. This file was signed using my private key. It can be obtained from my web page using this URL: http://home.netscape.com/people/jsw/my-pgp-key.txt or by searching for 'jsw(a)netscape.com' from the PGP key server at mit: http://www-swiss.ai.mit.edu/~bal/pks-commands.html#extract There are three sets of checksums in this file. The first set of checksums uses MD5 to create 128-bit checksums that can not be forged. The second and third sets of checksums were generated using the two forms of the unix 'sum' command. The 'sum' command creates a 16-bit checksum, which can be used detect accidental corruption during download, but is too small to protect you from malicious tampering. There are two version of the checksums for the unix 'sum' command because unix vendors follow two different standards. I have labeled the checksums with the systems that they are good for. If you are performing the checksum operation on a unix system that is not listed, check both lists and make sure that one matches. --Jeff ============================================================ These MD5 checksums were generated with the 'md5sum' program from the PGP2.6.2 distribution, which was obtained from http://bs.mit.edu:8001/pgp-form.html/. 4355327d682ee02b34384cbb30e8042d ./mac/netscape-1.12.hqx 314326ea7f6e16a7ed51b4ddd32830dc ./mac/patch_1.1_to_1.12/nscp_1.1_68K_update.hqx af1e3a626a3ba3e903e9268bdacdd879 ./mac/patch_1.1_to_1.12/nscp_1.1_FAT_update.hqx dc70e43f7541cdcca334cf81a53fe5ab ./mac/patch_1.1_to_1.12/nscp_1.1_PPC_update.hqx 44ab217346102d4bd3c8b648ac915eb7 ./unix/netscape-v112-export.alpha-dec-osf2.0.tar.Z 2b359e275d4f18fc532cc33eeda05f06 ./unix/netscape-v112-export.hppa1.1-hp-hpux.tar.Z 5eaba5768b4bc35e869659a720221eec ./unix/netscape-v112-export.i386-unknown-bsd.tar.Z 0b94e22d6e103dc1425eb5587be5e639 ./unix/netscape-v112-export.i486-unknown-linux.tar.Z 858389abea7cd4aa2211d28e4637cbf8 ./unix/netscape-v112-export.mips-sgi-irix5.2.tar.Z 0a8dedc135abe48405cd663d77a53496 ./unix/netscape-v112-export.rs6000-ibm-aix3.2.tar.Z 40a1c0418d4273b198bf82f4520bc483 ./unix/netscape-v112-export.sparc-sun-solaris2.3.tar.Z 5f0e785bdf1e7e6fadeb79a3cc77daf5 ./unix/netscape-v112-export.sparc-sun-sunos4.1.3_U1.tar.Z d9e4b2c7d5b18992d900c3299fbbcf33 ./windows/n16e122.exe fd59a0505d0e29a20703409e47eef9ee ./windows/n32e122.exe 9cef44bb905ce05af46012482f1b1e28 ./windows/patch122/n16d122p.exe 77e5634c83b79615e8d085c9187721d7 ./windows/patch122/n32d122p.exe ============================================================ These checksums were generated using the Unix 'sum' command. These checksums are for the form of the sum command that is on SGI IRIX and HPUX systems. 33513 2993 ./mac/netscape-1.12.hqx 56041 482 ./mac/patch_1.1_to_1.12/nscp_1.1_68K_update.hqx 36637 859 ./mac/patch_1.1_to_1.12/nscp_1.1_FAT_update.hqx 28284 460 ./mac/patch_1.1_to_1.12/nscp_1.1_PPC_update.hqx 39304 5287 ./unix/netscape-v112-export.alpha-dec-osf2.0.tar.Z 26165 4285 ./unix/netscape-v112-export.hppa1.1-hp-hpux.tar.Z 37396 3262 ./unix/netscape-v112-export.i386-unknown-bsd.tar.Z 26207 3164 ./unix/netscape-v112-export.i486-unknown-linux.tar.Z 39858 2068 ./unix/netscape-v112-export.mips-sgi-irix5.2.tar.Z 6109 2000 ./unix/netscape-v112-export.rs6000-ibm-aix3.2.tar.Z 2249 3420 ./unix/netscape-v112-export.sparc-sun-solaris2.3.tar.Z 62215 7254 ./unix/netscape-v112-export.sparc-sun-sunos4.1.3_U1.tar.Z 18716 3254 ./windows/n16e122.exe 20238 3494 ./windows/n32e122.exe 6931 210 ./windows/patch122/n16d122p.exe 34741 480 ./windows/patch122/n32d122p.exe ============================================================ These checksums were generated using the Unix 'sum' command. These checksums are for the form of the sum command that is on Sun, DEC OSF/1, AIX, BSDI, and Linux systems. 51500 1497 ./mac/netscape-1.12.hqx 43890 241 ./mac/patch_1.1_to_1.12/nscp_1.1_68K_update.hqx 62256 430 ./mac/patch_1.1_to_1.12/nscp_1.1_FAT_update.hqx 09953 230 ./mac/patch_1.1_to_1.12/nscp_1.1_PPC_update.hqx 32352 2644 ./unix/netscape-v112-export.alpha-dec-osf2.0.tar.Z 03948 2143 ./unix/netscape-v112-export.hppa1.1-hp-hpux.tar.Z 02857 1631 ./unix/netscape-v112-export.i386-unknown-bsd.tar.Z 17319 1582 ./unix/netscape-v112-export.i486-unknown-linux.tar.Z 53470 1034 ./unix/netscape-v112-export.mips-sgi-irix5.2.tar.Z 05441 1000 ./unix/netscape-v112-export.rs6000-ibm-aix3.2.tar.Z 02463 1710 ./unix/netscape-v112-export.sparc-sun-solaris2.3.tar.Z 17806 3627 ./unix/netscape-v112-export.sparc-sun-sunos4.1.3_U1.tar.Z 22208 1627 ./windows/n16e122.exe 04365 1747 ./windows/n32e122.exe 32585 105 ./windows/patch122/n16d122p.exe 37352 240 ./windows/patch122/n32d122p.exe -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMHt6O6wWZfp0yzT1AQGrgwP/QF1AY9Wp44OjK0he3E+IRq9VbuxXrn1H NjNWuSxOLlWrDYiIDu9L+pbCmz2Fu8+3S9c8J4sz80Rzd73kT5xL8dfbQBb7GwqD Xot99yYrwNaSPRkixHk+n1M4sVHe2UO6u+tZJDYM2PFcy5Ycdw7qQGvEfy1rJTWN 8Y/tYU9eQx4= =lu96 -----END PGP SIGNATURE----- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw(a)netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.

1 0