December 2003 - cypherpunks-legacy

Re: noiz-0.5: simple noise-emitting package
by Matt Blaze 17 Dec '03

17 Dec '03

This looks really cute, especially given the ability to "precompute" entropy before the process that needs it is running. An interface I'd rather see is one that allows a process to grab random bits that it can be sure are not correlated to bits that have been given to other processes. Since everything runs asynchronously with cron, you have no way of knowing how much time has elapsed since the last time the file was read or updated, and hence don't know how "fresh" the bits are. Also, /etc/noiz is an attractive target on multi-user machines.... So I'd rather see a /dev/noise, although a portable implementation of somthing like that is out of the question now that there are 10 gazillion unix vendors. Perhaps a more reasonable implementation would be a tcp or rpc service that processes can query to get random bits, where the server delays responding until it can guarantee that its state is sufficiently decorrelated from previous responses. Because you can "bank up" entropy during idle periods, most requests could probably be served without delay, making this technique a real advantage over just implementing the same functions in a library called directly. (Since good randomness is still rather expensive even when you can store it up, and useless when sent over a network, you'd probably want the noise server to refuse requests from outside the local machine.) Anyway, I'm looking forward to playing with it. It's a very nice idea. -matt

1 0

!NYC Cypherpunks meeting 2/11/95!
by Arsen Ray Arachelian 17 Dec '03

17 Dec '03

Incase you're in the NYC area, there is a meeting this Saturday. (If you're already on the list of NYC Cypherpunks, you'd have received the notice with the address.) If you're in NYC, but not on the NYC Cypherpunks list, and you need info, please send email to me, rarachel(a)photon.poly.edu, and I'll give you directions. See you there.. --Ray. =============================================================================== | + ^ + || ' . . . . . . . Ray (Arsen) Arachelian || | \|/ || . . . ' . ' . : . . rarachel(a)photon.poly.edu || |<--+-->||. . . |' '| .' . . ... ___ sunder(a)intercom.com || | /|\ || . . \___/ . . . : .... __[R] || | + v + || . oOOo /o.O\ oOOo :. : .. |A| "And bugs to kill before I sleep"|| =========/---vvvv-------VVVV------------|I|----------------------------------/ / . : . ' : ' |D| This signature pannel is / / The Next Bug to kill(tm) --- now open. / /___________________________________________________________________/ GCS d++(---)(-) H s+++/++ !g !p !au a- w-(+) (!v | v) C+++++ Coherent++++ L+ 3 C+ V+ P? E- N++ K- W W--- M++ V-- po- Y+++ t:[tos+, tng--, ds9+] 5 !j !R G? tv+ b+++ D+ B--- e+(- | *) u--- h+++ f+(++) r++ n+(---) x**(++)

1 0

