- cypherpunks-legacy - lists.cpunks.org

Re: Warning about Pegasus Mail and PGP (fwd)
by Jeff Hupp 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- On 10 Dec 95 at 12:30, Anonymous wrote: : On 9 Dec 95 at 21:43, Jeff Hupp wrote: : : > On 9 Dec 95 at 18:29, Siberia wrote: : : > : Okay, here's how I understand things with PGP and Pegasus. : > : You have two options with Pegasus depending on the set-up : > : options you choose. You can either send upon completion of : > : your out-going email, or you can have your mail queued : > : until you press the send out-going mail button. The actual : > : PGP process does not occur until you actually send the : > : mail. So the answer would be: don't queue your mail. : : > That's not really a solution in the Windows environment, if : > you have a swap file, you never know what gets written out : > to it. The solution is run w/o a swap file or run an : > encrypted file system. I run an encrypted file system. : : Oh, PLEASE! Do you HAVE to go and mix up two completely : different issues? Aren't the nontechnical people trying to : follow these things likely to be confused enough without your : adding to that confusion? For every person who really : understands the technical issues there are probably a thousand : or ten thousand who are just trying to *use* the stuff without : stepping into a deep hole. : : An OS swap file is one kind of hole. What Siberia is writing : about is ANOTHER type of hole. If I wipe my swap file after : each use of my machine and don't know that Pegasus is doing : this, or think that because of what you wrote I'm no worse off, : I've been done a serious disservice.] So, I shouldn't take the opportunity to tell those non-technical people about the other "hole" they most likely have? After all this only effects Windows users and it is a problem with windows. Read what I wrote, I did not say the original post was in error about not queuing mail and saw no reason to repeat what appears to be a fact. And, if the non technical people don't know about the swap file problem, and just assume that if they don't queue mail they are no worse off then they have been don a serious disservice. BTY, did you check it out? Or just take what you saw as an opportunity to rant? : : > Pegasus will indeed save your key with your message in the : > outgoing queue. This is a problem with the design of : > pegasus, not with the design of the add on encryptor. : : How about saying something USEFUL, like yes or no to the : question of whether sending WITHOUT queueing will make any : difference? How about agreeing that if David Harris hopes to : provide a useful interface to external "encryptors" he will : have to do something about this? How about cc'ing David? : : Somebody else could as well point out that we're all full of : crap because we don't use Amigas, and while he might have a : point, it wouldn't be a very useful one. : Yes, it would have been a WONDERFUL opportunity to drop a O/S v. O/S troll on the list, notice I didn't. What I did do, was write up a problem description and mail it to David Harris. This based on the likelyhood that he doesn't read cypherpunks. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMMrgqTUjeCeeebC9AQG3gwf/VdD9J/KJ1Tau3/L8BLoZ1v6ACAc93zcP 4F1MDoeX7EMSjWqGFZvsh0ev9hgciXvId9lu7tfMqIXQdolHzjXiyPXaw3qEa1Id A80j+Z7OKB9RSz9LKHQqjrrqpANDbJ16LIztYW5r9YjMSntWX9OF7MzeZ0BJRYc4 d1oWnhHqnF6K9rX2XWDveXyQJgCnu2sZw6nNXi0V61OdhBc/QmPsjBp+u7aig+i8 vdC7EJh2znKsNqlQqiJmHnfTbGuoVZGQkc/71hpD2reLzcU7W/NQwM7rL4PFGyDg QA15LXcfKsp6p0JCdZc+bvUfpH5mQQFWm4kd6sY7knjO3fKuTc7jpg== =Li0A -----END PGP SIGNATURE----- -- JHupp(a)gensys.com |For PGP Public Key: http://gensys.com |finger jhupp(a)gensys.com A generation which ignores history has no past - and no future.

1 0

Re: More FUD from First Virtual
by Ed Carp 17 Dec '03

17 Dec '03

