December 2003 - cypherpunks-legacy

The NSA's influence on New Zealand crypto policy
by pgut001＠cs.auckland.ac.nz 17 Dec '03

17 Dec '03

For nearly a year I've been involved in an ongoing battle with several government departments and the odd intelligence agency in an attempt to clarify NZ's position on the export of crypto software. The whole story has now got about as far as it can go, so I thought I'd share it with others. I've been trying to get the media to take an interest in this, but noone really seems to care... if anyone knows any journalists who might be interested in it, feel free to pass it on. I've got more details including names of contact people and phone numbers in case anyone needs to verify parts of the story. The main players are: The Government Communications Security Bureau (GCSB), a New Zealand intelligence agency (for US readers, the GCSB is the NZ subsidiary of the NSA). The foremost authority on the GCSB is Nicky Hager, who recently published the book "Secret Power" which documents their activities. The Defence Signals Directorate (DSD), an Australian intelligence agency (the Australian version of the NSA). The Ministry of Foreign Affairs and Trade (MFAT), a New Zealand government department. New Zealand Customs. Cyphercom Solutions, a New York company which produces financial/online commerce systems. Kiss Audio Video, an Australian video production company. Orion Systems, a New Zealand company which produces medical information and communication systems for transmitting medical information. Myself (Peter Gutmann) and cryptlib, my free encryption library http://www.cs.auckland.ac.nz/~pgut001/cryptlib.html In April 1996 I got a call from someone who worked for Cyphercom Solutions, a New York company who wanted to use my cryptlib encryption library in a project they were working on. Their lawyers wanted them to obtain an official, physically exported copy so that there wouldn't be any complications later on if the source of the software were ever called into question. The application involved financial transaction processing, and they had received indications from the NSA that it would be looked on favourably in terms of getting export permission. Somewhat strangely though, they were given the distinct impression that to get anywhere, they'd need to play ball with the NSA, even though it was NZ software being exported from NZ, where the NSA should have no jurisdiction. At this point a brief explanation of the export law situation in NZ is in order. The Customs Act of 1996, Section 54, "Prohibited Exports", states that "The Governor-General may from time to time, by Order in Council, prohibit the exportation from New Zealand of any specified goods or goods of a specified class or classes" (followed by a list of specific conditions on prohibitions). There's no further information in the Customs Act, but NZ Customs have a short publication "New Zealand Customs Fact Sheet: Export Prohibitions and Restrictions" which contains, among such curious items as cat skins and a large list of agricultural products which can't be exported without going via the appropriate government department, the item "Strategic goods such as computers, navigation and marine equipment, firearms, ammunition, explosives, military aircraft and vessels". The responsible government department is the Ministry of Foreign Affairs and Trade (MFAT, pronounced "em-fat"). Apparently computer software comes under the same classification as computers (MFAT extends the Customs definition of "Strategic goods" to cover "Computer technology, information security systems, and telecommunications equipment"). The entity within MFAT which handles this is the International Security and Arms Control Division, who are advised by the Government Communications Security Bureau (GCSB), the New Zealand NSA subsidiary. Once you get past the part where NZ Customs are involved, the whole setup is run like the mafia. Nothing is ever written down, everything is done verbally. Although it took only a paragraph to describe how this works, it took more than two months of work to find out in practice. Unless you know exactly who to ask for information, noone has ever heard of these restrictions. A search of NZ legal databases found nothing. Several IP lawyers had never heard of these restrictions. Noone seemed to know anything about any restrictions. (In an October newsletter, MFAT retroactively gave themselves jurisdiction over this area, this is covered further down). An initial discussion with MFAT revealed that NZ Customs tend to apply restrictions based on the old COCOM rules, which have been superseded by the Wassenaar agreement. For this reason export permits are required for shipments to certain eastern european countries, certain middle eastern countries, and the current UN politically-incorrect-country club. Export to countries other than that would be unlikely to require a permit. In May, Cyphercom therefore decided to try to export the software to the US and Singapore. Initially MFAT said this was OK. Then at the last minute they changed their minds and imposed the following restrictions: - No encryption algorithms except single DES. - Keysize limited to 64 bits (this is peculiar, I assume it's to stop me from using tricks like key-dependant S-boxes and DESX, which I'd discussed in email with people in the US some time ago). - Definitely no triple DES (this was specifically mentioned). - Export limited to object code only (so the key size couldn't be changed). The text of the message (with a few names removed) is: "The Secretary of Foreign Affairs and Trade has no objection to the export of the XXX financial package, as detailed in the following application from YYY, *provided that* the library of encryption algorithms is limited to DES (but not triple DES) and any required hash algorithms, dated 15 May 1996". In the accompanying description of the library, every single algorithm except DES and the hash algorithms have been crossed out. Note that this is for export to the US, which has its own export restrictions anyway (the same thing was done for the Singapore export). Inquiries by lawyers in the US indicated that there had been a flurry of communication between the NSA and the GCSB over this (as one person - not one of the lawyers BTW - I talked to put it, "When the NSA says 'Bend over', the GCSB says 'How far?'"). The NSA might as well have signed the export (non-)permit themselves. The story from the US lawyers was that there was "repeated intervention of the NSA" and that "NZ is out of its depth, it was terrified of offending the US". >From the information I've been able to gather the whole thing seems to have been initiated by the GCSB rather than the NSA, who were afraid to do anything without NSA approval. The GCSB went to the NSA and asked them what they should do, the result was the (non-)permit. A DSD person also later told a reporter that the GCSB had gone to the DSD and asked them "Would you allow the export under these conditions?". The DSD said "No". Shortly before this, the Canadian government, which follows the same export guidelines as New Zealand (dual-use technology under the Wassenaar agreement), had ruled that cryptlib was exportable to anywhere except the previously mentioned restricted countries, with no permit necessary, and no need to apply for a permit: "Application No.278466 covering cryptographic software proposed for export to England, this software is not controlled according to Canada's ECL. Therefore, provided the product noted in this application is not of US origin within the meaning of the ECL item 5400, these goods may be exported to any country, except Libya and Angola, without an export permit. Please note that most goods to Iraq are still prohibited at this time, as well". The interesting thing about the Canadian decision was that I was contacted twice by Canadian export controls people who asked me a number of very detailed questions about the software, whereas MFAT managed to come to their decision without ever examining the encryption software or talking to its author. As far as I've been able to tell MFAT had very little to do with the decision: They have to follow the GCSB's advice, and the GCSB won't do anything without the NSA's permission. The opinion from lawyers in NZ was that they were acting far outside their authority. In any case in late May two copies of the software on 3.5" disks were sent out by a large accounting firm acting for Cyphercom, one to the US and one to Singapore as provided for in the export permit. At about the time the original export appeal was lodged, the GCSB had told another NZ company, Orion Systems, that they couldn't export a product with the encryption necessary to protect patient medical data, lab results, patient referrals, and so on, without obtaining an end user certitificate for each user. To sell a copy to just the one overseas site which the inquiry was about would have required otaining two thousand certifications from all the end users. Larger sites with ten thousand users are not unknown. This meant that Orion would have had to somehow obtain 2000 signed declarations from users just to allow the exchange of medical records (this tactic has also been successfully used by the US government to effectively block certain software exports by US firms). Orion didn't even bother going to MFAT, because if the GCSB required these impossible-to-meet conditions then going to the next level down in the chain of command would make no difference. After chasing my way around a number of government departments I talked to some people in the Ministry of Commerce who advised that the best way to resolve this craziness was to write to MFAT and inform them that the Canadian government had ruled that the library was freely exportable and that there was no reason for them blocking the export, and ask under what authority the export was being blocked. This letter was sent to MFAT in mid-September (incidentally, the way government departments refer to the GCSB is wierd. Noone ever says "the GCSB", it's always "another government department" or "an organisation which I won't name", as if there was some belief that using The Dreaded Name will cause evil to descend upon the person who utters it, much like the use of the work J*h*v* or Lovecraft's "He Who Is Not To Be Named"). Anyway, at this point, things started to get weird. At about the time I wrote the letter, I was FedEx'd an NDA sent from lawyers representing PGP Inc (a US encryption software vendor) to Orion Systems, sent in a standard FedEx letter envelope. It was intercepted by NZ Customs and opened, and the contents examined, before I got it. This wasn't the usual random (and quite rare) "Examined by Customs" spot check, the letter had a large red "Customs - Hold" sticker on it with an LAX flight number, so I assume they knew in advance what they were looking for. NZ Customs couldn't tell me why it was intercepted, but seemed a bit surprised that the letter had been opened. They said that they may have been "acting on information". In early October, about a fortnight after I sent the letter to MFAT questioning the export refusal and asking for clarification on what law they were using to block the export (and many months after the export itself), the Australian parent of the US company who wanted the export got a call from the Australian Ministry of Defence (it was actually the DSD, but they generally identify themselves as Ministry of Defence just like NSA employess are always identified as Department of Defence rather than NSA). This company, Kiss Audio Visual, are a video production house who have nothing at all to do with encryption software (or, in fact, anything but video production and graphics design, which they are very good at). They were called by Alan Owen of the DSD who said that they had been informed that NZ Customs had intercepted a shipment containing a high-security encryption product which was being illegally exported from New Zealand. According to the story, when NZ Customs went back to the party who exported the software, they claimed it was on behalf of Kiss. The Managing Director of Kiss called the Ministry of Defence to make sure this was actually for real, and they confirmed that it was. This story has several very large holes in it: - NZ Customs never intercepted anything. The package containing the disks arrived in the US unopened, there was no "high-security encryption product" on the disks, and a Customs person has verified that NZ Customs have never intercepted any crypto software shipped overseas. - There was no illegal export of any kind. All the necessary permissions had been obtained from MFAT before the disks were shipped. - The export was performed by Cyphercom, not Kiss. Kiss happens to be the parent company, but (apart from a few business discussions carried out over international phone links), there was no other connection between Kiss and Cyphercom. Alan said that this export had very serious consequences, and that they would be coming to Melbourne to talk to Kiss at 2pm the next day. The Kiss Director immediately called Cyphercom in the US, and they discussed having serious quantities of lawyers present at the meeting, and taking the whole story to the media. The visit was cancelled without any explanation. Who says governments never listen to their citizens? (The DSD side of the story is that they were rather busy that day and didn't have time to carry out their investigation). The implications of this are interesting. Despite the fact that MFAT had already (in effect) denied permission for the export, someone with the ability to listen in to international phone conversations had used discussions about the export to fabricate a story about NZ Customs with which the Australian government could harass Kiss, who had done nothing wrong and in fact had nothing to do with the whole affair (unfortunately I don't have any proof of the phone-conversation monitoring, but I can't see how anyone could possibly have connected Kiss with Cyphercom except for the phone conversations - they simply have nothing else in common). Apparently whoever was pulling the strings saw it necessary to bypass MFAT entirely in an attempt to suppress the encryption software (this does not inspire confidence in the working relationship between MFAT and the unnamed agency. The identity of the unnamed agency was later revealed by the DSD - see below). Also in October, an article "Trade in Strategic Goods - An Update" in MFAT's "Business File" publication, Vol.3, No.7 made specific mention that MFAT were in charge of controlling the export of encryption hardware and software. It's pretty certain that this special mention was motivated entirely by attempts to export cryptlib, because MFAT stated in a letter to me that they'd never encountered anything like this before, so the claim that: "..the most commonly affected exports from New Zealand are of encryption hardware and software..." is distinctly peculiar. The last time anyone checked (a KPMG report from mid-1994) NZ had no restrictions on the export of crypto. Some time between mid-94 and October 1996, export controls (or at least some vague mention of controls) appeared, with MFAT having jurisdiction. I suspect this was in October 1996, *after* the whole export/non-export fiasco took place. In any event the article contains some rather curious comments. "Run-of-the mill exports have usually been processed within 48 hours". MFAT have now taken 9 months without showing any results, causing considerable financial hardship for Cyphercom who are unable to ship a product or even obtain a sample copy for demonstration to customers. "New Zealand... is helping to limit the spread of increasingly sophisticated military technology and weapons of mass destruction". Whether software to protect financial transactions and medical records counts as "sophisticated military technology" or "weapons of mass destruction" is unclear. In late October I called MFAT to see what the delay was in replying to my earlier letter, and received a reply the following week. In their reply, MFAT stated that the export (non-)permit was in fact not final, and was still under consideration, which was at odds with what they had told Cyphercom and with the wording of the permit itself (see above). The letter also states: "We made it clear that it would take some time, as the application dealt with a relatively new area in terms of our export controls, and was in a rapidly changing and advancing field. We... are currently discussing it and other issues it raises with relevant government departments". (the "relevant government department" is the GCSB, this has been confirmed by the DSD). I interpret this paragraph to mean "We're making up the rules as we go along". The Canadian government certainly didn't seem to have any of these problems when they covered the same issue. MFAT declined to answer my question as to whether this portion of NZ's foreign trade policy was being controlled by US intelligence agencies. In early January 1997, Kiss were informed by the same Ministry of Defence/DSD person (Alan Owen) that he and an associate would again be flying in from Canberra to talk to them, using as justification the same fictitious story about NZ Customs that they had used before. They spent about two hours at Kiss, saw that they were indeed a video production house (and nothing but a video production house), and left. Before they left, they told the Kiss people that the source of the story about NZ Customs was "their counterparts in NZ" (the GCSB). Kiss had a lawyer present to witness this. The implications of this are pretty scary. The GCSB first used their position to impose impossible-to-meet conditions on Orion and influence MFAT to indefinitely delay export of software which isn't export-restricted anyway (or at least not by any known NZ law) and which the Canadian government had already ruled wasn't export restricted. However, not content with this, they then fed a fictitious story to the Australian government to convince them to begin an investigation into a company which had done nothing wrong, and had very little to do with the whole issue. Foreign competitors of NZ companies will ship their encryption products within 15 minutes of a credit card order being received. The GCSB, by employing all sorts of devious measures, has managed to suppress distribution of the same software by NZ individuals and companies. Under their influence, MFAT have now spent nine solid months brooding over the export of one single copy of equivalent encryption software without showing any results. This has had the effect of protecting overseas markets for exploitation by foreign competitors... by a ministry supposed to be in charge of promoting NZ trade. To summarise, the situation is as follows: 1.There is absolutely no way that anyone could reasonably be expected to find out about what to do with crypto software in New Zealand. NZ Customs have been extremely helpful throughout this affair, but had to keep deferring to MFAT, where everything stops. Even the people charged with enforcing export conditions don't know what it is they're supposed to be enforcing. If it wasn't for a number of lucky coincidences and occasionally knowing or running into the right people, I still wouldn't know any more about the situation. 2.Anyone trying to follow the vaguely-defined, possibly nonexistant rules, at least in New Zealand, is opening themselves up to government harassment, no matter how hard they try to follow whatever rules and regulations someone in the government comes up with. The only safe way to distribute crypto software seems to be to either distribute it over the Internet, or to make sure you have enough media and political contacts to raise hell over any ensuing mail interception, possible phone tapping, government investigations, bogus stories about crimes being committed, and other niceties which may crop up.

1 0

Re: I beg you, PLEASE prove that 0.123456789101112131415 is IRRATIONAL (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > One can construct the reals from the rationals quite easily using any > of several well-known methods, such as equivalence classes of Cauchy > sequences, or Dedikind cuts. So you are saying that the Reals are a subset (ie can be constructed from) of the Rationals? I can create a number which is not representable by the ratio of two integers from two numbers which are representable by ratios of two integers? That's a nifty trick indeed, I am really impressed. Cauchy produced a test for testing convergence. I fail to see the relevance here, but please expound... Dedekind Cut: "Thus a nested sequence of rational intervals give rise to a seperation of all rational numbers into three classes." Just exactly where does this allow us to create Reals? Jim Choate CyberTects ravage(a)ssz.com

1 0

Re: I beg you, PLEASE prove that 0.123456789101112131415 is IRRATIONAL
by Sir Robin of Locksley 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >Dear Cypher Punks, > >I BEG YOU TO HELP ME!!! > >Is it possible to prove that number 0.1234567891011121314151617181920... >iz irrational? Most definately. All you need to do is prove that the set of this number is uncountable, ergo is irrational. If you have friend who have done math in real analysis they can explain more. > >Or may be it is rational? > >Also, another question for math geniuses here: > >Is it REALLY true that there are real numbers that cannot be generated >by any algorithm? Some guy said that since the set of algorithms is >countable, but the set of real numbers is more than countable, there >must be some numbers for which there is no algorithms that generate them. If you show me an algorythm that calculates the real number TT (=3.14.....) I'll give you a Nobel Prize personally! > >But I still do not believe him. > >Also, is it true that the sequence of digits in e is random because the ONLY way to get to the >p'th digit is to calculate the p-1'st digits? > Exactly! This is called recursive definition. To get the p-th set in the sequence you need to find p-1 first... >Also, is it the correct definition of a real number: > >``A real number is the class of numbers which can represent the length of >an arbitrary line.'' Well, that is not entirely true... The length of any arbitrary line can be any number, rational, natural, etc. Real numbers are the numbers that defy all other categorization (they are not rational, irrational, natural, etc.) They are complex and despite any instinctual perception, there are a lot of them! I don't know if these maed a lot of sense but all of these questions are answered in a good Elementary Real Analysis book. > > >I AM REAL DESPERATE FOR YOUR ASS ISTANCE. Sincerely, Gabe -----BEGIN PGP SIGNATURE----- Version: 4.5 iQEVAgUBMuJmYqr5aWnB1HshAQH2bwf+O/C0vRosJAclWr9OhYufFtSYnGohHjnA hwbcb6wftvrRES4HyMu9GfCYZanZ37TI4erblofctiJh7RVgFmvJxK0VDbaSth8J Ns0u/c86dw6qSeE8XG+1LBQ9hH8eXJ4Mojnohea4L9IesjfqugZwh6+g/1BXngco wpOnhixj9Xxoh8Bu/N01rNtaCOcDQPziCYWg3iKTIJ0ySP0zZBPoamVq7OYAhXzY +sn5lABFZ81/VQf0Y/7drWnZhBDpJXq7xtbo4NZGkDbQ6ifNaH9AlF9+9vLJn6AS osG5SsS2TmeJLmpi3BxC0k1cNHGHI7+DGazRVMrtCZFFMeeh5RtRgQ== =ZAZJ -----END PGP SIGNATURE----- --------------------------------------------------- | Gabor K. Tozser | 1500 St. Olaf Ave. | | St. Olaf College | Northfield, MN 55057 | ---------------------------------------------------

3 2

Re: [STEGO] Sphere packings
by nobody＠huge.cajones.com 17 Dec '03

17 Dec '03

Tim C. May will fuck anything that moves, but he'd rather be fucking his own mother's dead body. \|/ (*,*) Tim C. May _m_-_m_

4 3

GSM technology
by azur＠netcom.com 17 Dec '03

17 Dec '03

GSM DATA FEATURES GSM is particularly suited for mobile data communications. All GSM base systems support 9.6kbit/s circuit-switched data services, soon many will increase transmission speed up to 28.8kbit/s. A new part of the GSM standard, known as High Speed Circuit Switched Data (HSCSD), is being developed which will boost user capacity up to 64 kbit/s, and higher. Interconnecting this 64 kbit/s wireless capability with public ISDN networks, for example, will give mobile users complete end-to-end digital connectivity with the attendant benefits of very fast set-up times and high link quality. Technically, HSCSD requires a new radio link protocol; a modification of the existing protocol used to provide the GSM voice channel. GSM uses TDMA (Time Division Multiple Access) technology, which divides each 200 kHz carrier into eight timeslots. To provide a single voice channel, one timeslot is used; one timeslot is also used to provide a single 9.6 kbit/s data circuit. However, all eight slots will be used to provide one 64 kbit/s circuit. The main benefit of this approach is that it is designed for the existing GSM infra-structure. There is no need for operators to change their entire network infrastructure in order to implement it. Operators will therefore be able to implement HSCSD in a quick and efficient way, once the specification has been ratified. ENCRYPTED GSM LINKS If the GSM phone includes a data port, as some already do, just connect your laptop, dial your ISP and 'push' the encrypted traffic over that link (e.g., using TCP/IP and PGPfone). REFERENCES If you really want to dive headfirst into GSM, the following is a resource list generated in 1994: @article(rahn, author = {Rahnema, Moe}, title = "Overview of the {GSM} System and Protocol Architecture", journal = {IEEE Communications Magazine}, month = {April}, year = 1993) @incollection(chee, author = {Cheeseman, David}, title = "The pan-{European} cellular mobile radio system", booktitle = {Personal and Mobile Radio Systems}, editor = {R.C.V. Macario}, publisher = {Peter Peregrinus}, address = {London}, year = 1991) @incollection(bals1, author = {Balston, David M.}, title = "The pan-{European} cellular technology", booktitle = {Personal and Mobile Radio Systems}, editor = {R.C.V. Macario}, publisher = {Peter Peregrinus}, address = {London}, year = 1991) @article(moha, author = {Mohan, Seshadri and Jain, Ravi}, title = "Two User Location Strategies for Personal Communication Services", journal = {IEEE Personal Communications}, volume = 1, number = 1, year = 1994) @inproceedings(haug, author = {Haug, Thomas}, title = "Overview of the {GSM} Project", booktitle = {EUROCON 88}, month = {June}, year = 1988) @inproceedings(mall, author = {Mallinder, Bernard J. T.}, title = "Specification Methodology Applied to the {GSM} System", booktitle = {EUROCON 88}, month = {June}, year = 1988) @inproceedings(aude, author = {Audestad, Jan A.}, title = "Network Aspects of the {GSM} System", booktitle = {EUROCON 88}, month = {June}, year = 1988) @incollection(bals2, author = {Balston, D. M.}, title = "The pan-{European} System: {GSM}", booktitle = {Cellular Radio Systems}, editor = {Balston, D. M. and Macario, R.C.V.}, publisher = {Artech House}, address = {Boston}, year = 1993) @incollection(wats, author = {Watson, C.}, title = "Radio Equipment for {GSM}", booktitle = {Cellular Radio Systems}, editor = {Balston, D. M. and Macario, R.C.V.}, publisher = {Artech House}, address = {Boston}, year = 1993) @incollection(harr1, author = {Harris, I.}, title = "Data in the {GSM} Cellular Network", booktitle = {Cellular Radio Systems}, editor = {Balston, D. M. and Macario, R.C.V.}, publisher = {Artech House}, address = {Boston}, year = 1993) @incollection(harr2, author = {Harris, I.}, title = "Facsimile over Cellular Radio", booktitle = {Cellular Radio Systems}, editor = {Balston, D. M. and Macario, R.C.V.}, publisher = {Artech House}, address = {Boston}, year = 1993) @article(dech, author = {D\'echaux, C. and Scheller, R.}, title = "What are {GSM} and {DCS}", journal = {Electrical Communication}, month = {2nd Quarter}, year = 1993) @article(feld, author = {Feldmann, M. and Rissen, J. P.}, title = "{GSM} Network Systems and Overall System Integration", journal = {Electrical Communication}, month = {2nd Quarter}, year = 1993) @article(bezl, author = {Bezler, M. and others}, title = "{GSM} Base Station System", journal = {Electrical Communication}, month = {2nd Quarter}, year = 1993) @article(schm, author = {Schmid, E. H. and K\"ahler, M.}, title = "{GSM} Operation and Maintenance", journal = {Electrical Communication}, month = {2nd Quarter}, year = 1993) @article(lobe, author = {Lobensommer, Hans and Mahner, Helmut}, title = "{GSM} -- a {European} Mobile Radio Standard for the World Market", journal = {Telcom Report International}, volume = 15, number = {3-4}, year = 1992) @article(hube, author = {Huber, Josef--Franz}, title = "Advanced Equipment for an Advanced Network", journal = {Telcom Report International}, volume = 15, number = {3-4}, year = 1992) @book(winc, author = {Winch, Robert G.}, title = "Telecommunication Transmission Systems", publisher = {McGraw-Hill}, address = {New York}, year = 1993) @inproceedings(natv, author = {Natvig, Jon E. and Hansen, Stein and de Brito, Jorge}, title = "Speech Processing in the pan-{European} Digital Mobile Radio System ({GSM}) --- System Overview", booktitle = {IEEE GLOBECOM 1989}, month = {November}, year = 1989) @inproceedings(vary, author = {Vary, P. and others}, title = "Speech Codec for the {European} Mobile Radio System", booktitle = {IEEE GLOBECOM 1989}, month = {November}, year = 1989) @inproceedings(sout, author = {Southcott, C. B. and others}, title = "Voice Control of the pan-{European} Digital Mobile Radio System", booktitle = {IEEE GLOBECOM 1989}, month = {November}, year = 1989) @unpublished(nils, author = {Nilsson, Torbjorn}, title = "Toward a New Era in Mobile Communications", note = {http://193.78.100.33/ (Ericsson WWW server)}) PGP Fingerprint: FE 90 1A 95 9D EA 8D 61 81 2E CC A9 A4 4A FB A9 --------------------------------------------------------------------- Steve Schear (N7ZEZ) | Internet: azur(a)netcom.com Lamarr Labs | Voice: 1-702-658-2654 7075 West Gowan Road | Fax: 1-702-658-2673 Suite 2148 | Las Vegas, NV 89129 | --------------------------------------------------------------------- Internet, electronic currency and wireless development 1935 will go down in history! For the first time a civilized nation has full gun registration! Our streets will be safer, our police more efficient, and the world will follow our lead in the future! --Adolf Hitler

3 2

RE: Newt's phone calls
by Internaut 17 Dec '03

17 Dec '03

>What does concern me is personal privacy. I don't want people tracking >my movements or purchasing patterns, so I prefer to use cash or >pseudonymous debit cards. How pseudonymous are debit cards? Don't they go through visa before they debit your account? --Internaut

8 18

Re: Dr. Vulis' social engineering experiment
by ichudov＠algebra.com 17 Dec '03

17 Dec '03

Jane Jefferson wrote: > > The heart and soul of the problem is that "sin", "freedom", "good", > and "evil" are abstract concepts which fluctuate from individual to > individual. An excellent point, Jane. Worth remembering. - Igor.

1 0

Re: Thoughts re moderation, filtering, and name changes
by ichudov＠algebra.com 17 Dec '03

17 Dec '03

[Cc: alex(a)agate.net] Dale Thorn wrote: > > Many credible and respected authors and commentators have made references > to the masses in one form or another as "stupid, lazy, ignorant, > selfish, etc.", or even "almost useless". > In the classical example, you should say "LYING, FUCKING, THIEVING, STUPID," and so on. The art of insults has developed somewhat. Alexplore is one of the best masters after Dr. Vulis (some would say even better than Dr. Vulis, but that depends on taste). if you do not get it, it is because you need to know the context... - Igor.

1 0

Arkansas Phone Scramblers, etc.
by John C. Randolph 17 Dec '03

17 Dec '03

I just had an interesting exchange with the latest person to take up residence in my bozo filter. I get this message from some clown I've never heard of, sent from AOL, saying that he wants one of these Radio Shack scrambler frobs, and hinting that he'd be willing to pay lots for it. I sent him back a note pointing out, among other things, that I don't know him, he doesn't know me, and that we're talking about buying and selling a frob that at least one set of JBT's doesn't think he should have. I concluded by telling him that I wouldn't sell him one if I had one, that I wouldn't tell him whether I had one, and that if he wants to have a private conversation with someone, he should just get a copy of PGP phone, like everyone else. He sent me a huffy note, saying I'd better learn some diplomacy. So, what do you think guys? Did I just piss off some federal prosecutor who was hoping to body-grab me to a clueless jusrisdiction like Arkansas to try me for crypto-terrorism, or did I piss off another fucking AOL'er? Amused and Torqued at the same time, -jcr

1 0

Re: Airport security [no such thing]
by Adam philipp 17 Dec '03

17 Dec '03

At 09:23 PM 1/20/97 -0500, you wrote: > Recall that all security is economics. The airlines want the >appearance of security without having to pay for it. > > The '3 questions' ("Pack your luggage? let it out of your >sight? Taking any gifts?") originated with El Al, where they are the >introduction to a very expensive (and privacy invading) set of >screening questions. The El Al people are trained to watch you as >they ask the questions, and respond to signs of lying or rehersal. >The Americans read the questions off the screen, and pay no attention >to your answers. True, however the number of questions asked by El Al decreases amazingly when you answer in Hebrew, however that did not stop me being addressed by five security personnel after a trip where had been doing a photo documentary and was still wearing a photo vest full of black metal cannisters (lenses). Of course when the security head finally approached me I used Hebrew and that was then end of the episode. Unfortunately speaking English is not a very good determination of airline safety. Adam Esq. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\ | My PGP key is available on my |Unauthorized interception violates | | home page: http://www.rosa.com |federal law (18 USC Section 2700 et| |=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-|seq.). In any case, PGP encrypted | |SUB ROSA...see home page... |communications are preferred for | | -=[ FUCK THE CDA]=- |sensitive materials. | \=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-/ If A is a success in life, then A = x + y + z. Work is x; y is play; and z is keeping your mouth shut. Albert Einstein (1879-1955)

1 0