RE: a new way to do anonymity
by Johnathan Corgan 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >This is what I wrote: >> Imagine a server that allows you to open a >> low bandwidth (let's say around 100 cps, in order to reduce costs) >> link-encrypted telnet session with it, and provides you with a number >> of services, for example a link-encrypted talk session with another >> user. You'll need to maintain the link 24 hours a day to defend >> against statistical analysis, and of course you can chain a number of >> these servers together in a way similiar to chaining remailers. There are many, many analogies you can draw about a network of this type to an ATM (asynchronous transfer mode) network. By simplifying just slightly from what you describe to only include an encrypted, switched-pipe methodology, you now have a "cloud" type network with service entry points that are defined by a pair of byte streams (one in each direction). The switched path could be set up and torn down dynamically by the user by interacting with the "switch" at each point to select the next hop the encrypted byte stream will follow. Of course, just like in remailer chaining, the data that indicates which hop to follow is encrypted with the data in a form only the switch can decrypt. Alternatively, once a path is set up between switches, it can be assigned a virtual path identifier that has only local significance at each hop, with the switch performing a lookup to forward packets and substituting a new path number with significance at the next hop. The above description is pretty unclear, I think, but many of these concepts have been fleshed out to a significant amount of detail in ATM circles. Fixed length data packets (at the encrypted telnet level) also make it very easy to aggregate individual circuits into higher bandwidth pipes that connect server to server. With these continuously running with cover traffic, individual circuit establishment is much more immune from traffic analysis. Cover traffic is substituted with real traffic as necessary, up to the bandwidth of the pipe. To summarize, what has been described is a method to establish a "network within a network", using encrypted telnet, to provide a connection oriented, unreliable packet switched link layer protocol. Sounds remarkably similar to IP (except for the connection oriented portion of it.) What can you do with a network like this? By layering a TCP process on top of this "Pipe-Net" IP like service, any of the standard TCP based application protocols can function between two end point systems, such as SMTP, FTP, HTTP, etc. What is so neat about this is that it could probably be done in user space, and since the packet based protocol is defined as unreliable, switches could come and go, with some sort of switch-to-switch protocol that propagates route availability. Eric, you could probably chew on the trust implications of all this. Perry, I'm sure all the IPSP/SSL/SOCKS/whatever stuff you know so well could provide a lot of building blocks for this type of thing. Wei, your traffic analysis treatment of this sort of thing would go a long way toward uncovering weaknesses and determining operational requirements and limitations. Tim, what massive social effects would it have if this type of network service were to become widely deployed? :) At first glance, this Pipe-Net idea doesn't seem to take a lot of rocket science; it seems that most of the components or algorithms are are already in use, just in a very different way. I can think of a number of problems already, however. Spamming. Bandwidth limitations. Complexity of client and switch software. Standards. Flow control. In other works, all the stuff the ATM forum is already dealing with :) Come to think of it, has anyone thought of something like this before? == Johnathan Corgan "Violence is the last refuge of the incompetent." jcorgan(a)aeinet.com -Isaac Asimov WWW: ftp://ftp.netcom.com/pub/jc/jcorgan/home.html -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzg6ME1Diok8GKihAQEBygP/do7MnM2Ha/b3nYNeVb/7mpJqAwgke3D6 VlyhtVjxTM2tn42Voz47BtwTMiR+zkiwI5Ha3EQs/fpJGY7x69YGY+arGXAn/VsI Xq7/onQd/LOv8JAjrxrgH2gLTCmfs57+sLJXqghHmSrxgothsK8XRLY1HDoYDfai EgiNUmMTXEM= =ENYC -----END PGP SIGNATURE-----

2 1

Fwd: Seals and Sealing Waxes
by Alan Pugh 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Date: Tue Feb 07, 1995 10:15 PM EST To: cypherpunks(a)toad.com Subject: Fwd: Seals and Sealing Waxes Message-Id: TM> "All crypto is economics," and this is what made seals and sealing wax so TM> useful for so long. Saying "seals were duplicatable from the start" does TM> not mean this feat was easy, even if technically possible. TM> In fact, the fine details produced by a good seal are hard to exactly TM> emulate with a copy. Even on a two-dimensional surface. And with the advent TM> of three-dimensional surfaces, which sealing wax made possible, the fine TM> detail of a good seal was in fact very hard to forge. TM> Not impossible, but very costly with the technology of the day. Or even the TM> technology of _today_. After all, paper currency is largely based on seal TM> technology, with various embossing, printing, etc. methods used (on special TM> paper) that remain fairly hard to duplicate. true. thanks for the reminder of seals. i need to work this analogy into my current 'lecture' on the usefullness of encryption. _puzzle palace_ makes reference to british intellegence making use of people trained into the use of people trained to reproduce seals. this is something for us to look out for from the fine folx at nsa. if there is a way to spoof signatures (as mentioned in another thread recently), they will be perfecting and perhaps using these methods if they feel the need is great enough. i promote encryption using pgp with a lot of stress on the privacy and veracity of documents in business settings. how strong is the hash used by pgp? do you think it will eventually be hashed out in the courts in our favour?(pun semi-intended) i'd like digital signatures w/verifiable timestamps be recognised in a court of law. i don't know of any cases revolving around this issue. if anyone out there knows of one, i'd be interested in hearing of it so i can track it's progress. btw: though it is a pain sometimes to weed the noise off this list due to my (very) limited net access, it has proved to be an excellent resource. my thanks to the regulars. - --if i could code worth a damn i'd be a cypherpunk amp <0003701548(a)mcimail.com> February 7, 1995 22:17 -----BEGIN PGP SIGNATURE----- Version: 2.61 iQEVAwUBLzgN4CgP1O9KJoPBAQETZQf/WAY0I+fvEmevc7iwfVglqjIZ26zDnc33 p8Yjc+uQfagS0wavYLpN+OxMphpdUHHjycb98aYLDax8CUW3iDJ54tZKVnQT3pPx 9+v1gq38UbP8k7hvoGl5lIltmMJ/rMl2lZU87l2biYjmQq8n9S+mMoIOAatcmboG 6JQ4MEsNnZvsQVeaZm87qOGqfkeTbzwsBfz8LjLkgnv7TLUNn5wJgMgiC+apYC0V bJfAHWce3UGEPlaa4JHBbCRyfrC/hk1ggrYKthxHKE+Ceep1O2k7fRkX/tCC2BZC UaY8ZjogZKZJbfdDNmlG7fBN5EBWlj6Mj9Ti2SRYlx4q8lwSHad+gg== =HeNj -----END PGP SIGNATURE-----