> From: Adam Shostack <adam(a)homeport.org> > Subject: Re: More FUD from First Virtual > To: jimbell(a)pacifier.com (jim bell) > Date: Sat, 9 Dec 1995 16:51:58 -0500 (EST) > Cc: cypherpunks(a)toad.com > jim bell wrote: > > [Good points about cost of transactions deleted] > > | The answer, I think, it that there would be no problem finding people to > | take that risk in exchange for the return, ESPECIALLY if they have some > | input into the design (level of security) of the system. They might insist > | on 2048-bit RSA keys, instead of 1024-bit, for example. > > (I know its only an example, but...) > > Key length is not what is needed for better security; more > solid code and better interfaces are needed. (I might also argue for > hardware keys that are more difficult to steal..) Nonsense. The code is pretty solid, the interfaces aren't very difficult. What is needed is better human management of keys. Why brute-force, why look for weak keys, why bother calculating how much safer 2047-bit keys are rather than 1024-bit keys when someone can look on your HD and find your secret key, when they can open your desk drawer and find your pass phrase or password, when they can guess that you used your wife's maiden name as your password? Adam, I don't understand why you wrote nonsense in the first paragraph, then followed it up with textbook attacks such as: > Cryptosystems fail because of bad storage of keys, coding > mistakes, accidentally writing passphrases to disk during a swap, etc. > Moving to 2048 bit keys is no help if you lose the key to a > non-cryptanalytic attack. Moving to keys with a week or day lifetimes > might be better. Moving the systems which automatically issue key revocation certificates, and coupling that with a wide distribution system would be the perfect match to such a scheme. Of course, that means that PGP et. al. needs to be more tightly integrated into existing mail software.

2 1

Re: Free calls to Govt (fwd)
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

I've been told that number is out of date. Since I forgot to save it, would someone who did check and find out? Thanks, -Allen

1 0

NSA rigs Crypto machines according to Balto Sun
by pcw＠access.digex.net 17 Dec '03

17 Dec '03

Most of us might believe that the holes in Netscape's encryption software were simply the result of sloppy engineering. That was the public story. A story from today's Baltimore Sun (Sunday December 10, 1995) gives more reasons to be paranoid. The Baltimore Sun has been running a long series of articles on the National Security Agency. Some of the earlier ones have been largely positive and filled with stories of intelligence coups. Today's story, describes several reasons why one might believe that the NSA was party to a plan to rig the machines of the Swiss company, Crypto AG, so that the messages could be read by those who knew the game. Crypto AG sells its machines to other countries around the world who believe that the Swiss are neutral vendors of superior technology that wouldn't have such holes. The clearest link, in my mind, was the minutes from a design meeting at Crypto AG which was attended by an NSA cryptographer, Nora Mackebee. (She is now 55, retired and living at what the Sun calls a "Howard County horse farm.") But there are reasons to wonder about this link. Motorola was also part of the list. Also one employee got in a legal battle after being fired. The details were settled a few days before company engineers were scheduled to testify "that they believed the machines were altered." More anecdotal evidence was offered by someone who is listed as a "longtime colleague" of Dr. Kjell Ove Widman, the Swedish mathematician who "had total authority over Crypto algorithms." The colleague said that Widman would often travel to Germany and then return with design instructions. The impression was given that Crypto could only use an algorithm if it was approved. But approval is not, in my mind, proof of a secret attempt to read messages. I believe that the NSA probably did more to strengthen DES than weaken it during the classified design process at IBM. But I only have the work of Biham and Shamir to base these conclusions upon. Perhaps the machines were altered to make them stronger for western firms using them? The Mackabee meeting occured in 1975 during the height of the Cold War. The Soviets were grabbing Western technology left and right. Of course, the Sun also reports that Crypto AG "denied that intelligence agenies had ever rigged its machines." (The words in quote are the Sun's not Crypto AG's. ) So, is this what happened at Crypto AG? Is this what happened at Netscape? We may never no for certain, but there is a final warning for the folks at Netscape that is buried the Sun's article about Crypto AG: "Meanwhile, though the company has hastened to reassure its customers, business has declined and employees have been laid off." -=-=-=-=- There are two more articles in the series. Tuesday's will report that "Trolling for foreign secrets, NSA routinely picks up Americans' overseas calls. And it's legal." On Friday, the article reports, "The next war will be fought with computers. NSA is getting ready." You will be able to buy a reprint of the NSA stories from SunSource. $3.95. Call 410-332-6962.

