December 2003 - cypherpunks-legacy

Cypherpunks Fax Service
by sameer 17 Dec '03

17 Dec '03

I see a potential business opportunity for enterprising cypherpunks: People have been posting things saying "we should have press releases". People have been posting useful information regarding fax numbers of reporters around the country and such. In this I see a potential low-maintenance business opportunity for some enterprising cypherpunk with a high-grade fax machine. There is no way anyone can make a 'Cypherpunk press release' because there is no "Cypherpunk Organization". There -are- however, cypherpunks organizations. Community ConneXion is one, for example, and others such as COMSEC partners may be considered cypherpunk organizations. Some enterprising cypherpunk may wish to sell the services of their fax machine so that cypherpunk organizations don't need to invest the time towards building up a good database of press fax numbers. For some fee a cypherpunk organization would send only to the service a press release, and the service would make sure it reaches all the people in the press who find cypherpunk topics interesting. Hell, if no one sets this up before I get my own mass-faxer setup, I might just do it myself. -- sameer Voice: 510-601-9777 Community ConneXion FAX: 510-601-9734 An Internet Privacy Provider Dialin: 510-658-6376 http://www.c2.org (or login as "guest") sameer(a)c2.org

1 0

COMMUNITY CONNEXION TO OFFER REWARD FOR HACKING MICROSOFT
by sameer 17 Dec '03

17 Dec '03

For Immediate Release Contact: Sameer Parekh 510-601-9777 (Pager: 510-321-1014) COMMUNITY CONNEXION TO OFFER REWARD FOR HACKING MICROSOFT Sept. 29 1995 - Community ConneXion, an Internet Privacy Provider in Berkeley, CA, announced today that it will be providing awards to people who find and publicize security holes in Microsoft products. "Microsoft claims to be promoting secure transactions on the net," said Sameer Parekh, founder of Community ConneXion, "We will prove them wrong." Microsoft has been quoted making disparaging comments about their competitor Netscape's product, Netscape Navigator. Community ConneXion has also been offering a reward to expose holes in Netscape's products. "We target widely used programs," said Parekh. Parekh expects that many bugs and flaws in Microsoft's security software will be found. People want to use the Internet to do business. They want to be able to buy things, manage their finances, and communicate privately from the comfort of their home computer. Without a secure infrastructure none of this is possible. Information about the Hack Microsoft promotion is available from http://www.c2.org/hackmsoft/. People who have found security holes and have written exploits are directed to send mail to hackmsoft(a)c2.org. Community ConneXion is the premier provider of privacy on the Internet. They provide anonymous email accounts and support the anonymous remailer infrastructure. Information is available from http://www.c2.org/ or info(a)c2.org. Microsoft is a trademark of Microsoft Corp. Netscape and Netscape Navigator are trademarks of Netscape Communications Corp. This promotion is not affiliated with Microsoft or Netscape.

1 0

Cryptanalysis of RC4 - Preliminary Results (Repeat)
by Andrew Roos 17 Dec '03

17 Dec '03