1 0

Re: "encrypt tcp connections" hacks
by Chris Claborne 17 Dec '03

17 Dec '03

>> Thats because the providers never package things up cleanly. If they >> sent a client on a disk, a la AOL, and they set things up to >> autoconfigure, they'd never need to speak to the clients. > > You've obviously never attempted to get a Windows product working for >someone whose previous experience with a computer is limited to "Solitaire". > > I've done work with this ISP, and I can tell you it's nearly the most >frustrating experience I've had in my life -- Windows has bizzare >conflicts with software eating other software, ports getting set up >wrong, and just general nastiness. Even the slickest software needs >helpline time - for whatever reason. I hate jumping in when I may be completely off base but... NT and (possibly Winodws97) may solve some of this, mainly through better controll over devices and protected memory. I recently installed some NT services, HTTP server, and Time Service (to get time off a trusted host). The HTTP server was installed and working in 5 minutes. I'm a little more advanced than the typical "Solitare junky", but I was amazed at the ease of install and controll that some of this stuff gives you. I would probably spend atleast 30+ minutes trying to get them properly installed on my UNIX host. ... __o .. `\<, Chris.Claborne@SanDiegoCA.ATTGIS.COM...(_)/(_). CI$: 76340.2422 --------------------------------------------------------------------------- PGP Pub Key fingerprint = A8 FA 55 92 23 20 72 69 52 AB 64 CC C7 D9 4F CA Available on any Pub Key server. PGP encrypted mail welcome.

1 0

Re: Effects of S.314 (Communications Decency Act)
by jpp＠markv.com 17 Dec '03

17 Dec '03

For my congresional 'representatives'. S.314 is not a moral bill. Making the owner of a computer (or computer network) responsible for what its users store (or transmit) is like making the owners of a parking lot responsible for what is stored in the cars parked there. It just isn't moraly reasonable. S.314 is un-American. America has always been a place where speach is freeest. We have consistently held the expression of ideas to be one of the very most important rights. To hold the owner of a buliten board responsible for the illegal messages posted to it, is to force the buliten board owner to become a government censor in all but name (and wages). It effectively ends the bulliten board's use as a venue of free speach. S.314 is harmfull to America. The kind of 'chilling effect' this bill wil place on the computer (networking) industry would put american companies at a serious disadvantage. Could I really operate an airline reservtion system for a large airline if I could be held liable for illegal information transmitted using my equipment? No. Could I operate the masive software and hardware networks that the phone system requires? No. But, I bet the company I own in Mexico, or in Canada could. They aren't burdened with such (artificially created) liabilities. Or perhaps I could get a special waiver from my friends in Washington. Hmmm. How much will these sorts of 'work arounds' cost american bussiness? S.314 is not enforceable. There is no certain way to tell if a file of data is an illegal one. Stegnography and cryptography, along with the fact that what a bit means depends on which programs are used to interpret it, mean that even this message could be porno, terrorist threats, or arangements for drug trafficing. Imagin searching all the cars in your parking lot for drugs. Very expensive, and not very reliable. Tons of drugs travel past just such inspection sites each year. Now imagine how tough it would be if the drugs could be turned into perfectly normal steal in the body panels of the vehicles! That is what stegnography and cryptography do to data. Turn perfectly 'awfull' data into data perfectly indistinguishable from noise, and then hide the noise as indistinguishable-from-inocent 'errors' in other data. Concider the spelling in this message -- convert each word into a bit -- 1 if it is speled right, 0 if not. Or how about spacing, or, punctuation -- Hmmm. Now supose we add otras idiomas, aux eble muchos languages en cxiu mesagxon. Will computer (network) owners be responsible for the spelling, punctuation, language, word choice, and grammer of all the electronic mail sent, received, and stored? S.314 is bad for *your* career. If you vote to support it, I will vote against you in upcoming elections. I will work to impeach you. I will never employ you, I will not read your memoirs, I will not do business with you in any way what so ever. I urge you to think twice, and then vote no on S.314. j'

2 2

Re: Effects of S.314 (Communications Decency Act)
by Michael Sattler 17 Dec '03

17 Dec '03

>Can anyone confirm this S.314 thing? It sounds an awful lot like >the "modem tax" and other urban legends. S 314 IS 104th CONGRESS 1st Session To protect the public from the misuse of the telecommunications network and telecommunications devices and facilities. IN THE SENATE OF THE UNITED STATES February 1 (legislative day, January 30), 1995 Mr. Exon (for himself and Mr. Gorton) introduced the following bill; which was read twice and referred to the Committee on Commerce, Science, and Transportation A BILL To protect the public from the misuse of the telecommunications network and telecommunications devices and facilities. Be it enacted by the Senate and House of Representatives of the United States of America in Congress assembled, SECTION 1. SHORT TITLE. This Act may be cited as the `Communications Decency Act of 1995'. SEC. 2. OBSCENE OR HARASSING USE OF TELECOMMUNICATIONS FACILITIES UNDER THE COMMUNICATIONS ACT OF 1934. (a) Offenses: Section 223 of the Communications Act of 1934 (47 U.S.C. 223) is amended-- (1) in subsection (a)(1)-- (A) by striking out `telephone' in the matter above subparagraph (A) and inserting `telecommunications device'; (B) by striking out `makes any comment, request, suggestion, or proposal' in subparagraph (A) and inserting `makes, transmits, or otherwise makes available any comment, request, suggestion, proposal, image, or other communication'; (C) by striking out subparagraph (B) and inserting the following: `(B) makes a telephone call or utilizes a telecommunications device, whether or not conversation or communications ensues, without disclosing his identity and with intent to annoy, abuse, threaten, or harass any person at the called number or who receives the communication;' and (D) by striking out subparagraph (D) and inserting the following: `(D) makes repeated telephone calls or repeatedly initiates communication with a telecommunications device, during which conversation or communication ensues, solely to harass any person at the called number or who receives the communication; or'; (2) in subsection (a)(2), by striking `telephone facility' and inserting `telecommunications facility'; (3) in subsection (b)(1)-- (A) in subparagraph (A)-- (i) by striking `telephone' and inserting `telecommunications device'; and (ii) inserting `or initiated the communication' and `placed the call', and (B) in subparagraph (B), by striking `telephone facility' and inserting `telecommunications facility'; and (4) in subsection (b)(2)-- (A) in subparagraph (A)-- (i) by striking `by means of telephone, makes' and inserting `by means of telephone or telecommunications device, makes, knowingly transmits, or knowingly makes available'; and (ii) by inserting `or initiated the communication' after `placed the call'; and (B) in subparagraph (B), by striking `telephone facility' and inserting in lieu thereof `telecommunications facility'. (b) Penalties: Section 223 of such Act (47 U.S.C. 223) is amended-- (1) by striking out `$50,000' each place it appears and inserting `$100,000'; and (2) by striking `six months' each place it appears and inserting `2 years'. (c) Prohibition on Provision of Access: Subsection (c)(1) of such section (47 U.S.C. 223(c)) is amended by striking `telephone' and inserting `telecommunications device.' (d) Conforming Amendment: The section heading for such section is amended to read as follows: `obscene or harassing utilization of telecommunications devices and facilities in the district of columbia or in interstate or foreign communications'. SEC. 3. OBSCENE PROGRAMMING ON CABLE TELEVISION. Section 639 of the Communications Act of 1934 (47 U.S.C. 559) is amended by striking `$10,000' and inserting `$100,000'. SEC. 4. BROADCASTING OBSCENE LANGUAGE ON RADIO. Section 1464 of title 18, United States Code, is amended by striking out `$10,000' and inserting `$100,000'. SEC. 5. INTERCEPTION AND DISCLOSURE OF ELECTRONIC COMMUNICATIONS. Section 2511 of title 18, United States Code, is amended-- (1) in paragraph (1)-- (A) by striking `wire, oral, or electronic communication' each place it appears and inserting `wire, oral, electronic, or digital communication', and (B) in the matter designated as `(b)', by striking `oral communication' in the matter above clause (i) and inserting `communication'; and (2) in paragraph (2)(a), by striking `wire or electronic communication service' each place it appears (other than in the second sentence) and inserting `wire, electronic, or digital communication service'. SEC. 6. ADDITIONAL PROHIBITION ON BILLING FOR TOLL-FREE TELEPHONE CALLS. Section 228(c)(6) of the Communications Act of 1934 (47 U.S.C. 228(c)(6)) is amended-- (1) by striking `or' at the end of subparagraph (C); (2) by striking the period at the end of subparagraph (D) and inserting a semicolon and `or'; and (3) by adding at the end thereof the following: `(E) the calling party being assessed, by virtue of being asked to connect or otherwise transfer to a pay-per-call service, a charge for the call.'. SEC. 7. SCRAMBLING OF CABLE CHANNELS FOR NONSUBSCRIBERS. Part IV of title VI of the Communications Act of 1934 (47 U.S.C. 551 et seq.) is amended by adding at the end the following: `SEC. 640. SCRAMBLING OF CABLE CHANNELS FOR NONSUBSCRIBERS. `(a) Requirement: In providing video programming unsuitable for children to any subscriber through a cable system, a cable operator shall fully scramble or otherwise fully block the video and audio portion of each channel carrying such programming so that one not a subscriber does not receive it. `(b) Definition: As used in this section, the term `scramble' means to rearrange the content of the signal of the programming so that the programming cannot be received by persons unauthorized to receive the programming.'. SEC. 8. CABLE OPERATOR REFUSAL TO CARRY CERTAIN PROGRAMS. (a) Public, Educational, and Governmental Channels: Section 611(e) of the Communications Act of 1934 (47 U.S.C. 531(e)) is amended by inserting before the period the following: `, except a cable operator may refuse to transmit any public access program or portion of a public access program which contains obscenity, indecency, or nudity'. (b) Cable Channels for Commercial Use: Section 612(c)(2) of the Communications Act of 1934 (47 U.S.C. 532(c)(2)) is amended by striking `an operator' and inserting `a cable operator may refuse to transmit any leased access program or portion of a leased access program which contains obscenity, indecency, or nudity. -----------------------------------------------------------------------+ Michael Sattler <msattler(a)jungle.com> San Francisco, California | Digital Jungle Consulting Services http://www.jungle.com/msattler/ | | You couldn't get a clue during the clue mating season in | a field full of horny clues if you smeared your body with clue musk | and did the clue mating dance. - Edward Flaherty |

7 13

USPO & Digital Postage/E-Cash Project
by daleh＠ix.netcom.com 17 Dec '03

17 Dec '03

The US Post Office just killed a project that would have created a digital postage/e-cash system. This would have been a digital replacement for the Pitney-Bose style Postage Metering machines. To use a PM machine one has to take the entire machine physically to a Postal Station and purchase some fixed dollar amount of postage. The Postal clerk unseals and unlocks the machine, dials in the amount of postage purchased and then relocks and reseals the machine. This mechanical system would have been replaced by a serial-port dongle and a piece of software. The dongle would contain an EEPROM in a replacable button (made by Dallas Semiconductor) into which would be loaded data indicating the amount of postage that had been purchased and not yet used. The software package would be able to print the address, postage seal, routing codes, etc directly on the envelope via a laser printer and decrement the amount of available postage left in the dongle. In the original test, customers would have to take the dongle to a Postal Station to purchase additional postage, but the ultimate goal was to have been to have a commerical dial-up service available that one could dial into and purchase additional postage directly. A proof-of-concept prototype was developed in VB and a production prototype was then developed in VC++. Unfortunately the crypto wasn't very strong. The USPO contracted with Carnege-Mellon to try and break the system and they were able to within a couple of weeks. USPO then killed the project. Dale H.

2 1

RE: a new way to do anonymity
by Johnathan Corgan 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- > There are many, many analogies you can draw about a network of this > type to an ATM (asynchronous transfer mode) network. > >Thank you for the analogy. It's always good not to reinvent the wheel >when you don't need to. Exactly. Anywhere we can "stand on the shoulders" of others reduces wasted time and effort. >When you set up a mapping on a packet forwarder, this is exactly the >kind of initialization that would be required. It is also at this >point that keying would be negotiated, etc. Encrypt-Telnet to a switch process. Use text based command line sequence to check outbound paths, bandwidth available, negotiate quality of service, execute digital payment arrangements, etc. Conclude the transaction and get bumped to your next hop, where it happens all over again. Done right, it could probably be automated. It seems like a lot of effort, but if you remember that once an initial session is established with your Pipe-net Service Provider (tm), a given circuit can be relatively long-lived. >Now here's an important detail that needs to get done right. Is the >forwarding for fixed length packets, variable length packets, or >streams? Is this decision global or local? What are the latency and >aggregatation effects? How important are these for different classes >of data? (telnet v. voice, e.g.) One of the lessons learned in the years-long debate between the telco folks pushing synchronous time-division multiplexing point to point circuit switches and the data folks pushing variable length packet-switched broadcast medium networks is that fixed length packets can give you both TDM and statistical multiplexing. So, at the bottom most session layer, moving bits around in fixed chunks allows you to do things easier like bandwidth pre-allocation, aggregation, circuit based congestion control, and negotiated quality of service agreements to end points in the network. To learn from the efforts that have come from the thousands of people working on ATM, we could take a look at what has emerged as the "ATM Adaptation Layer." AAL specifies methods to encapsulate various data formats and quality of service requirements onto this fixed length, continuous stream of data packets. There is one for voice traffic, which requires fixed bandwitdth and very little relative latency, another for LAN type data packets, which have bursty bandwidth requirements and variable packet sizes. Your comment above is accurate in that the requirements involved in a Telnet session are vastly different from say, PGP Phone over TCP. The good part about all this is that a lot of the thinking, testing, prototyping, and standardization has already been done. The standards exist today for adapting variable bandwidth, variable packet length, variable latency data packets onto a continous stream of fixed length packets moving through a switched network. This reminds me of the old days of Packet Radio which used intelligent repeaters that you would access (via command line), determine your next repeater, then log into it, etc. I once established virtual circuit from Connecticut to Florida over 2 meter packet that took 25 or so hops, and had a transit delay of a half an hour. Primitive, kludgy, unreliable, and essentially useless, but totally cool. An opportunity presents itself here to establish this Pipe-net style service network, that would greatly expand the ability for network users to essentially bypass all the crap which appears to be coming down on us from our friendly representatives in Washington, who are trying so hard to "protect" us from ourselves. >I'd suggest just getting something running first, to get some >prototyping experience. Of course. What I've outline is a pretty ambitious goal. I'd be happy to see primitive switch implementations that do nothing more than forward TCP streams. Its a start and we would learn a lot along the way. Alas, I don't do Unix; my programming expertise is in (gasp) the Windows environment. So it looks like I could start looking at the requirements implementation of a Winsock interface that made all this stuff transparent to an end user. Important consideration. I suppose the IRC folks could add their experience to the mix. In a very real way, IRC _is_ a packet switched unicast/multicast stream service on top of the 'net. Do we have any IRC op types onboard here? == Johnathan Corgan "Violence is the last refuge of the incompetent." jcorgan(a)aeinet.com -Isaac Asimov WWW: ftp://ftp.netcom.com/pub/jc/jcorgan/home.html -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzhqMU1Diok8GKihAQGRxAP/dWIvYMuqX5c1y/Mlmc73WQlQ/1263vqb YzGMvgTFEP0p/jZZstb8tMOyHY2KKp7WWLXV94jd8/KhdQgYFtGHphVm93WP3Bu8 hRK8kV5UEtANQ/JycVHG6HU3MMxLhE+Yh+M/CFLBwBZZYYglnV3DLqBHv4kq+5Tg /7ZiTjnHRDk= =ee6L -----END PGP SIGNATURE-----

2 1

Full text of S. 314
by Samuel Kaplin 17 Dec '03

17 Dec '03

2 2