2 1

Is it possible?
by Laszlo Vecsey 17 Dec '03

17 Dec '03

Suppose I have the source of a C program that I would like to distribute on the Internet. This program computes some data (perhaps attempting to to do a partial brute force) and sends it's results to a server. The problem is someone might modify the source to simply contact the server saying "ok, my part of the brute force failed" and not even do anything. How can I be sure that the source has not been modified from the original distribution before it is compiled? My original plan was to compute many digits of PI using the new Plouffe formula (allows you to compute any Hex digit of PI in linear time) but perhaps trying to brute force things in this way isn't such a bad idea.

2 1

NIST GAK meeting writeup, LONG part 3 of 3
by pfarrell＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- NIST Key Export meeting, December 5, 1995 Long version Part 3 of 3. This covers the notes on agent criteria, and the industry presentations. Part 2 of three hasn't been written, it is supposed to address the issues related to interoperability. I decided it was better to get this part out than to wait. Items on the criteria themselves that I think were under reported in my first reports: Ed Appel: the LEAs are very interested in Criteria #5 (two ended decryption) as they have more than 100 international offices. Miles Smid described a trick for meeting Criteria #5, if you encrypt the session key with your own public key, in addition to the key of your destination, and if you have escrowed your private key with an Escrow Agent, then nearly any approach meets criteria #5. ********* On agent criteria: ********* Geoff G. says that the discussions on agent criteria are simply a follow-on to the main criteria #3. The criteria themselves have been spam'd to the list. They are also available at url: <a href="http:/www.isse.gmu.edu/~pfarrell/nist/escagent.html"> There was a lot of reactions to the SECRET clearance requirement, which they claimed was to handle secure investigations (e.g. FISA). This has already been discussed on the list, so I'll skip it here. David Lesher asked a series of questions concerning the requirement that the Key Escrow Entity employ a person with a SECRET clearance. They included: what agency will issue the clearance? Who will authorize for the BI (background investigation)? Who will pay for it? Who does the existing RBOC clearances? Geoff dodged nearly all of them. He acknowledged that "they" will have to pay, but made no effort to define who "they" are. Geoff said that they may want legislation support for protecting against illegal release of keys, failure to release, etc. A fair number of the agent criteria would be considered professional business practice (no single point of failure, dual locations, etc.) if you thought that escrowing keys was a good thing. ********* User/Industry presentations Bill Sweet of TIS Bill gave a presentation about his CKE product, and how hard he is working to "find a global solution." This is actually the same product that Bill talked about in September when he worked for National Semiconductor. It was impressive then (private keys are NOT escrowed, only session keys, etc.) and is still not approved for export. Bill talked about "information owners," they ultimately decide which security systems get deployed "in spite of various government requirements around the world." He said that "if rational key escrow systems are not offered, or do not adequately protect their information, owners will use unescrowed encryption from whatever sources available (Germany, et al)." Bill talked about a UK University (Royal Holloway) study on UK/European needs for key escrow. He said that there was a lot of overlap with the NIST criteria, but that there were criteria that were judged as totally unacceptable. The first and loudest finding was: "the use of the scheme should provide visible benefits to the user." This begs the obvious question, what visible benefits to the user does GAK bring? Two other interesting findings in the study were: - - An entity with a warrant should not be able to fabricate false evidence." - - Abuse by either side should be detectable by the other. He suggested that these criteria be added to the NIST list of 10. Bill went on to look at the NIST criteria. He said, concerning Criteria #3 (agents certified by US Government or reciprocal agreement), that "this is a show stopper!" because: - -- no reciprocal agreements exist today, anywhere. - -- what about countries where justice systems are different, and what about where "these agreements are not desirable (e.g. Nigeria, Mexico, Saudi Arabia, Argentina, Poland, etc.)? - -- even for NATO countries, agreements will be different (Germany has data privacy laws, in Greece), or we may not want to be reciprocal (in Greece, the government likes to bug the opposition) He also says that Criteria #7, 64-bit keys, is unacceptable. CE Infosys currently sells a PCMCIA (PC Card) encryptor that does triple-DES at T1 speeds. TIS uses it, and sells it in the US. [as an aside, I was told that they can import and resell them, but when one breaks, TIS cant ship it back to Germany for repairs. Sigh.] Sweet had two recommendations: - -- develop a tiered crypto policy, with hardware and software under differing levels of rules, - -- allow a pilot project, where TIS can sell VPN (virtual private networks) using strong encryption. A VPN is the use of the Internet as a private network for a corporation by adding appropriate firewalls, encryption, etc. It seems to me that while TIS' CKE doesn't meet the criteria, it could be made to, with a few changes. They've have to change the design to allow GAK for any one target. (Criteria #5) This would mean for generating one DRF (ie., LEEF) for each recipient as well as for the sender (as opposed to just for the sender) The neat thing about CKE is that each LEEF holds only the session key -- so you never give away your private key. (I think the govenment really expects that we'll be willing to escrow our private keys. Fat chance!) But this is a bit of a catch 22, because to follow all the criteria, you can't stop there. - -- For each encryption, you generate a DRF for the sender and each recipient - -- For each DRF generated, you must have and check a certificate chain for the chosen DRC and refuse to encrypt unless all recipients and the sender have validly certified (ie., USGovt approved) DRC public keys. - -- Each receiving application must refuse to decrypt unless every other recipient and the sender have validly certified DRC public keys. This gets into the interoperability issues that I need to write up... - -- I don't know how they can meet the revised #6. It seems to be designed specifically to break CKE. To get govie approval, each DRC needs to meet all the key escrow agent entity criteria. I'm really not at all convinced that it is actually practical. This is sad, because CKE is obviously designed with the spirit of the government at heart, with just some modifications to make it marketable. Guess TIS needs an Ireland office too. Ken Mendelson of TIS Ken gave a solid presentation describing how all of the Governments need for data about key escrow agents could be met with a commercial "vendor registration" approach instead of a Government mandated "certification" scheme. This would be in keeping with the current "spend less money, have less government bureaucratic rules" political climate. I have copies of his slides, Id rather not type them in. With any luck, hell put them up on the TIS web site url: http://www.tis.com Dorothy Denning of Georgetown University Dorothy Denning gave a presentation on an article that will be published in the March 96 Communications of the ACM. It analyzes currently available products (and vapor products) and sees how well they meet Criteria #5. It says that eight of the sixteen approaches that she surveyed currently meet Criteria #5. She lists her web page as http://www.cosc.georgetown.edu/~denning, but as of Sunday 12/10, the text is not available. Melanie Janin, US Council for International Business Ms. Janins speech presented the US Council for International Business comments on GAK. They are a NY based trade group, representing 300 clients. They dont like GAK. She called for a coherent policy on all encryption. Major topics in the presentation include: - - free choice - - open to the public - - international acceptance - - flexibility of implementation - - User key management - - Key escrow (where they "embrace key escrow as one possible method of managing encryption keys.") - - Liability Ed Scheidt, Tecsec Presented both comments on the criteria and his companys VEIL and Export VEIL Version 2.0 products. He raised a number of points, including: - - how do we protect our commercial information unless we have the best cryptography? - - we need "constructive key management technology" to manage keys, key splits, and different algorithms for extended data separation. - - solution must address issues such as international trust in a key escrow. He said that his "Export VEIL 2.0" product meets "the intent of 11/95 export criteria today." Daniel Weitzner of CDT Mr. Weitzner agreed to shorten his presentation so that he could yield some time to VTW. He opened by pointing out that while the schedule had both him and Jerry Berman were supposed to talk, Jerry was too busy to make the meeting. "Jerry is out defending pornographers, so Ill be here defending terrorists." I expect that his text will be on CDTs webpage, url: http://www.cdt.org. Ill just enter the key points. The first thing he said is that "this is the wrong forum" and that "the [NIST] process will not work." He proposed a open, privately sponsored forum to develop alternatives that will work. "The NIST proposal will not provide adequate security, privacy, promote secure communications worldwide, or guarantee user privacy." Major issues are: - - Inadequate security - - No viable policy framework for the long-term - - Hinders the deployment of globally interoperable secure systems - - not necessarily voluntary - - not viable in the marketplace - - no constitutional privacy protections - - will not meet the needs of law enforcement, since it will "not deny criminals or terrorists access to strong encryption, the stated objective of the policy." Shaber Safdar, Voters Telecommunication Watch Described the results of an Internet-based, non- scientific survey that the VTW recently made. Not surprisingly, those who replied were overwhelmingly against the NIST proposal. I dont have the slides, but VTW has a website with most of their information. The url is http://www.vtw.org There were 26 respondents to the survey. 24 out of 26 said that they would never buy products with law enforcement access. 16 out of 24 are already using security products. He described a Technology Pledge that VTW is presenting to politicians (available at url: http://www.vtw.org/pledge/) and stated that Rep. Ronald Wyden (D-OR) signed the pledge with pro- freedom, pro-market answers. David Sobol, EPIC As expected, EPIC doesnt like much about the NIST proposal. Their comments are on their web page, url: http://www.epic.org/crypto/EPIC_Statement.html A key statement is "Given the reality that users are unlikely to adopt key escrow systems on a voluntary basis, we believe that the current policy will result in the eventual prohibition of non-escrowed products. Indeed, documents released to EPIC under the Freedom of Information Act (FOIA) reveal that NSA and FBI concluded nearly three years ago that Technological solutions such as they are, will only work if they are incorporated into all encryption products." Major points - --Public comment is frequently solicited but never heeded. - --Relevant information has not been released. - --The proposal conceals the attempt to expand wiretapping capability As a result, EPIC proposes the following Policy Recommendations - --Relax export controls on encryption and permit the free flow of encryption products across national borders - --Withdraw FIPS 185 (the Clipper standard for voice, fax,... and low speed data networks in the federal government) - --Remove "cryptology" from items that may be classified ... under executive order - --Do not fund the Telephone Carrier Compliance Program (the "Digital Telephony" proposal) - --Do not permit the use of classified algorithms for public networks - --Examine the activities of the National Security Agency ... since passage of the Computer Security Act of 1987. NOTE: during Mr. Sobels discussion, a FBI representative sitting at the head table said that the issues addressed by key escrow are "not just wiretapping, they include search and seizure of all stored media." I was not able to identify the person. He was sitting at Ed Appels seat, but did not have a namecard. No one sitting near me recognized him either. Padgett Petersen, Lockheed Martin Noted Internet personality, Padgett Petersen took a rarely held position, he spoke as a Security officer of Lockheed Martin, rather than speaking as a private net-citizen. He said that "these criteria are acceptable and can be made to work." He also said that "without US agreements, there is no reason to be concerned with export." Lockheed Martin was looking forward to participating in using and buying the escrowed products that will hit the market as a result of this process. Robert Hollyman, Business Software Alliance Mr. Hollyman said that "the facts are clear, companies are unanimous against" the NIST proposal. His members agree that: - - security is critical - - 40 bit is not viable - - the 1992 government review requires a change in policy. He recommended: - -- immediate approval of DES or equal strength alternative for export. - -- encourage companies to build encryption software by submitting code to NIST (under non-disclosure) for review - -- add two bits ever three years to allowable key lengths in recognition of Moores law. He called this a COCA allowance (cost of cracking algorithms). - -- removal of restrictions on interoperability because they are artificial and antithetical to the Global Information Infrastructure. He stated that the current criteria are vague, and will take years for approval. Yet he notes that in industry, the average life cycle of software is 18 months. Alex McIntosh, PC Security PC Security sells key management systems. Shell is a customer. He addresses a couple of areas that his commercial customers ask. The first question is "why encrypt?" He said that the answer is to protect confidential data. These data include email, PC files, and archival data. This leads to the obvious question, why use key management? The two separate answers are to have operational backup and to allow compliance with internal and external law enforcement. He said that he has a surprise for the NIST folks concerning key escrow agents. The corporate customer is the key escrow agent. Other key observations: - -- Companies, such as Shell, often do business in countries where they can not trust the government. - -- Shell handles over a million email messages a day. This defines engineering requirements for any system to meet. - -- Liability is a huge issue, and the amounts are huge. Geologic information, market strategies, etc. are worth staggering amounts of money. The "US Government can NOT cover Shells liabilities." Doug Miller, Software Publishers Association Mr. Miller said that his members need immediate relief from the current encryption export policies. "our members are poised, but cannot leap, because of the barriers that U.S. cryptographic policy continues to impose." He wants to be able to export 56-bit DES. His position paper says, "we believe the discussion should also include assessment of the exportability of products employing the DES algorithm. DES-strength (56-bit) products can compete with 179 foreign products (80 of which are software products) that employ DES. Liberalization of the export restrictions of software with encryption capabilities is essential if U.S. companies are to compete with strong, widely available non-escrowed products." Viktor Hampel, Hampel Consulting Proposed "a Consumer Protection Act for Digital Products to support electronic commerce and to control the increasing abuse and lack of security on the national information highways." A copy can be obtained from Hampel Consulting, 1515 Jefferson Davis Highway, Crystal Square Suite 913, Arlington VA 22202- 3312. In his remarks, Mr. Hampel said that trust is important between business. Business worries about issues as varied as what accountability is in the system and how much is the per minute interest on a billion dollar money transfer? These cause business to need solutions that NIST hasnt raised. He recommended that a public key infrastructure be included into the Uniform Commercial Code. Closing comments. Mike Nelson noted that the meeting had some time for floor questions. He was asked what is the timeframe for finishing the process. He danced, saying that promising a fixed date for policy decisions is bad for your career, but thought it would be done in a couple of months. Someone asked about the "Personal Use" export process (the one that will allow you to export PGP on a laptop computer for personal use, and that was promised for "in a couple of weeks" at the September NIST meeting). They said that it is about to go to the Federal Register, and should be available within weeks. Nelson was asked about foreign escrow agents. He said that "if there exists bilateral diplomatic agreements, then the US will allow specification of Foreign Escrow agents." [Of course, no such agreements exist now.] Ed Appel of the White House said that the intent is to make export "as easy as 40-bit" is under the existing policies. The existing export policies will continue. He also said "so far, we are only controlling export" and that "the government has very strong cryptography available to them, so they are not worried about export." He said they hope to control export in two ways, first by applying the combined purchasing power of the US Government to encourage the market, and by controlling export. ********* After the meeting closed, I invited both Mike Nelson and Ed Appel to the next DC Cypherpunks meeting. Somehow I expect it when they declined. ******** A note on quoting within this document: I did not take a tape recorder to the meeting. Words in quotes were taken from either my hardcopy of handouts, words in documents on cited webpages, or from my noted. I tried hard to keep the words accurate and in context. There may be some cases where my quotes are incorrect. If I've misquoted anyone, it is not delibrate, and if told, I'll post corrections. Pat Copyright (c) 1995, Pat Farrell. Permission granted to electronically redistribute, provided it is transmitted in the whole and unaltered. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBMMsugLCsmOInW9opAQGWSAP/QC3Xja8kE56XGximmiiIVEv3ihJI1uY5 2eWZSVUGOxATc3jbwtLS5bqmkDnSXhQaaD6Slk/zA9IGlNhzi4tMV1xsrKwj4l4d 0KefEWOTinVze+6SQFsIVizGb9WzRaTrGwCV9RY7RRbC0dYa+cb21JXvlZOxYk/Q wGfkSY5/H0Y= =hJvT -----END PGP SIGNATURE----- Pat Farrell grad student http://www.isse.gmu.edu/students/pfarrell Infor. Systems and Software Engineering, George Mason University, Fairfax, VA PGP key available via finger or request #include standard.disclaimer

1 0

Free calls to Govt (fwd)
by Robert A. Hayden 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This is being forwarded from the ALA Intellectual Freedom mailing list. Thought it might be important here :-) - ---------- Forwarded message ---------- Date: Sun, 10 Dec 1995 09:59:48 -0500 From: Charles Willett <willett(a)AFN.ORG> To: Multiple recipients of list ALAOIF <ALAOIF(a)UICVM.CC.UIC.EDU> Subject: Free calls to Govt (fwd) - ---------- Forwarded message ---------- Date: Sat, 9 Dec 1995 14:31:58 -0700 From: El Tiburon <proteios(a)indirect.com> To: internet_censorship(a)monad.net Subject: Free calls to Govt 1) Dail 1-800-444-1555 2) They will give you a short recorded message. 3) Follow instructions if you have a touch tone phone, public ones work best and they have other advantages. :> 4) Enter a zip code...they ask for yours but it doesn't have to be...it can be any in the US. 5) Make a choice of the elected politician's office you want to be connected to. 6) When the staff person answers you are set to discuss the proposed environmental reform regulations, OR ANY OTHER ISSUE YOU WANT! Couple of tricks...we found they limit the number of calls to 3 from each number. Solution: public phones are everywhere...enjoy Exxon's corporate attempt to influence "grassroots democracy". M ______________________________________________________ Activism - Isnt it just participation? Internet Users Consortium 7031 E. Camelback Ste 102-515 Scottsdale, AZ 85251 IUC URL: http://www.indirect.com/www/molsen/ Proteios URL: http://www.indirect.com/www/proteios/ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Signed with PineSign 2.2 iQCVAwUBMMsZczokqlyVGmCFAQE+8AP7BkUKpHH06aC79T8P/J+YRF1AeMC/MB0W 2mEqED/zNhNF7pp2v0mUlRLpG6jrY0NRGip3JWZhRcdTwiMaVEWYNNHE6dUeklzO zm27/NxqKpi/e5ie+CsNwXKeket87+af8OZ8bzvIYg28pNcHAjnq5PLG62Oqsrxz 8E3QAHjAwc4= =l1BI -----END PGP SIGNATURE----- ____ Robert A. Hayden <=> hayden(a)krypton.mankato.msus.edu \ /__ Finger for Geek Code Info <=> Finger for PGP Public Key \/ / -=-=-=-=-=- -=-=-=-=-=- \/ http://krypton.mankato.msus.edu/~hayden/Welcome.html -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GED/J d-- s:++>: a-- C++(++++)$ ULUO++ P+>+++ L++ !E---- W+(---) N+++ o+ K+++ w+(---) O- M+$>++ V-- PS++(+++)>$ PE++(+)>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+ DI+++ D+++ G+++++>$ e++$>++++ h r-- y+** ------END GEEK CODE BLOCK------