(This is a repeat because I posted the original 36 hours ago and it still hasn't bounced back to me.) -----BEGIN PGP SIGNED MESSAGE----- Hi c'punks & sci.cryptites About a week ago I posted a message about weak keys in RC4. This is an update on the results of my continued 4am sessions with RC4 and shows that certain weak keys lead to an almost-feasible known plaintext attack on the cipher (well, about as feasible as the differential attack on DES, shall we say). The attack is based on two particularly interesting three-byte key prefixes which have a high probability of producing PRNG sequences which start with a known two-byte sequence. The prefixes are: 1. Keys starting with "00 00 FD" which have a 14% probability of generating sequences which start "00 00". 2. Keys starting with "03 FD FC" which have a 5% probability of generating sequences which start "FF 03". Note that the expected frequency of any two-byte output sequence is 1 in 65536 or about 0.0015%, so these key prefixes are highly unusual. I won't go into the reasons why in this post, since it follows the same reasoning as my last post, but these prefixes are special in that they have a high probability of initializing the RC4 state table in such a way that the first two generated bytes depend only on the first three entries in the state table. This observation is the basis for a simple known-plaintext attack which reduces the effective key space which you need to search to have a 50% probability of discovering a key by about 11.2 bits. The down side is that you need "quite a few" known plaintexts to make the attack feasible. It works as follows: 1. Collect a large number of known plaintexts (and hence known generator sequences). 2. Discard generator sequences which do not start with "00 00" or "FF 03". 3. For generator streams starting "00 00", search all keys which begin with "00 00 FD". 4. For generator streams staring "FF 03", search all keys which begin with "03 FD FC". 5. Keep going until you find a key :-) Clearly this attack will only discover a small fraction of the keys. However since most generator sequences are discarded without being searched, and for those which are searched the search is 2^24 smaller than would be required to search the entire keyspace, the number of trials required to determine a key is significantly lower than for brute force alone. Enough of an intro, here are the relevant results. Forgive my simplistic approach to maths, I'm a philosopher-come-software developer, not a mathematician. I've run the relevant simulations with 40-bit, 64-bit, 80-bit and 128-bit key lengths, and with two different PRNGs. For the sake of consistency with my earlier paper I'll use the figures gathered for 80-bit keys (this seems to be RSA's preferred key length for RC4), but there are no significant differences for other key lengths. The PRNG used for these tests was L'Ecuyer's 32-bit combined linear congruential generator as described in "Applied Cryptography" p. 349. (a) Out of one million trials, keys starting with "00 00 FD" generated sequences starting "00 00" 138217 times, and keys starting with "03 FD FC" generated output sequences starting "FF 03" 50490 times. (b) Out of ten million trials, arbitrary pseudo-random keys generated sequences starting with "00 00" 446 times, and sequences starting with "FF 03" 146 times. (Note the abnormally high incidence of "00 00"; the expected mean is 152.8). Suppose we have the output stream generated by a randomly chosen key. The chance that it will start with either "00 00" or "FF 03", and that we will therefore search it, is: (446 + 146) / 1e7 = 5.92e-5 The chance that it starts with "00 00" and was generated by a key starting with "00 00 FD", or that it starts with "FF 03" and was generated by a key starting "03 FD FC" - i.e. the chance that we will search it and be rewarded for our efforts - is: (138217 + 50490)/(1e6 * 2^24) = 1.12e-8 The total number of plaintexts required for a 50% chance that we will discover one of the keys is: log(0.5)/log(1 - 1.12e-8) = 61 900 000 Well I did say "quite a few" plaintexts would be necessary :-) And the number of plaintexts which you expect to search in order to find the "right" one is: 61 900 000 * 5.92e-5 = 3665 Since the total key length is 80 bits, and we are "guessing" 24 of these, each search requires 2^56 trials. Hence the total number of trials for a 50% chance of discovering a key is: 3665 * 2^56 = 2.64e20 = 2 ^ 67.8 Since brute search alone would require 2^79 trials for a 50% chance of determining the key, this reduces the number of trials by 2^11.2. The results are essentially identical for all the key lengths I have tried, and in each case reduce effective key length by about 11.2 bits. So, for example, a 64-bit key would normally require 2^63 trials for 50% chance of solution; this attack reduces the number of trials to 2^51.8 at the cost of requiring 62 million known plaintexts. I'm still running simulations to check my maths, and although initial results are encouraging, I don't have enough data for it to be statistically relevant yet (generating all these sets of 62 million known streams takes time...) So consider this preliminary (again), and I'll post the results of my simulations when I have enough data. Andrew ________________________________________________________________ Andrew Roos <andrewr(a)vironix.co.za> // C++ programmers have class (but not much inheritance) PGP Fingerprint: F6 D4 04 6E 4E 16 80 59 3A F2 27 94 8B 9F 40 26 Full key at ftp://ftp.vironix.co.za/PGP-keys/AndrewRoos -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMGrlfmatuqa4OR+lAQF1eQP+IBBmSztAYUpq1q/BjzvYDCbb+Ns0Gi1S u9wTaZOCl32fdp7NSUEQBX39nVJkQZginug56BZXzijRvOx6fl4+z7dmW9jwtE5E YNCOhx+/fHX4psszMyEUTrnza7MYDc4HXlgv743LOD/xvEyU0D5OGgB5fg+lyhAK 6xQ/Zy8JpE8= =BdMn -----END PGP SIGNATURE-----

1 0

screensavers and idle computation.
by nefud＠io.com 17 Dec '03

17 Dec '03

To the folx working on the RC4 et. al. distributed keysearch Net: Add a module that will be run from things like "xscreensaver". As Tim May pointed out, current use of crypto is a "tiny fraction of the total computons consumed running screen savers". So let use them, eh? Besides, it'd be kind of neat seeing the "galaxies in hyperspace" displayed in a fractal like screensaver image. -- Allan Bailey | "Freedom is not free." _O_ Senlima Diverseco je Senlimaj Kombinajxoj.| nefud(a)io.com | KC5KSF | GCS w+ v-/+ C++++ U@$ P+++ L++ E++ N++ po--- Y++ b++ ============================================================ = When Privacy Is Outlawed, Only Outlaws Will Have Privacy = = I Support the Phil Zimmermann Legal Defense Fund! = = email: zldf(a)clark.net http://www.netresponse.com/zldf = ============================================================

1 0

FinCen Blurb in local paper
by Kevin L Prigge 17 Dec '03

17 Dec '03

Found this in the St Paul Pioneer Press yesterday, no wire service attribution. Cyber banking risks cited New York Smart Cards, on-line banking and other high-tech consumer payment services could be exploited by money launderers and other crooks, a Treasury Department official warned Wednesday. Stanley Morris, director of the Financial Crimes Enforcement Network, said that government and regulatory agencies believe the new systems, known as cyber banking, will profoundly alter financial services in the future. "The government has got to get its act together" and quickly decide on whether on-line banking systems and smart cards require new regulations," Morris said. Morris spoke to reporters after a day-long closed-door meeting of bankers, regulators, law enforcement officials and technology executives sponsored by FinCen, the governments anti-money laundering agency. --- end article --- -- Kevin Prigge | Holes in whats left of my reason, CIS Consultant | holes in the knees of my blues, Computer & Information Services | odds against me been increasin' email: klp(a)cis.umn.edu | but I'll pull through...

1 0

Assessing Netscape Commerce Server Risk
by millar＠pobox.upenn.edu 17 Dec '03

17 Dec '03

Would anyone care to critique this assessment? >Q: What is the risk of implementing the Commerce Server without waiting for >the Oct. 9 patch (which fixes the randomness problem with the server's >public/private key pair)? >A: The exposure is essentially this: if someone were to make a concerted >attack on your public/private key pair, they might be able to discover your >private key. Combined with net eavesdropping this would allow interception >and decrypting of SSL-encrypted traffic to your Commerce Server, and >combined with IP address and DNS domain impersonation would allow someone >to masquerade as your server. > >I would characterize this risk as low to moderate, with the higher risk >only applying if your Commerce Server is handling larger financial >transactions or extremely sensitive information. > >The time required for an attack on your key pair depends on how close the >attacker can come to guessing exactly when your key pair was generated, and >what the pid/ppid were for the key generation program at the time the key >was generated, as well as how fast the attacker can generate candidate key >pairs. Since the time and pid/ppid are probably guessable only within >broad limits (e.g., within a few days for the time), and generating key >pairs takes on the order of a second or so, the estimated attack times are >much longer than the attack times for SSL messages. I believe Netscape has >published estimates like 60 days or so to crack a key pair; even if those >estimates are too high by factors of two or three the times are still >comparable to the time until the patch is available. > >So if you're really concerned you can certainly eliminate the risk by >shutting down SSL-secure services until you get the patch; however I'd >weigh that against the downside of not having those services accessible. > >P.S. If you do continue running your Commerce Server with SSL, one simple >thing that might help thwart attacks is to do a "touch" on your server key >file and server certificate file (or copy them somewhere and then copy them >back) to update the date/time modified on the files. This eliminates one >possible clue as to when the key pair was generated. _________________________________________________ Dave Millar University Information Security Officer 3401 Walnut St., Suite 265C Philadelphia, PA 19104-6228 University of Pennsylvania For security matters: security(a)isc.upenn.edu (read by Data Admin. staff) Other matters: millar(a)pobox.upenn.edu voice: (215) 898-2172 fax: (215) 898-1729 For PGP 2.6 Public key: http://www.upenn.edu/security-privacy/ PGP Fingerprint: 28 FB 09 DC C7 96 C2 53 1A B8 BE 3B 73 32 46 4C

1 0

Netscape hole without .Xauthority (fwd)
by Jyri Kaljundi 17 Dec '03

17 Dec '03

Haven't seen this on the cypherpunks yet, sorry if this has been here already. Juri <o Jüri Kaljundi e-mail: jk(a)digit.ee o< >o tel: +372 6308994 o> <o DigiTurg http://www.digit.ee/ o< ---------- Forwarded message ---------- There's a huge hole in the Netscape remote control mechanism for the X-Windows based clients. Potential impact : anybody can become any user that uses Netscape on any system without sufficient X security. Let's suppose that you have an account on a target machine, where somebody is using Netscape, and either the xhost checking is disabled, or you can set the xhost yourself (e.g. if you have an account and the target user has no .Xauthority, as is frequent in university computer rooms). Then you can gain access to the target user's account using the following steps : - make a text file containing only "+ +" accessible (as file, as URL, or whatever you like) to the target Netscape client. This is quite easy, either if you have a personal WWW page (http://... URL) or an account on the target machine (file://... URL), or even by uploading it to an anon FTP - set your DISPLAY environment variable to the target display - run the following set of commands : netscape -noraise -remote "openURL(<put-your-URL-here>)" netscape -noraise -remote "saveAs(.rhosts)" netscape -noraise -remote back In the second command, the path should be specified whenever possible (~ is not accepted). If the target user does not already have a .rhosts and is not looking at that precise moment, then the chances are it worked ! Solution to the problem : every user concerned should either create a Xauthority file, or stop using Netscape. MXK PS: WHY do they bother with PGP and RSA security when they keep such holes ???? +------------------------------------+---------------------------------+ | Denis AUROUX (MXK) | Ecole Normale Superieure | | 255 rue Saint-Jacques | 45 rue d'Ulm | | 75005 PARIS FRANCE | 75005 PARIS | | email: auroux(a)clipper.ens.fr | FRANCE | +------------------------------------+---------------------------------+ | This .sig is SHAREWARE. If you use it often, please send me $50. | | After registering you will receive a fully functional .sig and all | | updates for free. | +----------------------------------------------------------------------+

7 6

Re: netscape NSRANDFILE compatible with /dev/random ?
by Carl Ellison 17 Dec '03

17 Dec '03

>From: "Jeff Weinstein" <jsw(a)netscape.com> >Date: Wed, 27 Sep 1995 00:40:41 -0700 >> What happens if NSRANDFILE is set to /dev/random ? >> will netscape try to read an infinite number of random bytes ? > > In the current patch it will read up to 1 megabyte before stopping. >In 2.0 I will add a way to specify a size. As a temporary hack you >could use 'dd' to get the number of bytes you want into a file, then >remove the file once netscape had started up. or you can define a named pipe file (on UNIX at least) which runs /dev/random through dd.

1 0

Re: Simple Hardware RNG Idea
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 4:14 PM 9/28/95, cjs wrote: >Hello all. > >Someone mentioned this on IRC last night, and it sounded like a really >cool idea, so I thought I'd mention it. > >The idea is to generate random numbers using a geiger counter tube and >a small portion of radioactive substance (like perhaps the stuff they >use in smoke detectors?) Would that be random enough? > >I thought it was a neat idea anyway. It's a well-known idea. My FAQ has a section on this, and the Cypherpunks archives have many mentions of this. For the newcomers, here are some of the issues, very briefly presented: 1. Incorporating a "Geiger counter tube" is nontrivial. A solid-state detector does the same thing, and is a better approach. 2. Incorporating Am-241 or other alpha emitters in microcurie levels would require licensing, regulatory oversight, etc., etc. Don't count on it. 3. Data rates are fairly low. Anything that "clicks" at high rates (> 1K counts per second) would be too radioactive to ship. 4. Zener diodes and other random noise sources are cheaper to build, more consistent in output, and easier to integrate into actual products. --Tim May ---------:---------:---------:---------:---------:---------:---------:---- 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."

3 2

Traveling abroad with laptops
by rajaram＠morgan.com 17 Dec '03

17 Dec '03

What would happen if I flew out of the US with a portable computer that has crypto software (like PGP) installed ? Assuming that I had no intention of distributing the software abroad, would I be violating some US export law ? Matt Blaze (?) had written about his humorous experience in trying to do the right thing. It seems that the US Govt. does not seriously enforce its own export policies. But they may start doing so any time. I am sure that today many people regularly fly into Europe with crypto software, without intending to break any laws. At one point, I had heard that some sort of exception was planned for export of crypto for personal use. Does anyone know if this is real or just a rumor ? regards -raj

1 0

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

17 Dec '03

At 3:22 PM 9/27/95, Bill Stewart wrote: >2) RSA patent - can this be built with RSAREF? Or RSAREF with permission >for a couple extra activities? Or built out of RIPEM or RIPEM-SIG? >The latter has the benefit of already being exportable. It certainly can be built from RSAREF, as I use my Apple DigiSign X.509 key (ultimately created with TIPEM in the Mac system software) with RIPEM/Mac (which uses RSAREF.) Some additional info: my company, Consensus Development, has commercial rights to license developers RSAREF also has a good relationship with VeriSign. We helping them writea variety of tools to make issuing X.509 certs easier. >5) S/MIME - real S/MIME compliance requires support for RC2 as well as >publicly available algorithms, though this is really just an X.509 handler. I've been working on getting RC2/RC4 in object-only exportable size key form from RSA for RSAREF customers, and Jim Bidzos has agreed in principle. We have to work out details, however. >6) It's a lot of work - well, yeah, it is. And I'm lazy. Is there enough >related code in SSLeay to steal to help implement it? I spoke with Eric yesterday and I think he was working on some ASN.1 related classes for a future version of SSLeay. ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. ..<ChristopherA(a)consensus.com> 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. ..<http://www.consensus.com/> o510/559-1500 f510/559-1505..

1 0

COE Document
by Dave Banisar 17 Dec '03

17 Dec '03

------------------------------------------------------------------------ A HTML Version of this document is available at the Privacy International Archives at www.privacy.org/pi/intl_orgs/coe/info_tech_1995.html Recommendation No. R (95) 13 of the Committee of Ministers to Member States Concerning Problems of Criminal Procedure Law Connected with Information Technology (Adopted by the Committee of Ministers on 11 September 1995 at the 543 meeting of the Ministers' Deputies) The Committee of Ministers, under the terms of Article 15.b of the Statute of the Council of Europe. Considering that the aim of the Council of Europe is to achieve a greater unity between its members; Having regard to the unprecedented development of information technology and its application in all sectors of modern society; Realizing that the development of electronic information systems will speed up the transformation of traditional society into an information society by creating a new space for all types of communications and relations; Aware of the impact of information technology on the manner in which society is organised and on how individuals communications and interrelate; Conscious that an increasing part of economic and social relations will take place through or by use of electronic information systems; Concerned at the risk that electronic information systems and electronic information may also be used for committing criminal offenses; Considering that evidence of criminal offenses may be stored and transferred by these systems; Noting that criminal procedure laws of members states often do not yet provide for appropriate powers to search and collect evidence in these systems in the course of criminal investigations; Recalling that the lack of appropriate special powers may impair investigating authorities in the proper fufilment of their tasks in the face of the ongoing development of information technology; Recognising the need to adopt the legitimate tools which investigating authorities are afforded under criminal procedure laws the the specific nature of investigations in electronic information systems; Concerned by the potential risk that member states may not be able to render mutual legal assistance in an appropriate way when requested to collect electronic evidence within their territory from electronic information systems; Convinced of the necessity of strengthening internation co-operation and achieving a greater compatibility of criminal procedural laws in this field; Recalling Recommendation No. R (81) 20 of the Committee of Ministers on the harmonisation of laws relating to the requirement of written proof and to the admissibility of reproductions of documents and recordings on computers, Recommendation No. R. (85) 10 on letters rogatory for the interception of telecommunications, Recommendations No. R (87) 15 regulating the use of personal data in the police state and Recommendations No. R (89) 9 on computer-relating crime, Recommends the governments of member states: i. when reviewing their internal legislation and practice, to be guided by the principles appended to this recommendation; and ii. to ensure publicity for these principles among those investigating authorities and other professional bodies, in particular in the field of information technology, which may have an interest in their application. Appendix to Recommendation No R. (95) 13 concerning problems of criminal procedure law connected with information technology I. Search and seizure ----------------------------- 1. The legal distinction between searching computers systems and siezing data stored therein and intercepting data in the course of transmission should be clearly delineated and applied. 2. Criminal procedure laws should permit investigating authorities to search computer systems and seize data under similar conditions as under traditional powers of search and seizure. The person in charge of the system should be informed that the system has been searched and of the kind of data that has been siezed. The legal remedies that are provided for in general against search and seizure should be equally applicable in case of search in computer systems and in case of seizure of data therein. 3. During execution of a search, investigating authorities should have the power, subject to appropriate safeguards, to extend the search of other computer systems within their jurisdiction which are connected by menas of a network and seize the data therein, provided immediate action is required. 4. Where automatically processed data is functionally equivalent to a traditional document, provisions in the criminal procedure law relating to search and seizure of documents should apply equally to it. II. Technical Surveillance ------------------------------------- 5. in view of the convergance of information technology and telecommunications, law pertaining to technical surveillance for the purpose of criminal investigations, such as interception of telecommunications, should be reviewed and amended, where necessary, to ensure their applicability. 6. The law should permit investigating authorities to avail themselves of all necessary technical measures that enable the collection of traffic data in the investigation of crimes. 7. When collected in the course of a criminal investigation and in particular when obtained by means of intercepting telecommunications, data which is the object of legal protection and processed by a compuer system should be secured in an appropriate manner. 8. Criminal procedure laws should be reviewed with a view to making possible the interception of telecommunications and the collection of traffic data in the investigation of serious offenses against the confidentiality, integrity and availability of telecommunications or computer systems. III. Obligations to co-operate with the investigating authorities -------------------------------------------------------------------- 9. Subject to legal privileges or protection, most legal systems permit investigating authorities to order persons to hand over objects under their control that are required to serve as evidence. In a parallel fashion, provisions should be made for the power to order persons to submit any specified data under their control in a computer system in the form required by the investigating authority. 10. Subject to legal privileges or protection, investigating authorities should have the power to order persons who have data in a computer system under their control to provide all necessary information to enable access to a computer system and the data theirin. Criminal procedure law should ensure that a similar order can be given to other persons who have knowledge about the functioning of the computer system or measures applied to secure the data therein. 11. Specific obligations should be imposed on operators of public and private networks that offer telecommunications services to the public to avail themselves of all necessary technical measures that enable the interception of telecommunications by the investigating authorities. 12. Specific obligations should be imposed on service providers who offer telecommunications services to the public, either through public or private networks, to provide information to identify the user, when so ordered by the compentant investigating authority. IV. Electronic Evidence ------------------------ 13. The common need to collect, preserve, and present electronic evidence in ways that best ensure and reflect their integrity and irrefutable authenticity, both for the purposes of domestic prosecution and international co-operation, should be recognized. Therefore, procedures and technical methods for handling electronic evidence should be further developed, and particularly in such a way as to ensure their compatability between states. Criminal procedural law provisions on evidence relating to tradition documents should similarly apply to data stored in a computer system. V. Use of Encryption --------------------- 14. Measures should be considered to minimise the negative effects of the use of cryptography on the investigation of criminal offenses, without affecting its legitimate use more than is strictly necessary. VI. Research, statistics and training ------------------------------------- 15. The risks involved in the development and application of information technology with regard to the commission of criminal offenses should be assured continuously. In order to enable the competent authorities to keep abrest of new phenomena in the field of computer related offenses and to develop appropriate counter-measures, the collection and analysis of data on these offenses, including modus operandi and technical apsects, should be furthered. 16. The establishment of specialised units for the investigation of offenses, the combating of which requires special expertise in information technology, should be considered. Training programmes enabling criminal justice personnel to avail themselves of expertise in this field should be furthered. VII. International Cooperation ------------------------------ 17. The power to extend a search to other computer systems should also be applicable when the system is located in a foreign jurisdiction, provided that immediate action is required. In order to avoid possible violations of state sovereignity or international law, an unambigious legal basis for such extended search and seizure should be established. Therefore, there is an urgent need for negotiating international agreements as to how, when and to what extent such search and seizure should be permitted. 18. Expedited and adequate procedures as well as a system of liason should be available according to which the investigating authorities may request the foreign authorities to promptly collect evidence. For that purpose the requested authorities should be authorized to search a computer system and seize data with a view to its subsequent transfer. The requested authorities should also be authorized to provide trafficking data rtelated to a specific telecommunication, intercept a specific telecommunication or identify its source. For that purpose, the existing mutual legal assistance instruments need to be supplemented. _________________________________________________________________________ Subject: COE Document _________________________________________________________________________ David Banisar (Banisar(a)epic.org) * 202-544-9240 (tel) Electronic Privacy Information Center * 202-547-5482 (fax) 666 Pennsylvania Ave, SE, Suite 301 * HTTP://www.epic.org Washington, DC 20003 * ftp/gopher/wais cpsr.org

1 0

Re: Netscape "random" number seed generator code available
by Martin Diehl 17 Dec '03

17 Dec '03

on 9/24/95 karlton(a)neon.netscape.com (Phil Karlton) at Internet-USA wrote: The random number seed generation code is now available for review: ftp://ftp1.netscape.com/pub/review/RNGsrc.tar.Z My platform is DOS 6.22, Windows 3.11 Can someone suggest a program (and where to get it) that will run on my platform and extract the tar.z files into DOS ASCII files so that I can review the key generator code? Thanks for your help. Martin G. Diehl

2 1

my favorite random-numbers-in-software package (unix)
by Matt Blaze 17 Dec '03

17 Dec '03

About a week ago I posted my (Don Mitchell's really) truerand() routine for Unix. truerand() needs some post-processing before use; it cannot be used directly. Here's a more complete version; the main interface is randbyte(), which returns (in about a third of a second) one really random byte (based on 64 truerand() bits) that can be used directly. As an added bonus, the library also throws in a shs-2 function and the basic truerand() code. The basic idea is that you exploit randomness in the drift between the processor clock and the rate at which interval timer interrupts occur. Such drift occurs even on idle processors. randbyte() assumes that there's at least about .4 bits of "entropy" per interrupt, which is (probably) a safe assumption on modern processors. Randomness introduced by the OS (scheduler, etc.) can add to the overall entropy, but shouldn't be relied upon by itself. An advantage to this approach (using clock skew) is that the randomness doesn't depend on external events like user input, network traffic or processor load. That makes it especially attractive for generating keys on unattended servers, e.g., for generating Diffie-Hellman exponents. Note, however, that very (very) slow and heavily-loaded processors may not provide enough cycles to the truerand process between interrupts for these assumptions to hold. Also, all bets are off on processors that use a single clock source for both interval timing and CPU clocking. This code is very BSD/SunOS-centric and is completely untested elsewhere. Read the comments for scary warnings about testing on your own platform before using it for anything serious like generating keys. -matt =======================cut here============== #!/bin/sh # This is a shell archive (produced by GNU sharutils 4.1). # To extract the files from this archive, save it to some FILE, remove # everything before the `!/bin/sh' line above, then type `sh FILE'. # # Existing files will *not* be overwritten unless `-c' is specified. # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 1270 -rw-r--r-- makefile # 1246 -rw-r--r-- randbyte.c # 2886 -rw-r--r-- truerand.c # 7142 -rw-r--r-- shs.c # 149 -rw-r--r-- randtest.c # touch -am 1231235999 $$.touch >/dev/null 2>&1 if test ! -f 1231235999 && test -f $$.touch; then shar_touch=touch else shar_touch=: echo echo 'WARNING: not restoring timestamps. Consider getting and' echo "installing GNU \`touch', distributed in GNU File Utilities..." echo fi rm -f 1231235999 $$.touch # # ============= makefile ============== if test -f 'makefile' && test X"$1" != X"-c"; then echo 'x - skipping makefile (file already exists)' else echo 'x - extracting makefile (text)' sed 's/^X//' << 'SHAR_EOF' > 'makefile' && # makefile for librand # tested on Sparc-20 (SunOS 4.x) and P100 (BSDI) only. # You're on your own elsewhere. Read the comments for scary warnings. # # Usage: int randbyte(); # #* The authors of this software are Don Mitchell, Matt Blaze & Jack Lacy. #* Copyright (c) 1995 by AT&T. #* Permission to use, copy, and modify this software without fee #* is hereby granted, provided that this entire notice is included in #* all copies of any software which is or includes a copy or #* modification of this software and in all copies of the supporting #* documentation for such software. #* #* This software may be subject to United States export controls. #* #* THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED #* WARRANTY. IN PARTICULAR, NEITHER THE AUTHORS NOR AT&T MAKE ANY #* REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY X SRCS=randbyte.c truerand.c shs.c OBJS=randbyte.o truerand.o shs.o CC=gcc CFLAGS= # No -O in CFLAGS! On some compilers, this optimizes out the counter... X librand.a: $(OBJS) X ar rcv librand.a $(OBJS) X ranlib librand.a X randtest: randtest.c $(SRCS) X cc -DDEBUGRND randtest.c $(SRCS) -o randtest X librand.shar: makefile $(SRCS) randtest.c X shar makefile $(SRCS) randtest.c > librand.shar SHAR_EOF $shar_touch -am 0930150995 'makefile' && chmod 0644 'makefile' || echo 'restore of makefile failed' shar_count="`wc -c < 'makefile'`" test 1270 -eq "$shar_count" || echo "makefile: original size 1270, current size $shar_count" fi # ============= randbyte.c ============== if test -f 'randbyte.c' && test X"$1" != X"-c"; then echo 'x - skipping randbyte.c (file already exists)' else echo 'x - extracting randbyte.c (text)' sed 's/^X//' << 'SHAR_EOF' > 'randbyte.c' && /* X * Random byte interface to truerand() X * Matt Blaze 5/95 X * eight really random bits X * usage: X * unsigned char r; int randbyte(); X * r=randbyte(); X * randbyte() takes about .3 seconds on most machines. X */ /* X * The author of this software is Matt Blaze. X * Copyright (c) 1995 by AT&T. X * Permission to use, copy, and modify this software without fee X * is hereby granted, provided that this entire notice is included in X * all copies of any software which is or includes a copy or X * modification of this software and in all copies of the supporting X * documentation for such software. X * X * This software may be subject to United States export controls. X * X * THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED X * WARRANTY. IN PARTICULAR, NEITHER THE AUTHORS NOR AT&T MAKE ANY X * REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY X * OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE. X */ X int randbyte() { X unsigned long truerand(); X unsigned char *shs(); X unsigned long r[2]; X unsigned char *hash; X X r[0]=truerand(); r[1]=truerand(); X hash = shs(r,sizeof(r)); #ifdef DEBUGRND X printf("%011o %011o %02x\n",r[0],r[1],*hash & 0xff); #endif X return ((int) (*hash)) & 0xff; } SHAR_EOF $shar_touch -am 0930145795 'randbyte.c' && chmod 0644 'randbyte.c' || echo 'restore of randbyte.c failed' shar_count="`wc -c < 'randbyte.c'`" test 1246 -eq "$shar_count" || echo "randbyte.c: original size 1246, current size $shar_count" fi # ============= truerand.c ============== if test -f 'truerand.c' && test X"$1" != X"-c"; then echo 'x - skipping truerand.c (file already exists)' else echo 'x - extracting truerand.c (text)' sed 's/^X//' << 'SHAR_EOF' > 'truerand.c' && /* X * Physically random numbers (very nearly uniform) X * D. P. Mitchell X * Modified by Matt Blaze 2/95 X */ /* X * The authors of this software are Don Mitchell and Matt Blaze. X * Copyright (c) 1995 by AT&T. X * Permission to use, copy, and modify this software without fee X * is hereby granted, provided that this entire notice is included in X * all copies of any software which is or includes a copy or X * modification of this software and in all copies of the supporting X * documentation for such software. X * X * This software may be subject to United States export controls. X * X * THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED X * WARRANTY. IN PARTICULAR, NEITHER THE AUTHORS NOR AT&T MAKE ANY X * REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY X * OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE. X */ X /* X * WARNING: depending on the particular platform, truerand() output may X * be biased or correlated. In general, you can expect about 16 bits of X * "pseudo-entropy" out of each 32 bit word returned by truerand(), X * but it may not be uniformly diffused. You should therefore run X * the output through some post-whitening function (like MD5 or DES or X * whatever) before using it to generate key material. (RSAREF's X * random package does this for you when you feed truerand() bits to the X * seed input function.) X * X * Test these assumptions on your own platform before fielding a system X * based on this software or these techniques. X * X * This software seems to work well (at 16 bits per truerand() call) on X * a Sun Sparc-20 under SunOS 4.1.3 and on a P100 under BSDI 2.0. You're X * on your own elsewhere. X */ X #include <signal.h> #include <setjmp.h> #include <sys/time.h> #include <math.h> #include <stdio.h> X static jmp_buf env; static unsigned count; static unsigned ocount; static unsigned buffer; X static int tick() { X struct itimerval it, oit; X X timerclear(&it.it_interval); X it.it_value.tv_sec = 0; X it.it_value.tv_usec = 16665; X if (setitimer(ITIMER_REAL, &it, &oit) < 0) X perror("tick"); } X static void interrupt() { X if (count) X longjmp(env, 1); X (void) signal(SIGALRM, interrupt); X tick(); } X static unsigned long roulette() { X X if (setjmp(env)) { X count ^= (count>>3) ^ (count>>6) ^ ocount; X count &= 0x7; X ocount=count; X buffer = (buffer<<3) ^ count; X return buffer; X } X (void) signal(SIGALRM, interrupt); X count = 0; X tick(); X for (;;) X count++; /* about 1 MHz on VAX 11/780 */ } X unsigned long truerand() { X X count=0; X (void) roulette(); X (void) roulette(); X (void) roulette(); X (void) roulette(); X (void) roulette(); X (void) roulette(); X (void) roulette(); X (void) roulette(); X (void) roulette(); X (void) roulette(); X return roulette(); } X int n_truerand(n) int n; { X int slop, v; X X slop = 0x7FFFFFFF % n; X do { X v = truerand() >> 1; X } while (v <= slop); X return v % n; } X X X SHAR_EOF $shar_touch -am 0930143395 'truerand.c' && chmod 0644 'truerand.c' || echo 'restore of truerand.c failed' shar_count="`wc -c < 'truerand.c'`" test 2886 -eq "$shar_count" || echo "truerand.c: original size 2886, current size $shar_count" fi # ============= shs.c ============== if test -f 'shs.c' && test X"$1" != X"-c"; then echo 'x - skipping shs.c (file already exists)' else echo 'x - extracting shs.c (text)' sed 's/^X//' << 'SHAR_EOF' > 'shs.c' && /* X * The authors of this software are Jim Reeds and Jack Lacy X * Copyright (c) 1992, 1994 by AT&T. X * Permission to use, copy, and modify this software without fee X * is hereby granted, provided that this entire notice is included in X * all copies of any software which is or includes a copy or X * modification of this software and in all copies of the supporting X * documentation for such software. X * X * This software may be subject to United States export controls. X * X * THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED X * WARRANTY. IN PARTICULAR, NEITHER THE AUTHORS NOR AT&T MAKE ANY X * REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY X * OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE. X */ X /* X * Secure Hash Standard X * proposed NIST SHS X * coded for byte strings: number of bits is a multiple of 8 X * X * Copyright (c) 1992, 1994 AT&T Bell Laboratories X * Coded by Jim Reeds 5 Feb 1992 X * Enhanced by Jack Lacy 1993, 1994 X */ X /* X * unsigned char * shs(char *s, int n); X * X * input: X * s character array to be hashed X * n length of s in BYTES X * output: X * return value: address of 5 unsigned longs holding hash X * X * machine dependencies: X * assumes a char is 8 bits X */ X /* X * passes test on: X * gauss (vax) X * 3k (cray) X * slepian (MIPS) X * bird (sparcstation II) X */ X #include <sys/types.h> #include <stdio.h> X typedef struct { X long totalLength; X unsigned long h[5]; X unsigned long w[80]; } SHS_CTX; X unsigned char *shs(); #ifdef SOLARIS2X #define bzero(b, l) memset(b, 0, l) #define bcopy(s, d, l) memcpy(d, s, l) #define bcmp(s, d, l) (memcmp(s, d, l)? 1 : 0) #endif X static long nbits; static unsigned long *h; static unsigned long *w; static void shs1(); /* static void packl (unsigned long); static void pack (unsigned char, unsigned char, unsigned char, unsigned char); static void shs1(void); static void opack(unsigned char); */ X #define MASK (unsigned long)0xffffffffL /* in case more than 32 bits per long */ X /* X * stick one byte into the current block; process the block when full X */ static void opack(c) X unsigned char c; { X int n32, nd32, shiftbits; X register unsigned long x, mask, y; X X nd32 = (int)(nbits >> 5); /* nbits/32 */ X n32 = (int)(nbits & 0x1f); /* nbits%32 */ X shiftbits = 24-n32; X X x = (unsigned long)(c<<shiftbits); X mask = (unsigned long)(0xff << shiftbits); X mask = ~mask; X X y = w[nd32]; X y = (y & mask) + x; X w[nd32] = y; X X nbits += 8; X if(nbits==512){ X nbits = 0; X shs1(); X } } X static void pack(c0, c1, c2, c3) X unsigned char c0, c1, c2, c3; { X int nd32; X X nd32 = (int)(nbits >> 5); X w[nd32] = (u_long)(((u_long)c0<<24) | ((u_long)c1<<16) | ((u_long)c2<<8) | (u_long)c3); X X nbits += 32; X if(nbits==512){ X nbits = 0; X shs1(); X } } X /* X * stick a 4 byte number into the current block X */ static void packl(x) X unsigned long x; { X pack((unsigned char)(x>>24), (unsigned char)(x>>16), X (unsigned char)(x>>8), (unsigned char)(x>>0)); } X /* X * process one block X */ static void shs1() { X unsigned long *wp; X unsigned long temp; X unsigned long A, B, C, D, E; X int t; X #define S(n,x) (u_long)(((x)<<(n))|((MASK&(x))>>(32-(n)))) X X wp = w; X t = 8; X do { X wp[16] = S(1, (u_long)(wp[13]^wp[8]^wp[2]^wp[0])); X wp[17] = S(1, (u_long)(wp[14]^wp[9]^wp[3]^wp[1])); X wp[18] = S(1, (u_long)(wp[15]^wp[10]^wp[4]^wp[2])); X wp[19] = S(1, (u_long)(wp[16]^wp[11]^wp[5]^wp[3])); X wp[20] = S(1, (u_long)(wp[17]^wp[12]^wp[6]^wp[4])); X wp[21] = S(1, (u_long)(wp[18]^wp[13]^wp[7]^wp[5])); X wp[22] = S(1, (u_long)(wp[19]^wp[14]^wp[8]^wp[6])); X wp[23] = S(1, (u_long)(wp[20]^wp[15]^wp[9]^wp[7])); X wp += 8; X t--; X } while (t > 0); X X A = h[0]; X B = h[1]; X C = h[2]; X D = h[3]; X E = h[4]; X X t = 0; X while (t<20) { X temp = S(5,A) + E + w[t++]; X temp += (unsigned long)0x5a827999L + ((B&C)|(D&~B)); X E = D; D = C; C = S(30,B); B = A; A = temp; X } X while (t<40) { X temp = S(5,A) + E + w[t++]; X temp += (unsigned long)0x6ed9eba1L + (B^C^D); X E = D; D = C; C = S(30,B); B = A; A = temp; X } X while (t<60) { X temp = S(5,A) + E + w[t++]; X temp += (unsigned long)0x8f1bbcdcL + ((B&C)|(B&D)|(C&D)); X E = D; D = C; C = S(30,B); B = A; A = temp; X } X while (t<80) { X temp = S(5,A) + E + w[t++]; X temp += (unsigned long)0xca62c1d6L + (B^C^D); X E = D; D = C; C = S(30,B); B = A; A = temp; X } X h[0] = MASK&(h[0] + A); X h[1] = MASK&(h[1] + B); X h[2] = MASK&(h[2] + C); X h[3] = MASK&(h[3] + D); X h[4] = MASK&(h[4] + E); } X #define CHARSTOLONG(wp,s,i) {*wp++ = (u_long)((((u_long)(s[i])&0xff)<<24)|(((u_ long)(s[i+1])&0xff)<<16)|(((u_long)(s[i+2])&0xff)<<8)|(u_long)(s[i+3]&0xff));} X X void shsInit(mdContext) X SHS_CTX *mdContext; { X nbits = 0; X mdContext->h[0] = (unsigned long)0x67452301L; X mdContext->h[1] = (unsigned long)0xefcdab89L; X mdContext->h[2] = (unsigned long)0x98badcfeL; X mdContext->h[3] = (unsigned long)0x10325476L; X mdContext->h[4] = (unsigned long)0xc3d2e1f0L; X mdContext->totalLength = 0; } X X void shsUpdate(mdContext, s, n) X SHS_CTX *mdContext; X unsigned char *s; X unsigned int n; { X register unsigned long *wp; X long nn = n; X long i; X X w = mdContext->w; X h = mdContext->h; X mdContext->totalLength += n; X X nbits = 0; X n = n/(u_long)64; X wp = w; X X while(n>0){ X CHARSTOLONG(wp,s,0); X CHARSTOLONG(wp,s,4); X CHARSTOLONG(wp,s,8); X CHARSTOLONG(wp,s,12); X CHARSTOLONG(wp,s,16); X CHARSTOLONG(wp,s,20); X CHARSTOLONG(wp,s,24); X CHARSTOLONG(wp,s,28); X CHARSTOLONG(wp,s,32); X CHARSTOLONG(wp,s,36); X CHARSTOLONG(wp,s,40); X CHARSTOLONG(wp,s,44); X CHARSTOLONG(wp,s,48); X CHARSTOLONG(wp,s,52); X CHARSTOLONG(wp,s,56); X CHARSTOLONG(wp,s,60); X n--; X wp = w; X s = (s + 64); X shs1(); X } X i=nn%64; X while(i>3) { X CHARSTOLONG(wp,s,0); X s = (s + 4); X nbits += (u_long)32; X i -= 4; X } X while (i) { X opack((unsigned char)*s++); X i--; X } } X void shsFinal(mdContext) X SHS_CTX *mdContext; { X long nn = mdContext->totalLength; X w = mdContext->w; X h = mdContext->h; X X opack(128); X while(nbits != 448)opack(0); X packl((unsigned long)(nn>>29)); X packl((unsigned long)(nn<<3)); X X /* if(nbits != 0) X handle_exception(CRITICAL,"shsFinal(): nbits != 0\n");*/ } X unsigned char * shs(s, n) X unsigned char *s; X long n; { X SHS_CTX *mdContext; X static SHS_CTX mdC; X static unsigned char ret[20]; X int i; X X mdContext = &mdC; X X shsInit(mdContext); X shsUpdate(mdContext, s, n); X shsFinal(mdContext); X for (i=0; i<5; i++) { X ret[i*4] = (mdContext->h[i]>>24)&0xff; X ret[i*4+1] = (mdContext->h[i]>>16)&0xff; X ret[i*4+2] = (mdContext->h[i]>>8)&0xff; X ret[i*4+3] = (mdContext->h[i])&0xff; X } X X return ret; } X /*int fread(char *, int, int, FILE *);*/ X unsigned long * fShsDigest(in) X FILE *in; { X SHS_CTX *mdContext; X SHS_CTX mdC; X unsigned char buffer[1024]; X long length, total; X X mdContext = &mdC; X X bzero(buffer, 1024); X X total = 0; X shsInit(mdContext); X while ((length = fread(buffer, 1, 1024, in)) != 0) { X total += length; X shsUpdate(mdContext, buffer, length); X } X shsFinal(mdContext); X X return mdContext->h; } X X X SHAR_EOF $shar_touch -am 0930142495 'shs.c' && chmod 0644 'shs.c' || echo 'restore of shs.c failed' shar_count="`wc -c < 'shs.c'`" test 7142 -eq "$shar_count" || echo "shs.c: original size 7142, current size $shar_count" fi # ============= randtest.c ============== if test -f 'randtest.c' && test X"$1" != X"-c"; then echo 'x - skipping randtest.c (file already exists)' else echo 'x - extracting randtest.c (text)' sed 's/^X//' << 'SHAR_EOF' > 'randtest.c' && main(argc,argv) int argc; char **argv; { X int count; X X if (argc==1) X count = 0; X else X count = atoi(argv[1]) + 1; X while (--count) X randbyte(); } SHAR_EOF $shar_touch -am 0930150095 'randtest.c' && chmod 0644 'randtest.c' || echo 'restore of randtest.c failed' shar_count="`wc -c < 'randtest.c'`" test 149 -eq "$shar_count" || echo "randtest.c: original size 149, current size $shar_count" fi exit 0

1 0

Re: Cryptanalysis of RC4 - Preliminary Results (Repeat)
by Bill Stewart 17 Dec '03

17 Dec '03

At 01:01 PM 9/29/95 S, Andrew Roos <AndrewR(a)beetle.vironix.co.za> wrote: >(This is a repeat because I posted the original 36 hours ago and it still >hasn't bounced back to me.) Hmmm - I got it yesterday, so it did go out. >The attack is based on two particularly interesting three-byte key >prefixes which have a high probability of producing PRNG sequences >which start with a known two-byte sequence. The prefixes are: >1. Keys starting with "00 00 FD" which have a 14% probability of > generating sequences which start "00 00". >2. Keys starting with "03 FD FC" which have a 5% probability of > generating sequences which start "FF 03". [much interesting work deleted] It sounds like any application using RC4 with random session keys should start by testing session keys and rejecting any that start with 00 00 or 03 FD; it means doing 2**-15 more random key generations, and reducing the brute-force space by 2**-15, but it's a pretty small reduction. #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

2 1

Re: Q&A on the RSA/Cylink legal dispute
by Bill Stewart 17 Dec '03

17 Dec '03

At 08:27 AM 9/29/95 -0400, Jeff Barber <jeffb(a)sware.com> wrote: >That's pretty clear to me folks, but make your own judgements. >> If you're using RSA's software -you didn't write your own- you don't need >> a separate patent license under either the MIT or Stanford patents. >Again, only to the extent that you're not infringing the Stanford patents. > >So, pay your nickel, take your chances. Does RSA's software infringe >the Stanford patents? The RSA algorithm, and thus RSA's software, uses public-key cryptography, and is therefore within the scope of the claims of the Merkle-Hellman and/or Hellman-Pohlig patents. Also, the recent RSAREF versions contain Diffie-Hellman code, which is covered by the Diffie-Hellman patents (but PGP doesn't use that version of RSAREF.) On the other hand, the RSAREF license says that RSA will defend any patent claims for use of its code (I forget if that was RSADSI or RSA Labs), and Jim Bidzos confirms that that's still the case even after the PKP breakup. #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Info War Comes Home
by Duncan Frissell 17 Dec '03

17 Dec '03

[Note: Whenever I do one of my longer pieces, it seems to drop into the void. Perhaps they are so well written and complete that no one can think of any comment to make on them. Perhaps not. Read this one and comment. You won't regret it.] In honor of the Second Annual Conference on Information Warfare a few weekends ago, here is my proposal towards a paper to be presented at next year's conference. ************************************************************************* The Mesh in the 'Hood If any of you have not read every word of The Economist's Survey of Defence Technology - "Softwar" in the June 10, 1995 issue --- shame on you. Do so immediately. In that report, there is the following description of the future battlefield without platforms (ships, aircraft, armor). AKA the Mesh. The Mesh is a network imposed over a landscape (what used to be called a battlefield). The network of sensors, smart munitions, small attack modules, and perhaps human troops, shares information and kills enemies moving through it. Friendly forces travel through it as if it weren't there. It is "flat." Hills and valleys disappear and expensive platforms [tanks, helicopters, etc.] have nowhere to hide since it is co-extensive with the whole territory it covers. It is also tough because it is hard to destroy enough parts of it to make a difference. Nuclear munitions might destroy a Mesh or imposing a stronger Mesh over an existing one might work if you didn't mind wholesale destruction but defeating it without massive destruction is hard. To quote from the Survey: "The mesh has a number of advantages. It is hard to attack, because its strength is spread widely. It is hard to damage, because there are so many communication paths. Many small sensors can provide a better picture than a few large ones. More sensors allow the information domain to conform more closely to the physical terrain. At the moment line-of-sight detection by sensors in a widespread network leaves topographical blind spots--wadis, narrow valleys--in which platforms such as attack helicopters can lurk." "While nets may see through the fog of war, meshes also tackle another of the problems von Clausewitz identified; war's friction. The mesh is a war machine with almost no moving parts, save the actual warheads of the weapons. It is a solid-state device; its mechanisms have migrated far into the spectral dimension of information, leaving only a thin skeleton framework in the world of height, breadth and depth." It certainly makes for a challenging war environment. The Mesh is created by warriors to effectively serve warriors' ends, I would like to suggest the possibility that civilians might create their own Mesh to serve their ends. A Mesh is Just a Net with Attitude The Internet is (as we all know) a network of interconnected computers that cooperate to exchange information in a standardized fashion. Its purpose is communication. If its purpose is extended, it can become a Mesh. Assume that the Net has grown in size and importance so that a significant portion of the population in a given geographic area is fully wired --- hardly a dramatic assumption. All of those machines are cooperating to enable the various sorts of communications that people want to use the Net for. Some of those machines are already connected to external cameras to do "silly" things like put pictures of Stockholm on the WWW. What if people connected other things to the Net? While it is unlikely that most people will put a chain gun in the window and interface it with the Net anytime soon, other useful connections are possible. [And even in the case of weaponry, specific neighborhoods might be interested in doing creative things now. Thus Bo Grtiz' heavily armed, Patriot, Recreational Subdivision in Idaho might find a use for the Mesh. And won't those Black Helicopters be surprised.] More peaceful civilians might deploy a Mesh to protect themselves against bad people whether official or unofficial. Like the existing Speedtrap website (http://www.nashville.net/speedtrap/) but in real time, cameras and passive sensors could track the minions of the State as they cruise through neighborhoods. They could also multicast live, full color, and audio images of arrests and less formal interactions with the authorities. Fans of Robert Heinlein will recall that Jubal Harshaw used a version of this strategy in "Stranger in a Strange Land." Cops behave better when they are on camera (and know it.) The Net allows everyone to play. END OF PART I (More next week).

2 1

"Who shall speak for us?"
by tcmay＠got.net 17 Dec '03

17 Dec '03

The questions "Who are the Cypherpunks?" and "Who shall speak for us?" have come up several times, in different contexts: -- Reporters want "human interest" stories for their other stories on Netscape cracks, SSL challenges, arrests, executions, etc. They want to know who we are, what our agenda is, what motivates us, and who our spokesmen are. -- "Who shall be our Spokesman?" keeps coming up. "Who shall speak for us?" -- There is once again talk about "getting organized" so as to better compete with EPIC, EFF, CPSR, VTW, ACLU, etc. While no one is seriously advocating a formal, dues-collecting organization, their is an undercurrent of thought that we had better get more organized or we'll just be roadkill on the information superduperhighway. -- And there seems to be a sense of uneasiness amongst some of us that there can't be a "Cypherpunks group" without organization, without hierarchy. In contrast, there have been points made that we are "nothing," not even a group, and that we are only a set of mailing list subscribers. I think this is too extreme a view, as we clearly have: * some sense of membership in a group, some sense of cohesion, some sense of "Us" vs. "Them." * regional activities in several parts of the U.S. and in some non-U.S. countries. * a growing archive of postings, of knowledge gained through hard work. So, we are _more_ than just the subscribers to a mailing list, but _less_ than a formal organization with shareholders, voters, elected officials, and a Great Leader at the top. What are we, then? One parallel is to a bunch of folks who meet at a gathering spot, perhaps a bar or pub. Perhaps a reading group, a book club. People who talk, speculate, exchange theories, and even decide on things that some of them will do. Maybe these folks, an ever-changing set of folks, will come to some commonly-held viewpoints, though not held by all folks, and not "voted on" to be the Official Position of this informal gathering of folks at the local bar. Cyberspace allows for all sorts of new kinds of "watering holes" where such emergent, loosely-organized, anarchic groups may develop. These "virtual communities" are an incredibly important development. (My paper given at Imagina '95, in Monte Carlo, "Crypto Anarchy and Virtual Communities," goes into this in detail.) Another parallel is to what is sometimes called an "invisible college." Academic researchers in a country or around the world form a loose kind of invisible college, a network of people at various institutions that share a common interest and that have certain emergent standards. Think of the cryptology researchers, or the fusion researchers, of the world. In this invisible college, reputations matter. Some researchers are more esteemed than others, some play different roles than others. Some of them are mostly teachers, others are buried deeply in their laboratories. And, as with the informal pub gathering, this invisible college does not have to "vote" on an official position, or "elect" leaders. Ah, I hear some of you pointing out, "But in fact some of these invisible colleges _do_ elect officials and _do_ have official positions!" Indeed, many invisible colleges develop subsets that have formal structures and become the de facto _professional guilds_ for their organizations. The American Association of Chiropractic Examiners, the French League of Graph Paper Experts, the Russian Federation of Agriculturists, and on and on. (More seriously, the American Bar Association, the American Medical Associatio, etc.) Often these "professional organizations" are designed to extend the reach of these organizations, to give official titles to the early organizers, and to lobby governments for laws favorable to their members. Often these formal organizations adopt licensing rules and regulations to "police themselves" and also, in well-known cases of "public choice" theory and "rent-seeking behavior," to limit the number of competitors. Often the other hierarchies, such as the State itself, endorse the rules adopted by the professional guilds. (I'm not saying anyone is directly arguing that the Cypherpunks, not even by innuendo, become a professional guild, but some of the clamoring about how we need to adopt a less threatening or strange name, organize ourselves more hierchically, and present a more unified front is often a step toward a rigid bureaucracy.) It's been gratifying to me, at least, that the Cypherpunks group has not fallen prey to this temptation, that in an important sense "we practice what we preach." We claim to be an "anarchy," not a "hierarchy." While it may be the case that each of us has his or her own personal heirarchical ratings of others, it is important that we never have tried to formalize or "vote on" these ratings. Or voted to elect a Great Leader. Our strength is in our numbers and in our ideas, not in the guy we have ensconced in an office in Washington so he can give press conferences and sound bites for journalists. Our strength is in our multi-headed (dare I mention "Medusa"?), multinational, informal lack of structure. "But how will _We_ compete with the organizations that have Washington offices? How will we get "air time" if we have no Spokespunk in Washington, or no list of Official Spokespunks that journalists can call to get The Cypherpunks Slant on things? Who shall speak for us?" The answer is simple: Let no one claim to speak for "us." Let no one claim to be a speaker for others. Let journalists adjust to a new way of speaking, a nonhierarchical way of saying "I think" and "My view is." Let journalists contact the people actually doing something they are writing about. Let journalists call the people directly involved, not the Official Spokespunks. It may be _easier_ for some journalists to simply call the guy they always call, just to get a "reaction quote," but our job is not to make it easier for some lazy journalists. And let those who dislike the name "Cypherpunks" call themselves something else. Nothing's stopping them. Of course, it may be that the people wanting a more conservative, more staid name also wish to "inherit" the mantle the Cypherpunks now have, wish to convey to the "International Association of Cybernetic Privacy Advocates," or whatever, the membership and reputation of the current and past Cypherpunks. This, I think, is the "old way" of doing things, the herd way. If the views many of us have about anarchy and cyberspace are correct, this way of operating represents the future. If not, who cares what we think? --Tim May ---------:---------:---------:---------:---------:---------:---------:---- 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."

2 1

HP Lobbies for Exportable Crypto
by bwern＠jax.jaxnet.com 17 Dec '03

17 Dec '03

>From the 28th of September's EDUPAGE: HP LOBBIES FOR EXPORTABLE ENCRYPTION PLAN Hewlett-Packard has developed an encryption strategy with the French company Gemplus SCA that they're hoping will pass the tough scrutiny of U.S. export controllers. The plan takes a two-pronged approach -- an "encryption engine" that works in conjunction with a code-making formula that can be adjusted to any level deemed acceptable by the U.S. government, and a policy card that would be reviewed on a case-by-case basis by the State Department. The flexible system is designed to adapt to changing government policies, and could even accommodate a key escrow system like the Clipper chip. "There was a lot of skepticism when HP first proposed it. But it looks to me that they are well on the way to the next step," says a former encryption specialist at the National Institute of Standards and Technology. (Wall Street Journal 27 Sep 95 B7) Ben Wern bwern(a)jaxnet.com | bwern(a)pathtech.com | bwern(a)unf.edu SAY NO TO TALKING COWS! ------------------------------------------------------------------------- "We are more than the sum of our knowledge, we are the products of our imagination."

1 0

RE: Cryptanalysis of RC4 - Preliminary Results (Repeat)
by Andrew Roos 17 Dec '03

17 Dec '03

Hi Bill You could check for the full three-byte prefix, which further reduces the number of keys you have to discard. Although all keys beginning "00 00" are weak in the sense of my original post, they do not appear to be as exploitable as the prefixes which generate two-byte probable sequences. I also recommend generating and discarding some initial sequence bytes, since the generation process mixes up the state table further. An extra "round" through the state table (i.e. generating 256 bytes) _appears_ to confuse things significantly, since by the time you've generated the initial state table from the key, Index Y is a function of all bytes of the key, so the second time around it's hard to figure out the impact of the byte swaps. But I wouldn't trust this without a significant amount of analysis: as always in this field, appearances can be dangerously deceptive. Of course, this defense is not possible with protocols like SSL where you have to follow the spec - or better still, PCT which conveniently moves the MAC to the *end* of the record, exposing the initial stream... Andrew ---------- From: stewarts[SMTP:stewarts@ix.netcom.com] Sent: 29 September 1995 10:16 To: Andrew Roos Cc: cypherpunks Subject: Re: Cryptanalysis of RC4 - Preliminary Results (Repeat) It sounds like any application using RC4 with random session keys should start by testing session keys and rejecting any that start with 00 00 or 03 FD; it means doing 2**-15 more random key generations, and reducing the brute-force space by 2**-15, but it's a pretty small reduction. ________________________________________________________________ Andrew Roos <andrewr(a)vironix.co.za> // C++ programmers have class (but not much inheritance) PGP Fingerprint: F6 D4 04 6E 4E 16 80 59 3A F2 27 94 8B 9F 40 26 Full key at ftp://ftp.vironix.co.za/PGP-keys/AndrewRoos

1 0

Re: VISA and Microsoft STT Specs available
by Bill Stewart 17 Dec '03

17 Dec '03

At 11:10 AM 9/29/95 -0400, Phill wrote: >Yes, VISA put the ASCII on their site... >We only host the ps version. Thanks! I looked at the Visa site, and it has a usable form of the documents still under construction; I waded through the 73-separate-page HTML version for a while.... There's some good intro material on how you use the stuff and who's responsible for what. Microsoft has the technical specs as one big slightly-HTMLized text file under http://www.windows.microsoft.com/windows/ie/stt.htm ; it's _much_ more readable, and has a pointer to the Visa version. (It's one big <PRE> with a few <B> and hrefs, in black-on-white.) Some cryptographic high points, from a brief scan. - 1024-bit RSA signatures, using PKCS#1 format. - SHA 160-bit hashes - Symmetric bulk crypto includes two options (I haven't yet seen how you choose between them; I assume it's export/domestic?) == RC4/64 with 24 bits of salt leaving 40 bits of real key == DES-CBC - yes, that's single-DES. IV=0. #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

2 1

This fax list is 95% accurate!
by carolann＠censored.org 17 Dec '03

17 Dec '03

Sorry the whole HTML is here, however, if you now want to make "A CYPHERPUNK SPEAKS....." Press Release, this fax list will do it for you, only two or three numbers are unverified! (and that's as of today!) <html> <head> <title> Fearless Fax Numbers Revised 9-29-95 </title> </head> <center> <h1>Transgender Lobby Days Website</center> </center> <pre> I promised last week that I would send this out when the idea of a blanket-fax-campaign for a c-punks press release was being discussed. Sorry it took me so long to get around to it, but here it is. I was mistaken in my original posting: it includes neither the Fox Network _nor_ the Eye on America show, but I'm sure we'll find those numbers somewhere. I got it from the Iron Feather Journal, volume 14. I have no reason to believe that any of these numbers are incorrect, but some of them may have changed. Also: personal apologies to anyone who considers this to be noise. Please restrict all flames to private e-mail. Anybody wanna fax Ted Turner? :) ABC 20/20 NY 1-212-456-2969 Ann Arbor News Ann Arbor, MI 1-313-994-6879 AP Los Angeles 1-213-748-1200 AP San Diego 1-619-291-2098 AP (Broadcast) Washington, D.C. 1-202-955-7367 Associated Press Los Angeles 1-213-748-9836 Steve Loeper Associated Press Phoenix, AZ 1-602-254-9573 Assignment Editor Associated Press San Francisco 1-415-552-9430 Bill Schiffmann Associated Press MN Minneapolis, MN 1-612-332-4245 Boston Phoenix Boston, MA 1-617-536-1463 Boulder Daily Camera Boulder, CO 1-303-442-1508 C-SPAN Washington, D.C. 1-202-737-6226 Sarah Traheorn CBS Washington, D.C. 1-202-659-2586 CBS (Radio) Washington, D.C. 1-202-659-5578 CBS Eve News NY 1-212-975-2115 CBS Morning Washington, D.C. 1-202-331-1765 CBS News Los Angeles 1-213-651-0285 Jennifer Siebens CBS News San Francisco 1-415-362-7417 John Blackstone CBS TV Los Angeles 1-213-651-0321 CBS TV San Francisco 1-415-362-7417 Chicago Sun-Times Chicago, IL 1-312-321-3084 Chicago Tribune Chicago, IL 1-312-222-3143 CNN San Francisco 1-415-398-4049 CNN President Atlanta, GA 1-404-827-1575 Ted Turner Coloradoan Fort Collins, CO 1-303-224-7726 Denver Post Denver, CO 1-303-820-1369 Der Spiegel Hollywood, CA 1-213-851-9867 Frances Schoenberg Detroit News Detroit, MI 1-313-222-2335 ESPN Bristol CT 1-800-592-3776 Gannett Washington, D.C. 1-202-243-0190 Gannett News Service Sacramento, CA 1-916-446-7326 Becky Lavally KFAN AM Minneapolis 1-612-820-4265 Kostabi Media New York 1-212-925-3055 Mother Jones San Francisco, CA 1-415-863-5136 Douglas Foster NBC Washington, D.C. 1-202-362-2009 NBC News Burbank, CA 1-818-840-4275 Heather Allan NBC News President New York NY 1-212-315-4037 NBC TV Los Angeles 1-818-840-4275 Newsweek Washington, D.C. 1-202-783-6512 NPR Radio San Francisco, CA 1-415-553-2241 NY Times New York, NY 1-212-556-4603 PBS Alexandria, VA 1-703-739-0775 Pulse! West Sacramento, CA 1-916-373-2480 Laurie Macintosh Rainbow Coalition Washington, D.C. 1-202-728-1192 Reuters Los Angeles 1-213-622-0056 Rocky Mountain News Denver, CO 1-303-892-5499 Scripps Howard Washington, D.C. 1-202-408-8116 Shareware Magazine Sunnyvale, CA 1-602-839-2872 Tracy Stephenson Sports Fan Radio Net Las Vegas NV 1-702-737-1906 Time San Francisco, CA 1-415-434-5209 Paul Witteman Time Magazine NY 1-212-522-0451 UPI Boston, MA 1-617-338-9774 Barry Fly UPI Los Angeles 1-213-620-1237 UPI San Francisco 1-415-552-3585 Bill Bucy UPI Seattle, WA 1-206-283-0408 Penny Spar UPI Washington, D.C. 1-202-789-2362 UPI (Radio) Washington, D.C. 1-202-842-3625 US News & Wrld Rprt Washington, D.C. 1-202-955-2713 USA Today Washington, D.C. 1-202-955-2049 Utne Reader Minneapolis, MN 1-612-338-6043 Whole Earth Review Sausalito, CA 1-415-332-2416 Kevin Kelly kelli(a)zeus.towson.edu Geek Code v3.0 http://zeus.towson.edu/~kelli/ GAT dx s++:- a-- C++ uu+++ P+ L++ E- W++ N K W--- O- M- V-- PS+++ PE- Y++(-)> PGP+>++ t+ 5 x+ R tv b+++ DI- D--- G e h* r+ z** Diverse Sexual Orientation Coll.Towson State University DSOC(a)zeus.towson.edu "All the world will be your enemy, Prince With The Thousand Enemies. . . And whenever they catch you, they will kill you. But first, they must catch you. . ." -Richard Adams </pre> carolann(a)censored.org </html> -- Member Internet Society - Certified BETSI Programmer - Webmistress *********************************************************************** Carol Anne Braddock (cab8) carolann(a)censored.org 206.42.112.96 My Homepage The Cyberdoc *********************************************************************** ------------------ PGP.ZIP Part [017/713] ------------------- M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M MF=O0H+*%(-S%&>S%+FS&<LS%3(Q&#W1"<]2%`H^;,]^1C$'HBN8PX$4SYAU^ MPGD<Q0ZLA0D+,`MCT!LA**4M[-JPAK9F?40!AJ,CW"'%DR#:'9?Q)3[%<DQ` ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/

1 0

STT is 40-bit for RC4, 56-bit for DES
by Stephan Somogyi 17 Dec '03

17 Dec '03

>From the STT spec, page 73: 6.8 CRYPTOGRAPHY A. Encryption Two bulk encryption algorithms are used in STT - RC4 and DES. 1. STT uses RC4 encryption with 8-byte keys, of which 3 bytes are salt, in the clear. See the RC4Key entry under the Low Level Composites sub-section of this document. RC4 is a stream cipher; there are no pad bytes and the encrypted data is the same size as the plaintext data. 2. STT uses the Cipher Block Chaining (CBC) mode of DES, as defined in Federal Information Processing Standard FIPS 81. The key is 8 bytes long, with each byte having a parity bit in position 0. Thus there are 56 bits of random key. STT uses an all-zero byte Initialization Vector (IV). A maximum of 8 bytes of padding is applied to every plaintext message encrypted with DES to pad the message to a length that is a multiple of 8 bytes. Pad bytes have a value of x = 8 - ((length of the plaintext) mod 8) and the number of pad bytes is also x. For example, if the plaintext message was 17 bytes long, then each of the 7 bytes of padding contains the value 0x07. If x is 0, then there are 8 bytes, each containing 0x08. Padding is appended to the end of the plaintext before encryption and is stripped off after decryption. B. Signatures STT uses PKCS #1 Encryption block formatting for RSA signatures. Total length is 128 bytes for the signature (1024-bit modulus). The following is the plaintext: (TLV_SIGNATURE (BYTE[20] HashOfData) ;Hash of the data being signed (BYTE 0) ;parser initializer (BYTE[105] 0xff) ;padding (BYTE 0x01) ;recom. for private key encryptions (BYTE 0)) ;overflow protection for RSA C. Hashing All hashes in STT are 20-byte SHA hashes. See Federal Information Processing Standards FIPS 181 for the specification of SHA hashes. ________________________________________________________________________ Stephan Somogyi Mr Gyroscope Digital Media

1 0

(Fwd) Internet Euro-Clipper
by Peter Trei 17 Dec '03

17 Dec '03

------- Forwarded Message Follows ------- >From Risks Digest, via www-buyinfo ============================================ F Y I from the RISKS DIGEST----------- Date: 20 Sep 1995 12:24:10 GMT From: rja14(a)cl.cam.ac.uk (Ross Anderson) Subject: European Governments Agree to Ban Strong Crypto According to an article in `Communications Week International', the 34-nation Council of Europe has agreed to outlaw strong encryption products which do not make keys available to governments. The article, `Euro-Clipper chip scheme proposed', is on the front page of the magazine's issue 151, dated 18th September, which arrived in my mail this morning. It relates that the policy was approved on the 8th September at Strasbourg by the Council, and coincides with an attempt by the European Commission to propose a pan-European encryption standard. The Council - unlike the Commission - has no statutory powers to enforce its recommendations. However, Peter Csonka, the chairman of the committee that drafted the document (and an administrative officer at the Council's division of crime problems) says that `it is rare for countries to reject Council of Europe recommendations'. The proposal would make telecomms operators responsible for decrypting traffic and supplying it to governments when asked. It would also `change national laws to enable judicial authorities to chase hackers across borders'. Opposition to this measure was expressed by Mike Strezbek, VP responsible for European telecomms at JP Morgan, who said that his organisation `will challenge any attempt to limit the power of our network encryption technologies very strongly'. Czonka said that the Council had given consideration to business interests but had tried to strike a balance between privacy and justice. However, `it remains possible that cryptography is available to the public which cannot be deciphered,' his document says. `This might lead to the conclusion to put restrictions on the possession, distribution, or use of cryptography.' Apparently another international organisation, the OECD, has called a conference of its members in December to devise a strategy on encryption. I for one will be making clear to my MP that his stand on this issue will determine how I cast my ballot at the next election. I note that John Major stated in a 1994 parliamentary written reply to David Shaw MP that the government did not intend to legislate on data encryption. I am disappointed that government policy has changed to the point of supporting the Council of Europe, and that this change has sneaked through during the parliamentary recess. Ross Anderson Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

1 0

SOFTWARE: Filtering ads out of popular web sites
by lethin＠ai.mit.edu 17 Dec '03

17 Dec '03

On the subject of HTTP proxies, [SEVERAL FWD'S DELETED, ENTERTAINING SUBJECTS RETAINED] - - - Begin forwarded message - - - Subject: The agents/advertising arms race heats up Subject: OH YEAH BABY, FILTER ME HARDER >From: Axel Boldt <boldt(a)math.ucsb.edu> >Newsgroups: comp.infosystems.www.announce >Subject: SOFTWARE: Filtering ads out of popular web sites >Organization: Univ of California at Santa Barbara, Dept of Mathematics >Approved: www-announce(a)boutell.com >Message-ID: <44ercn$nhl(a)holly.aa.net> Several popular web sites have recently turned to putting advertising gifs on their pages. NoShit is a tool that filters these out so that you don't see them - in fact, you don't even download them in the first place, thus saving time, money and brain capacity. NoShit is implemented as a set of patches against Cern httpd to turn it into a "filtering proxy server". This means that the proxy maintains a list of URL templates together with corresponding filter scripts. When a document is requested form the proxy that matches one of the templates, then the page is piped through the corresponding script before being presented to the client. This works together with caching, if desired. The idea is to run your own personalized NoShit proxy server and point your browser to it. The proxy does the filtering; the browser doesn't even know about it. This scheme works with every browser. I have written a ready-to-use library of filter scripts for a couple of well known, ad-infected sites, including Yahoo, Lycos, Netscape, HotWired, CNN, Infoseek and NandO Times. You can change these or add your own very easily. Locations: <URL:http://math-www.uni-paderborn.de/~axel/NoShit/> (Germany) <URL:http://emile.math.ucsb.edu:8000/~boldt/NoShit/> (California) Enjoy, Axel - - - End forwarded message - - -

1 0