1 0

Re: Warning about Pegasus Mail and PGP (fwd)
by Adam Hupp 17 Dec '03

17 Dec '03

Where can you get the Open Encryptor PGP interface? -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQBtAzCNppQAAAEDALhWZl7IuGZ9zZT5bACo0b/1L0Nv0C72vKHIO3IHh+cwpHHa 2Ozb9aeO0UvXGwkkZIYgUm0EvmzKh7yb1GTLvBp5kXpR3I9w+Yj4LGlBDERpUWw6 x4ED49pwDnz1Hl5FBQAFEbQYYXNoIDxhaHVwcEBwcmltZW5ldC5jb20+ =PtJK -----END PGP PUBLIC KEY BLOCK-----

1 0

What is AOL
by HyperReal-Anon 17 Dec '03

17 Dec '03

Twenty1CC(a)aol.com had these pearls of wisdom: >Found in rec.homor.funny.reruns Yes, you are quite a rerun, but you aren't funny. To answer your question, AOL is a haven for crackers, lamers, losers, fakers, and posers like yourself. You owe the Cypherpunks a video of your very violent and graphic death.

1 0

Re: GAK and self-incrimination?
by Greg Broiles 17 Dec '03

17 Dec '03

Ed Carp writes: > Greg Broiles writes: >> Tim May writes: >> >> >Consider this hypo: I send an encrypted message to a partner in crime >> >containing plans for future crimes and descriptions of past crimes. I >> >don't GAK the message. The government prosecutes me under the >> >Anti-Terrorism and Child Protection Act of 1997. >> > >> >My defense? That GAKKing the message would be tantamount to incriminating >> >myself, which the Fifth Amendment protects me against. > >> The Fifth protects you against *compelled* self-incrimination . . . In >> particular, you're free to simply not send the message at all. > >I don't believe that that would be a consideration. Wasn't there a >court case a few years ago, in which a convicted criminal sued the >government, charging that filling out one of those forms that you >have to fill out when you buy a gun was a violation of his 5th >amendment rights? What ever happened to that case? This sounds like _Haynes v. United States_ 390 US 85 (1968); the Supreme Court ruled that requiring registration of particular weapons (possession of which was illegal) violated the Fifth Amendment. The difference between _Haynes_ (and _Albertson v. Subversive Activities Control Board_ 382 US 70 (1965)) and Tim's hypo is that Tim's hypo doesn't force only guilty people to provide information, it requires all people using crypto to do so - so it's not targeted at "persons inherently suspect of criminal activities" (see _Haynes_ at 96, _Anderson at 79), and it doesn't necessarily give rise to "real and appreciable hazards of incrimination" (_Haynes_ at 97). But it seems to me that the real bottom line is that the information which is compelled is not incriminating, and the information which is incriminating is not compelled. The keys to my crypto might lead to incriminating evidence, or they might prove to be useful in a prosecution, but they're not in themselves any sort of a signal that a crime has been or will be committed. I think it's a different argument - and probably even comes out the other way - if the command to reveal a key is made to a particular individual in circumstances where possession/knowledge of the key is likely to implicate the holder in criminal activity. If the police find an encrypted disk which is labelled "The Story of How I Killed Jimmy Hoffa and Where I Put His Body and the Murder Weapon", compelling someone to reveal the key which decrypts the file(s) on that disk seems incriminating, even if the information produced (the string of binary digits which is the key) isn't by itself incriminating. Is it "self-incrimination" to require people to provide the government with an address when they register a car, even though the police may use that address to look for evidence if you're suspected of a crime? Is it "self-incrimination" to require drivers involved in an auto accident to remain at the scene and provide a name and address to cops or other drivers? (Supreme Court says no self-incrim re hit & run statute, _California v. Byers_, 402 US 424 (1971).) (Now, if the government required people who weren't using GAK to provide a "Statement of Refusal to Comply with GAK", I think it'd be a different kettle of fish entirely.) I'm not trying to say that I think GAK is good - I think it's awful. But I don't think it's incompatible with the way that the Fifth amendment has been interpreted over the past 200 years. I think it's possible to ignore those interpretations and make up your own, but I don't think that's of much practical utility where the dominant local gang doesn't find your theory plausible or expedient. So much for the rule of law. >I also think that, besides the obvious 5th amendment problems, there >would be a 1st amendment problem - if you "*had* to use GAK to >communicate, that would be an impermissible restriction on your 1st >amendment rights. I agree with you re the First amendment. -- "The anchored mind screwed into me by the psycho- Greg Broiles lubricious thrust of heaven is the one that thinks every temptation, every desire, every inhibition." greg(a)goldenbear.com -- Antonin Artaud gbroiles(a)darkwing.uoregon.edu

2 1