December 2003 - cypherpunks-legacy

CYPHERPUNKS PARTY -- invite to party in DC on September 6
by Declan McCullagh 17 Dec '03

17 Dec '03

You are cordially invited to a DC cypherpunk working meeting and patent expiration party on September 6. On Saturday, September 6, the patent on the Diffie-Hellman public key cryptography system expires. Along with the Merkle-Hellman patent (which expires on October 6), this patent is key to the future of public key crypto. Now programmers can write strong encryption software without worrying about patent licensing. But the expiration of the patents doesn't guarantee the future of strong cryptography. Proposed laws could restrict its use. So the party has two portions: -- 5:30 pm: a DCCP working party and potluck supper. Topics include discussion of the patents and regulation of cryptography. Guest speakers will discuss legislation in Congress and the Bernstein case. A speaker from the administration will provide a regulator's perspective. (Please contribute to the potluck dinner!) -- 8:00 pm: a post-meeting party to celebrate the expiration of the patents. (Please bring snack foods and beverages/drinks...) To RSVP, and for directions and details, e-mail Declan at declan(a)well.com with DCCP-DH in your Subject: line. The party will be held in Adams Morgan in Washington, DC. -Declan

1 0

Openings for INFOSEC Analyst and Engineers
by Robert Hettinga 17 Dec '03

17 Dec '03

--- begin forwarded text X-Authentication-Warning: silence.secnet.com: majordom set sender to owner-security-jobs(a)secnet.com using -f From: "Meryweather, Rod" <Rod.Meryweather(a)wang.com> To: "'security-jobs(a)secnet.com'" <security-jobs(a)secnet.com> Subject: Openings for INFOSEC Analyst and Engineers Date: Mon, 25 Aug 1997 13:43:14 -0400 X-Priority: 3 MIME-Version: 1.0 Sender: owner-security-jobs(a)secnet.com Precedence: bulk WANG GOVERNMENT SERVICES SECURITY SERVICES POSITION OVERVIEW AND SUMMARY Organization Overview The Wang GS Security Services organization is a descendant from the Honeywell Information Systems group that has been focused on developing High Assurance computing solutions for the US Government since the late 1970's. Honeywell was the first vendor to have a system evaluated by the NSA National Computer Security Center (NCSC) against the Orange Book (a document that defines levels of trust that can be reached by operating systems) at the A1 level - the highest - in 1984. Our XTS 300 product is a direct descendent of the A1 SCOMP platform, and is currently evaluated at the B3 level of trust. The Security Services (SS) organization focuses on development and deployment of secure solutions. Product activities are contained in a group focused on the XTS 300 operating system and a trusted guard development framework product (the SAGE). The rest of the organization is focused on implementation of task-specific solutions. These currently include: DLA Security Assessment: Wang currently supports the security planning, assessment and accreditation activities with the DLA and the Defense MegaCenter in Dayton, Ohio. The DMS/DII Guard: This is a multi-year development effort that will result in a XTS 300-based X.400/X.500 guard with strong user authentication and encryption support (FORTEZZA). The State Department Guard: This is a new project that will implement a proprietary (State-compliant) XTS 300-based telegram network guard that works with identification of unclassified telegrams. The Command and Control Guard: The C2G effort involves the evolution of an existing XTS 300-based Government-owned Guard application that is deployed world-wide. The FBI: Wang currently has developed and deployed multiple IBM communications guards for the FBI, and continues to evolve and enhance the functional capabilities of these XTS 300-based systems. The IRS: This effort does not involve the XTS 300. Rather, Wang is responsible for the EDI telecommunications and security infrastructure of the IRS Tax Collection system, based on an NCR commercial Unix platform. General Technical Requirements Excellent C and Unix skills (we do not code in C++ except for the IRS project). Strong structured design and documentation skills. Linux OS on Pentium workstation. Heavy emphasis on one of the following areas: Computer Security, Unix Kernel (device drivers, printer drivers, API, OS construction), Communications (TCP/IP, X.400, X.500, SNMP), Encryption (PCMCIA or software-based), GUI development (X), Testing. MUST be clearable to TS. MUST have a BS degree or equivalent experience. MUST be a self-starter and quick learner. Competitive compensation and benefits, casual dress code, technical organization. Herndon location as of August 1, 1997. See http://www.wangfed.com/products/ssso/homepage.html for product details, http://wang.com for information about Wang. Specific Positions INFOSEC Accredidation & Risk Assessment Candidate will be a member of the DLA Security Architecture team, and will be responsible for taking a lead role in the security assessment, certification, accreditation, and post accreditation of large multifaceted LAN's/WAN's conducting EC/EDI communications on a global bases. Required 4-12 years experience with trusted system solutions and architectures. Strong back ground in National Computer Security Center "Rainbow Series" and Information Systems Security (INFOSEC) policies, procedures and documentation experience. Accreditation Support/Risk Assessment Candidate will be a member of the DMS/DII Guard Development and Deployment team, and will be responsible for taking a lead role in the assessment and justification of the assurance of the Guard architecture. Required 6-12 years experience with trusted solutions and architectures, X.400/X.500, accreditation and deployment issues. Strong documentation and communications (verbal) experience. Senior OS Developer (1) Candidate will be a member of the XTS 300 OS development staff, and should have considerable exposure (8-15 years) to the construction and enhancement of a Unix OS. Activities include API development and enhancement, device driver implementation (e.g., printer, SCSI, "console", PCMCIA devices, ethernet (802.3 + 100Mb or ATM)), application porting (e.g., X), bug fixes, and new platform porting (from one Pentium mother board to the next). Orange Book security a BIG plus. Junior OS Developer (2) Candidate will be a member of the XTS 300 OS development staff, and should be very comfortable with heavy structured C and Unix (OS construction, release building from source, etc.) Linux experience a big plus. 2-5 years experience with heavy C, Unix, and at least one of the following: GUI development, application porting on Unix, communications (TCP/IP, X.4/500, SNMP), systems installation and debug, heavy scripts, heavy testing. Orange Book security a BIG plus. XTS 300 GUI Developer Candidate will initially be assigned to the State Department Guard task, and will be responsible for the specification, design, development, implementation, testing and documentation of the man-machine interfaces for this Guard (Main-in-the-Middle review capability, dirty word list management, report generation, etc.). This will be developed with a subset of X (Motif-based). 3-5 years experience in X, C, Unix, documentation, design. All salaries are dependent on experience and are negotiable. Open Date : 8/18/97 Close Date: 1/31/98 Point of Contact: Rodney Meryweather Ph: (703) 827-3818 Sr. Security Analyst Fax: (703) 827-3161 Wang Government Services Email: Rod.Meryweather(a)wang.com 540 Huntmar Dr. Herndon VA. 22070 Sr. XTS Applications Developer (3) Candidate will be a member of the XTS 300 Application Development focus group, and will be responsible for a lead role in the development of Guard applications. Must have 8-15 years heavy C, Unix, Comm (TCP/IP, X.4/500), structured design, documentation, development, implementation, testing, debug and support. Orange Book Security and Guard/Firewall design a big plus. Jr. XTS Applications Developer (3) Candidate will be a member of the XTS 300 Application Development focus group, and will be responsible for a supporting role in the development of Guard applications. Must have 2-5 years heavy C, Unix, with a focus in one or more of the following: Comm (TCP/IP, X.4/500), structured design, documentation, development, implementation, testing, debug and support. Orange Book Security and Guard/Firewall design a big plus. All salaries are dependent on experience and are negotiable. Open Date : 8/18/97 Close Date: 1/31/98 Point of Contact: Rodney Meryweather Ph: (703) 827-3818 Sr. Security Analyst Fax: (703) 827-3161 Wang Government Services Email: Rod.Meryweather(a)wang.com 540 Huntmar Dr. Herndon VA. 22070 --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' The e$ Home Page: http://www.shipwright.com/

1 0

BoS: Bug bugs privacy file but a fix is on the way (fwd)
by Patrick Oonk 17 Dec '03

17 Dec '03

Forwarded message: >From best-of-security-request(a)cyber.com.au Tue Aug 26 08:30:06 1997 Resent-Date: Tue, 26 Aug 1997 16:16:35 +1000 (EST) From: darrenr(a)melb.convergent.com.au (Darren Reed) Message-Id: <199708260343.NAA08202(a)duchess.melb.arcsystems.com.au> Date: Tue, 26 Aug 1997 13:43:37 +1000 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: darrenr(a)cyber.com.au Old-Status: O Resent-Message-ID: <"kYO8a.A.IkC.-PmA0"@plum> X-Loop: best-of-security(a)cyber.com.au Errors-To: best-of-security-request(a)cyber.com.au Precedence: list Resent-Sender: best-of-security-request(a)cyber.com.au To: best-of-security(a)cyber.com.au Resent-From: best-of-security(a)cyber.com.au X-OS: FreeBSD3.0-current X-Mailing-List: <best-of-security(a)cyber.com.au> ftp://ftp.cyber.com.au/pub/archive/b-o-s/ X-Subscription: To unsubscribe from this fine mailing list mail best-of-security-request(a)cyber.com.au with Subject: unsubscribe Subject: BoS: Bug bugs privacy file but a fix is on the way A "flaw" in the encryption program PGP 5.0 was reported to the Australian security organisation AusCERT lat week, and a recommended fix was issued later in the week. Security consultant Paul Drake, an expatriate Australian working for a company called NetSafe, said he had discovered a bug that menat PGP 5.0 (for "Pretty Good Privacy") kept passwords in memory "at all times", as well as part of the text of whatever had been encrypted. The keyfile was also being kept in a relatively insecure file, he said. AusCERT confirmed the problem had been reported and said they were investigating. PGP advocate peter Moon, who is pushing for wider use of the software in Australia, said while the problems pointed out by Drake were "valid", they were more weak points than "bugs". "The PGP encrpytion algorithm is - as anyone knows - as solid as a rock. The attacks are all based on the principal that if you want to break into the strongest box in the world, the easiest way is to pinch thekey." He said a product called bcwipe could clear the saved information and the keyfile should probably be deleted altogether. Drake said PGP, a United States-based company, would release "PGP 5.01" without the problem. -- Jenny Sinclair, Page D4, The Age, Tuesday 26 August 1997 -- | Patrick Oonk - http://patrick.mypage.org/ - patrick(a)pine.nl | | PGP Key ID 0xDA2E93FA - Internic PO59 - <clicketyclick> | | Pine Internet B.V. Consultancy, installatie en beheer | | Tel: +31-70-3111010 - Fax: +31-70-3111011 - http://www.pine.nl/ |

1 0

distributed virtual bank
by Adam Back 17 Dec '03

17 Dec '03

An application I have put a bit of thought into is the idea of creating a distributed banking system. That is not offline, but not a single centralised trusted bank either. Ideally it is a system where all nodes are equivalent, and k of n of those nodes have to collude before they can compromise the operation of the bank. This is related to the encrypted computation idea where I can ask you to perform a computation for me, but you won't know the operands, and I can recover the answer with a final transformation. There are a few such protocols around to compute certain functions. This would be a distributed system, the nodes in the network would be able to simulate a virtual CPU by exchanging messages and computing encrypted functions. The program you run on the virtual CPU is the bank software. One approach would be to simulate the CPU by using the exchange of encrypted communications to simulate circuit functions in the CPU. Hopefully there would be more efficient methods of performing this securely distributed computation. People would trust the bank by virtue of their belief that it would be too difficult for an attacker to compromise or acheive sufficent collusion to overcome the n of k threshold. The bank would live in the network in this virtual CPU. Individual nodes may come and go, yet the secured software entity which is the bank and it's account information would live on. Comments on how feasible it would be to design such a system with current crypto techniques? Adam -- Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

1 0

Collection of persona
by damion.furi＠the-matrix.com 17 Dec '03

17 Dec '03

BU|In fact it's not difficult. It's quite simple to estlablish new identity |for the individual willing to risk the charges and consequences of |exposure. The basic impediment is time. Good credit doesn't come |overnight. The second impediment is tax evasion- which is less than |justifiable in the United States on the grounds of privacy. If you're |willing to be patient, and pay taxes on more than one name, its easy to |maintain several identities. A lot of "ifs" there. Not to mention the expense. BU|> If it were possible to have an alias in real |> life, as easy as it is to get one on the 'net that is, then I would most |> certainly do so.. BU|Which tells me how serious you really are about your privacy. You have |made a decision here about how much trouble privacy is worth to you, |which is "not much." And how many "real names" do you have off the net? BU|I hear people bitch about privacy endlessly. Privacy helps those who |help themselves to privacy. I think Mr. May was precisely correct in saying |that it is so much easier and simpler for one to rely on self privacy |insurance rather than government privacy insurance. Certainly. That doesn't mean that we're all going to jump up and maintain several aliases. Particularly when our beloved Uncle Sam is quite capable of deciding that it's for fraudulent purposes -- which makes it a felony. It would be simpler and easier to start another revolutionary war than follow your logic. :----------:----------:----------:----------:----------:----------:----- : furi(a)the-matrix.com | pgp-public-key(a)demon.co.uk | LIVE LION ALERT : 2.6.2 1024/C1225CE1 | 38 11 7C 59 FB F3 7C C0 F7 E9 67 1F AF B8 2D 94 PGP: When it's none of their damned business. -- SPEED 1.40 [NR]: Evaluation day 133...

1 0

Re: Socio-Economic Cults (Re: Cypherpunk Cults)
by Anonymous 17 Dec '03

17 Dec '03

1 0

ULC Online
by Jaeson.M.Engle＠dronf.org 17 Dec '03

17 Dec '03

Just in case anyone else wants to go ahead and get ordains in the ULC, http://ybi.com/ulc/ordain.html Online form for getting ordained. Jaeson -- Jaeson M. Engle http://www.dronf.org Coordinator of the Jourvian Group PGP Mail Encouraged -> jme.pub.key(a)dronf.org Project List -> programs(a)dronf.org

1 0

Re: FCPUNX:Jurisdiction Shopping
by James A. Donald 17 Dec '03

17 Dec '03

At 11:06 AM 8/26/97 -0400, Duncan Frissell wrote: > Another popular reason is privacy in general. US domestic accounts can be > examined by any federal, state, or local government employee who can sign his > name to a subpeona. Any lawyer can also examine account records in the > course of discovery proceedings. There are some limits to the above powers > but not very substantial limits. For all we know, FINCEN has a nice Win32- > based point and click browser that can tiptoe through every bank and > brokerage account in America. If they don't have one yet, I'm sure they are > trying to get one. > > If domestic lawyers or governments want the same sort of access to accounts > in other jurisdictions, they have to spend many thousands of dollars and > months or years of personnel time. Cuts down on their capabilities. This is true to a greater or lesser extent of almost any foriegn jurisdiction. Even both countries are hostile to financial privacy and have cosy relationships with each other, it is still a lot more work for investigators in one country to get information from another. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0

Sweden's Social Democrats Sterilize the Inferior
by Declan McCullagh 17 Dec '03

17 Dec '03

> >From: David Boaz <dboaz(a)cato.org> >Subject: Social Democrats Sterilize the Inferior > >Surprisingly, the revelations about 40 years of forced sterilizations by the >Social Democratic governments in Sweden generated only small stories in the >New York Times and the Washington Post. I'm sure they would have been >equally uninterested in revelations about forced sterilization in, say, >Thatcher's Britain. Be sure to read to the last line of the story where at >last the AP pins it directly on the Social Democrats' ideas. > > > >By JIM HEINTZ >.c The Associated Press > >STOCKHOLM, Sweden (Aug. 25) - They were found to be ''inferior,'' flawed by >bad eyesight, mental retardation or ''undesirable'' racial characteristics. >To prevent this genetic heritage from being passed on, they were sterilized - >sometimes involuntarily. > >Sweden had as many as 60,000 of its own citizens sterilized between 1935 and >1976. Adults and children were singled out by doctors, school authorities or >other officials and were pressured to consent to the procedures. > >This sterilization program bore chilling similarities to Nazi ideas of racial >superiority - and media reports on it now are provoking sober >self-examination. > >The program stemmed from the pursuit of eugenics, a once-popular movement to >improve humanity by controlling genetic factors in reproduction. > >Though Sweden's sterilization program was a matter of record, it received >little public attention, ignored in schoolbooks and hardly mentioned in >reference works. A recent series by the prestigious newspaper Dagens Nyheter, >however, has stirred national debate. > >Especially shocking to many Swedes is the fact that the law allowing the >sterilizations wasn't overturned until 1976, three decades after the Nazis' >human engineering policies collapsed in the rubble of the Third Reich. > >The sterilizations targeted a wide range of people: those of mixed race; >unmarried mothers with several children; people judged to be habitual >criminals; even a boy considered ''sexually precocious.'' > >''Grounds for recommending sterilization: unmistakable Gypsy features, >psychopathy, vagabond life,'' reads one document cited by Dagens Nyheter. > >Maria Nordin, 72, told the newspaper she had been sterilized in 1943 because >she was regarded as mentally inferior. > >''One day, the (school) superintendent said I should come into his room to >sign some papers. I understood what this was about so I ran into a toilet and >sat there and cried for a long time for myself,'' she said. > >Sweden, with its well-developed welfare state and long-standing progressive >stances on social issues, is not accustomed to being on the defensive on >ethical issues. > >''This is a frightening picture that now is being shown to the Swedish >people,'' Alf Svensson, chairman of the opposition Christian Democratic >Party, said in a letter to Prime Minister Goeran Persson. > >Social Minister Margot Wallstroem says she is considering whether to >compensate people who were forcibly sterilized. That would require >overturning current law that says the victims can't get compensation because >the sterilizations were lawful when performed. > >Nordin applied for compensation last year but her request was turned down by >Wallstroem, who now says she feels ashamed over the matter. > >''I will take up the matter for discussion with the government. It is the >least I can do,'' the Cabinet minister said. > >The Dagens Nyheter report has hit Swedes at a time when they were already >examining some painful history from World War II. The government, under >increasing international pressure, is looking into whether property looted by >the Nazis from Jews in other countries ended up in Sweden. > >The issue of forced sterilization stands to be even more troublesome, because >it was conducted under the ostensibly benign gaze of the Social Democrats - >that party that built Sweden's welfare state and proclaimed it a paragon of >enlightened government. > >''The Social Democrats are implicated in a collective guilt,'' said Social >Minister Wallstroem, herself a member of the party. > >The sterilization programs can be traced to turn-of-the-century enthusiasm >for eugenics. > >The movement had adherents in many countries, but ''Sweden was the first in >the world to grant this pseudoscience official recognition,'' Dagens Nyheter >wrote in describing how Sweden established an Institute of Racial Biology in >1921. > >Not only did eugenics foresee an improved human race, it also was appealing >to Social Democrats, who were beginning to see that Sweden's welfare state >would be costly and wanted to limit the number of people who would have to be >supported, the newspaper said. > > AP-NY-08-25-97 1903EDT > > >

3 2

What is truth?
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 5:07 AM 9/7/95, Jim Choate wrote: >> >> Doesn't make it true, in Tim's sense--just makes it verifiable. >> >> MacN >> >> On Wed, 6 Sep 1995, Jim Choate wrote: >> > Truth is that which can be verified to be reproducable by indipendant and >> > unbiased parties. All else is opinion. >> > >What exactly is Tim's sense to you? Perhaps Tim could clarify more clearly >what he means by 'truth'. To me it sounds like he is saying that there is >some viewpoint that is absolute. I no more believe in absolute viewpoints >than I believe in absolute coordinates. I promise to be mercifully brief. This is a subject that we could all go on and on about. I used the ironic "What is truth?," a la Pilate, to indicate some degree of ambiguity. How Jim concluded that I have some absolutist viewpoint from this simple line is unclear to me. In any case, I don't believe there are "independent and ubiased parties" who can determine what truth is. Not that there is no measure of truth. I am no solipsist, and I believe we have a much clearer view today of how things work than we had, say, 500 years ago. Courtesy of science and the core idea of falsifiability. As this view relates to government and law, it is that many things are best left outside the bounds of the law. The law stays out of most inter-family disputes, for example, unless violence or fraud of a major sort occurs. And the law stays out of confirming or refuting religious claims. If Preacher Bob says that praying to Baal will save one's soul, no law officer will step in and stop this "lie." As I like to put it, of the N different religions, at most _one_ of them is "true," and the other N - 1 are based on lies. So, if we are to "allow" religious freedom we must surely allow lies to be told. Q.E.D. Our liberal, Western society went through this debate a long time ago, and it was pretty much concluded that people could choose their own paths to hell without interference from others. That people were free to believe any damned fool idea they wanted to believe in. Somewhere along the line we've adopted the new view that government needs to correct all incorrect thoughts, needs to protect people from "hurtful" ideas and speech, and needs to determine what is true and what is not true. If you want more information on my views about truth, check out the work on "evolutionary epistemology," especially the writings of William Bartley and Karl Popper. --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

How tO MutAte anD TaKE OVer tHe WOrld
by luciana luciana 17 Dec '03

17 Dec '03

I'm very interested on that. could u let me know anything else? ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Collection of persona
by damion.furi＠the-matrix.com 17 Dec '03

17 Dec '03

DM|Depends on the counter people. The local RS here the clerks don't care |much about it and will enter a random number. I wish they would do that here. I've just about yanked a manager over the counter over it. |A local Service Merchandise |does the same thing, but they're pesky, so I make up silly names to test |the wits of impatient teenage mutant cashiers. (They also used to have |a computer where you enter your telno. and place orders to pick up at |the desk... I don't think the system bills you automatically but the |employees probably won't like it when you have them get 10 wieght sets |out...) <chuckle> I love it when the system has a flaw I can take a crowbar to. :----------:----------:----------:----------:----------:----------:----- : furi(a)the-matrix.com | pgp-public-key(a)demon.co.uk | LIVE LION ALERT : 2.6.2 1024/C1225CE1 | 38 11 7C 59 FB F3 7C C0 F7 E9 67 1F AF B8 2D 94 PGP: When it's none of their damned business. -- SPEED 1.40 [NR]: Evaluation day 134...

1 0

Diskreet Disk Help Needed
by msprague＠owens.ridgecrest.ca.us 17 Dec '03

17 Dec '03

One of my Diskreet Disks has refused to open but will change size and password. Any suggestions??

1 0

SF Bay Area D-H patent party?
by Lucky Green 17 Dec '03

17 Dec '03

Who in the SF Bay Area plans to throw a party in honor of the upcoming expiration of the Diffie-Hellman patent? Several people had mentioned in the past they might do so. [Some of your are bcc'ed]. The patent will expire just a few weeks from now. Anybody? Thanks, --Lucky Green <shamrock(a)netcom.com> PGP encrypted mail preferred. DES is dead! Please join in breaking RC5-56. http://rc5.distributed.net/

1 0

Re: Are booby-trapped computers legal?
by alt＠iquest.net 17 Dec '03

17 Dec '03

At 03:38 PM 9/6/95 -0400, hallam(a)w3.org wrote: >People who go round drawing parallels to gun ownership and cryptography >ownership are simply playing into the governments hands. Which of our rights would you have us surrender so as to not play into the government's hands? >Cryptography has net benefits to society. You would have a hard time proving that cryptography has more, or different "net benefits to society" than gun ownership does. >Most advocates of gun ownership tend to convince me of >little more than they are a danger to society. Regardless of their case they are >the biggest argument for gun control, and therfore poor advocates of their >cause. Statists say the same thing about crypto-advocates. Talking about keeping secrets, and discussing which methods are uncrackable by the government is not what a statist wants to hear - and neither is talk about the real reason behind the 2nd Amendment.

1 0

Another Son of Clipper discussion paper
by Jim Gillogly 17 Dec '03

17 Dec '03

I sent along two discussion papers for tomorrow's NIST session on the revised plans for GAK last week. Here's the third. Jim Gillogly Hevensday, 14 Halimath S.R. 1995, 20:49 ----------------------------------------------------------------------------- Key Escrow Issues Meeting, September 6-7, 1995 Discussion Paper #3 Export Criteria Discussion Draft -- 64-bit Software Key Escrow Encryption As discussed at the SPA/AEA meeting on August 17, 1995, the Administration is willing to allow the export of software encryption provided that the products use algorithms with key space that does not exceed 64 bits and the key(s) required to decrypt messages/files are escrowed with approved escrow agents. On the same date, the September 6-7 key escrow issues meeting at NIST was also announced. The two principal topics at the meeting will be: discussion of issues of exportability of 64-bit software key escrow encryption and 2) desirable characteristics for key escrow agents. In order to help make most productive use of the limited time available at the upcoming meeting and to better focus deliberation, the following criteria are being distributed for discussion purposes. Since it is important that final criteria be clear, straightforward, consistent, and implementable, please review these draft criteria and be prepared to discuss how they may be refined and made more specific. --- Draft Export Criteria --- for Software Key Escrow Encryption Software key escrow encryption products meeting the following criteria will be granted special export licensing treatment similar to that afforded other mass-market software products with encryption. 1. The product will use an unclassified encryption algorithm (e.g., DES, RC4) with a key length not to exceed 64 bits. 2. The product shall be designed to prevent multiple encryption (e.g., triple-DES). 3. The key required to decrypt each message or file shall be accessible through a key escrow mechanism in the product, and such keys will be escrowed during manufacture in accordance with #10. If such keys are not escrowed during manufacture, the product shall be inoperable until the key is escrowed in accordance with #10. 4. The key escrow mechanism shall be designed to include with each encrypted message or file, in a format accessible by authorized entities, the identity of the key escrow agent(s), and information sufficient for the escrow agent(s) to identify the key or key components required to decrypt that message. 5. The product shall be resistant to any alteration that would disable or circumvent the key escrow mechanism, to include being designed so that the key escrow mechanism cannot be disabled by a static patch, (i.e., the replacement of a block of code by a modified block). 6. The product shall not decrypt messages or files encrypted by non-escrowed products, including products whose key escrow mechanisms have been altered or disabled. 7. The key escrow mechanism allows access to a user's encrypted information regardless of whether that user is the sender or the intended recipient of the encrypted information. 8. The key escrow mechanism shall not require repeated involvement by the escrow agents for the recovery of multiple decryption keys during the period of authorized access. 9. In the event any such product is or may be available in the United States, each production copy of the software shall either have a unique key required for decrypting messages or files that is escrowed in accordance with #10, or have the capability for its escrow mechanism to be rekeyed and any new key to be escrowed in accordance with #10. 10. The product shall accept escrow of its key(s) only with escrow agents certified by the U.S. Government or by foreign governments with which the U.S. Government has formal agreements consistent with U.S. law enforcement and national security requirements. Note: Software products incorporating additional encryption methods other than key escrow encryption methods will be evaluated for export on the basis of each encryption method included, as is already the case with existing products. Accordingly, these criteria apply only to the key escrow encryption method incorporated by a software product, and not to other non-escrowed encryption methods it may incorporate. For instance, non-escrowed encryption using a key length of 40 bits or less will continue to be exportable under existing export regulations. - - - Please also review discussion paper #1 (distributed earlier), which raises a number of issues involving exportability criteria and how exportable products could be designed. Discussion paper #2 (also previously distributed) presents questions involving key escrow agents. Note: These issues will be discussed at the Key Escrow Issues Meeting to be held September 6-7, 1995 (9:00 a.m. - 5:00 p.m.) at the National Institute of Standards and Technology (Gaithersburg, Maryland). The meeting will be open to the public, although seating is limited. Advance registration is requested, please contact Arlene Carlton on 301/975-3240, fax: 301/948-1784 or e- mail: carlton(a)micf.nist.gov. 9/1/95 -----------------------------------------------------------------------------

4 3

No. 8 / Re: Top 10 Ways to Make a Grouchy Old CypherPunk Smile
by bureau42 Anonymous Remailer 17 Dec '03

17 Dec '03

Top 10 Ways to Make a Grouchy Old CypherPunk Smile -------------------------------------------------- #10) Find his shoes for him. #9) Buy Kent Crispin a Dr. Kevorkian gift-certificate. #8) Lock. #7) #6) #5) #4) #3) #2) #1) [This space reserved for T.C. May]

1 0

Govt seeking emergency stay in Bernstein case
by John Gilmore 17 Dec '03

17 Dec '03

Date: Wed, 27 Aug 1997 13:43:36 -0700 From: Cindy Cohn <Cindy(a)mcglashan.com> Hi all, Just talked to Mr. Coppolino at the Justice Department. They are filing ex parte emergency stay papers tonight or tomorrow morning to try to stay the impact of Judge Patel's ruling pending appeal. He'll be faxing me the documents when they are ready. He said yesterday that they would seek to stay the "export" of crypto source code, although not the teaching or discussion (whatever that means). Cindy ************************ Cindy A. Cohn McGlashan & Sarrail, P. C. 177 Bovet Road, 6th Floor San Mateo, CA 94402 (415) 341-2585 (tel) (415)341-1395 (fax) Cindy(a)McGlashan.com http://www.McGlashan.com

1 0

subscripe
by Saitmacher, Klaus, Dr., DyStar 17 Dec '03

17 Dec '03

subscripe

1 0

Re: University logging mail to anon.penet
by Greg Broiles 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Jeff Simmons writes: > This just came up locally, and I'd like to have some comments on it, > especially from people who understand the law a lot better than I do: > > Our local University apparently has been logging ALL mail to anon.penet, > including faculty, students, and off-campus users. With respect to logging of student traffic, I'd look at the Family Education Rights Privacy Act ("Buckley Amendment", 20 USC 1232g) and the California analog to it (assuming one exists; Oregon's is located at OAR 571-20-005, et seq.). The release of information about individual students beyond "directory information" (e.g., name, dates of attendance, degrees granted, etc) is sharply limited without the consent of the student. Information about mail traffic sent and received is, IMHO, arguably (but not clearly) within "educational records" for FERPA purposes. To establish a Buckley Amendment violation (and I'm not saying there was one here) you'll still need to find a University employee to pin the disclosure on. If it's a University employee who posted them to the newsgroup, it's easy. If the University employee merely maintained those records in a place where an outsider was able to easily gain access to them, it seems like a bigger stretch. I had occasion to talk with a relatively high-level administrator in the University of Oregon's computer center some time ago and he explained that they've had to go to some trouble to make sure that gopher/WWW directories and other contemporary university computing practices don't fall afoul of the Buckley Amendment. Perhaps the powers that be at other places aren't quite so forward-thinking (or don't have the questionable benefit of being next door to a building full of law students with time on their hands). Perhaps an even longer stretch would be an argument that the practice of logging (and of keeping those logs in an insecure place) violates students (and others') right to privacy. Federal protection for a "right of privacy" is fickle, but California protects its citizens' right to privacy in its constitution. (I'm not an attorney (yet), don't live in California (right now) and consequently don't know much about CA law. So please think about this message as maybe a hint in (I hope) a useful direction, not necessarily the right answer. Feh.) This concrete issue seems like a good reminder of the implications of the way that we think about "cyberspace" and the things that happen when we use computers. If one thinks about a machine or a network as "public space", logging or reporting activities which happen there (e.g., Alice walks over to visit Bob, leaving footprints everyone can see in /var/adm/syslog) seems reasonable or at least not offensive, and it seems silly to talk about being angry because someone wrote down what everyone could see. But if we think about machines and networks as being private space, reporting on what Alice and Bob do seems tacky and rude at best, and horrifying (and likely to create liability) at the other end of the spectrum. As much as I dislike the "cyberspace" metaphor, its use or misuse has serious consequences. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBME6qJH3YhjZY3fMNAQHiQgP9HjqkwOzMabzXXbUKp0W7c2MAn4na5X1X UPVY8p70abNVpPoVFGQTUpgBnv3hBy40n5RFD9pNM7c2UPwq0C8Tcir9TBr+xEH7 L7iQCjsqIK5F1lv66C5yMFu8wfiRF10hMhTJYthOa04dyP10HovT2QameGw+DZHJ og1t7owgcco= =D5PV -----END PGP SIGNATURE-----

1 0

Le Monde: "Militant Cypherpunks liberate crypto software"
by Lucky Green 17 Dec '03

17 Dec '03

I am not making this up. Le Monde, a major French newspaper, discovered that "militant" Cypherpunks aid in the spread of crypto :-) In all fairness, the article is rather favorable. [Available in French only]. http://www.lemonde.fr/multimedia/sem3397/textes/act33971.html --Lucky Green <shamrock(a)netcom.com> PGP encrypted mail preferred. DES is dead! Please join in breaking RC5-56. http://rc5.distributed.net/

2 1

Collection of personal info
by David Neal 17 Dec '03

17 Dec '03

I sent this to the risks moderator some time back, but I guess he didn't like it. For those of you who think that perhaps people advocating cybercash are just a bunch of paranoid lunatics. -------------- As advertised in the trade magazine "DM News" (Direct Marketing News), Apr. 24, 1997, V. 17 N. 16. I've typed the entire text of the advertisement, any typos are mine. >From the huge number of people in the database, it would seem that TRW is now marketing a subset of their credit records they keep on everyone. Does anyone else remember the flap over Lotus' product (Magellan) that was going to allow something similar? The risks? This is the perfect database if you want to red-line your offerings. I'm sure others will have more creative answers. -------------- TRW DISCOVERED Some very smart people are uncovering exciting ways to increase response rates, find profitable customers, and develop new market niches. It's been a well kept secret. Now it's out. It's TRW. It all started with the search for more creative information solutions. Solutions that help you discover hidden markets and unique ways of using ordinary data to target qualified prospects. The result: a proven and massive database in the hands of people with real data management know-how. So far the findings have revealed: o A database of 170+ million consumers o 100+ demographic, psychographic and geographic selects o A full range of computer services. o Comprehensive motor vehicle data >From this comes an array of products and services to intrigue even the most seasoned direct marketer. One of these is called the TRW Smart Targeting Tools (SM). It links 98 million households with the goods and services they are most likely to buy. Choose consumer names by 50 neighborhood or 3600 household level clusters, by 56 broad product categories or by 516 specific product or brand preferences. Looking at all the advantages, TRW may be the direct marketer's find of this century. And the next. Energize your marketing. Contact your TRW representative or call 800.527.3933 Ext 640. You have a great find ahead of you. TRW Target Marketing Services Your one source for reaching all the right people. 701 TRW Parkway Allen, TX 75002-3717 800.527.3933 David Neal <dneal(a)usis.com> - GNU Planet Aerospace 1-800-PLN-8-GNU Unix, Sybase and Networking consultant. "...you have a personal responsibility to be pro-active in the defense of your own civil liberties." - S. McCandlish

5 5

Cypherpunks party videos
by Lucky Green 17 Dec '03

17 Dec '03

Good stuff from HIP keeps trickling in. See Brian the HIP brain. Witness Cypherpunks dancing. Watch your's truly as a DJ. http://www.ito.com/mpeg/hip/ --Lucky Green <shamrock(a)netcom.com> PGP encrypted mail preferred. DES is dead! Please join in breaking RC5-56. http://rc5.distributed.net/

1 0

Notes from NIS&T Key Escrow Export conference.
by Pat Farrell 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Here are my noted and remembered impressions from Wedensday's NIS&T conference on key escrow (aka GAK) export. Please note that there is a separate conference next week on creating a FIPS PUB standard for key escrow. That standard will be promulgated, just as GOSIP, POSIX and Clipper/Skipjack were promulgated. This export conference was separate from that FIPS standardization process. I got stuck in a construction traffic jam, and missed the introductory speaches. Perhaps one of the other c'punks can fill us all in on what I missed. The first item is that the export criteria will be changed. A small number of bits will be added to unescrowed crypto, and 64-bit escrow'd (GAK'd) systems will be allowed. They don't care which algorithm is used, DES, RC4, blowfish, etc. They care about key length. If it is short enough, it is exportable. The conference seemed to be an attempt to co-opt industry into agreeing that 64-bit GAK is much better than the current situation. After all, it would be too strong for a "hacker in France" to break it. When they opened the floor, there were a few comments/questions that indicated that not everyone was convinced that this was a good thing. I pointed out some graduate students don't consider "hacker" a compliment, and that I thought Damian did a great job breaking RC4-40. I also pointed out that it was broken again in 31 hours with a "bunch of commercial systems, Sun and Pentiums" with no need for suaercomputers. I then asked if the criteria were fixed, as setting criteria controls the result. The NIS&T approved board said that changes to the criteria was part of why the conference was being held. The next hour and a half was presentation from "industry." Essentially comments on the proposal. Nearly all of the spokesmen said that the criteria were flawed. Some said that they already had commercial products that met most of the real needs of the industry (key recovery) but they didn't meet the NIS&T/NSA "criteria." Probably the strongest was the condamnation by Robert Holleyman of the Business Software Alliance. Hollyman said that BSA represents firms such as Microsoft, Novell, Lotus, Sybase, SCO, Autodesk, and Intergraph. He said that current policy "directly threatens" the industry because of "The US Government's continuing refusal to adopt realistic export control policies." He went on and on. It was clear that his position is that the proposed policy is a mistake. After the presentations, there were more questions. I proposed one additional criteria (based on email that I received from the c'punks): How do we expire court approved access to encrypted data, so that once the court orders are over, the LEAs no longer have the ability to decrypt. The answer was that with clipper, special hardware is needed, and it goes away when the court order does. I asked how that model worked in a software only world. There were mumbled statements about adding it as a criteria. The conference then broke for lunch and breakout groups. The one I was in discussed criterias 5 and 6 of Topic 3, published in my URL http://www.isse.gmu.edu/~pfarrell/nistmeeting.html They are short enought to reproduce here. 5. The product shall be resistant to any alteration that would disable or circumvent the key escrow mechanism, to include being designed so that the key escrow mechanism cannot be disabled by a static patch, (i.e., the replacement of a block of code by a modified block). 6. The product shall not decrypt messages or files encrypted by non-escrowed products, including products whose key escrow mechanisms have been altered or disabled. After I commented that the person writing the notes has the ability to detirmine what was said, the folks from NSA and NIS&T asked me to take the notes. I love it; but I did try to be objective. In the middle of this discussion, a government-generated, but anonymnous paper was distributed. It had "Example Suggested Solutions." It suggeeted that source code not be available for products suitable for export. It also suggested other ideas, such as storing a checksum/hash and having the system "check the cryptographic code several times during its use." There was a strong reaction against these suggestions, not because they were bad ideas, but because the paper was delivered with no prior publication. This precluded any planned response to its ideas. We reworded #5 to say "want to Trust the Product." This means that it is untampered, works as expected, etc. We then hashed out ways to know this. The list ended up looking like: 1. is available only as object code 2. contains some "hash" function to check for modifications 3. contains some unique hash, with uniqueness based upon something like "site," "per copy" or "per release" 4. Contains policies against modification, such as liscense language against decompilation. 5. OS-related security, such as runs "protected mode" instead of as a wild DOS program. Of course, the software vendors went wild against "per copy" identifiers, saying it would add two orders of magnitude worth of problems to manufacturing. The items on the list were not "must have all of these" rather it was a pick-and-chose menu. We also required that the standard allow for technical innovation to keep up with the evolving state of the art. The discussion of #6 was more lively. We took a long time figuring out what it said. For instance, could ViaCrypt sell a product that was compatible with PGP 2.6.2 (non-escrowed) that also worked with the new escrowed ciphers? It seems to me, and a lot of other folks there, that such a product would be non-exportable. We simplified the criteria to: "right products won't talk to wrong products." with "right products" meaning those that are exportable, and wrong products being those that aren't, or are hacked, or ... We then developed "goals" including: 1. One version for sale worldwide 2. Allow development in the US 3. Domestic Law Enforcement Agencies want Escrowed (I almost wrote GAK :-) 4. Must interoperate with everything 5. Receiver can only decrypt if escrow agencies can decrypt. This leads to a bunch of issues and observations, including: a. Can goals 1, 2, and 4 be met simultaneously? There was a suggestion of a "friendly man-in-the-middle" who would receive a GAK'd conversation, and strip off the GAK parts, and reencrypt it, and retransmit it to a non-GAK user. Which leads to: b. Can we prohibit a friendly MITM? The big issue was: c. Startup compatibility. No one will buy products unless they have sales attractiveness. This means compatibility with existing systems. Yet the criteria #6 seems to say that approved products must refuse backwards compatibility. This was labeled a "non starter" by the group. The consensus was that companies can develop a substantial competitive advantage by developing off-shore and offering both escrowed encryption and compatibility with existing systems. There was a discussion of grandfathering in some technologies. This was to help interoperability. The conversation became fuzzy, Grandfather technologies included DES, 3-DES, IDEA, and long key RC4. One key idea was that it may make sense to allow software that encrypts with escrowed keys, but can also decrypt with any algorithm. This allows the LEA's to access outgoing messages, while allowing interoperability. The discussions frequently wandered to discuss the language of the criteria. The wording was considered simultaneously too subjective and impractical. For example, we considered the phrase "tamper resistant" to be preferable to the original "prevent tampering," because it is impossible to absolutly prevent modification to software. The issue of interoperability was raised repeatedly. It is critical that exportable products interoperate with other, existing export products. The last issue in the session was that the length of the key, 64-bits, was defined in criteria #1. There was no discussion at the conference on this criteria. It seems that the NIS&T and NSA folks believe that this is a closed topic. The folks in the session did not agree. They felt that 64-bits was not enough. Once the breakout session was over, the entire conference met together, and the "reporter" from each session reported their comments and findings. All breakout sessions had suggested changes. The group that discussed criteria #9 recommended removing it. The group that discussed criteria #2 (no multiple encryption) reported that industry was working on a general solution to the problem of key recovery, and that their solution would probably appear as quickly without the government's "help." Several groups identified that there are at least two separate problem domains: communications and data storage. Communications typically is short term, and has unique keys for each session. Data storage has far fewer keys that are used for long periods. Several speakers suggested that while communications keys were not suited to be escrowed, there was a large need for key recovery for data storage. There was no response from the government representatives to any of these points. One government speaker did say that there would be a Federal key escrow standard, period. After the combined session, there were more break-out sessions. In the one that I attended, the folks from National Semiconductor described their CAKE system. This is a smartcard/PCMCIA device that uses 2000+ bit public/private key encryption and signatures. They are hoping for export approval; it is necessary for the project to be viable. The system looks pretty interesting, but it too complicated to describe here. In short, random session keys are generated and signed with a Data Recovery Center's public key. The LEAs could then send encrypted session keys to the DRC, which would decrypt them, and return the unencrypted session keys which the LEA could then used to decrypt the messages. While this is a hardware system, its concepts could be transfered to a software implementation. One obvious problem is that NS' system doesn't meet criteria #8 (retuiring repeated involvement of the escrow agent), since it may require hundreds or thousands of session key decipherments. It also has a number of attractive features, such as never sending the private key anywhere, only the session key is escrowed. The general discussion showed concerns that in the international community, requiring government escrow may cause lose of valuable data, as some foriegn governments are not as trustworthy as the US. It was the consensus that requiring users to have 50 or more escrow centers was unworkable. Yet this could be required for large multinational companies working in 50 or more countries, if each required a local key escrow service. The NS model would allow both date stamping of session keys, and periodic rekeying. Either would satisfy my "unaccepted" Citeria #11, technical limits to the time that a court ordered decryption could be executed. There was a discussion of changing the criteria so that only the transmission of data was concerned with escrow. This would simplify the issue of multinational escrow. We did not resolve whether this would be sufficient or acceptable. Today, we will talk about suitable escrow agencies. Pat -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBME7WOLCsmOInW9opAQHbawP+PSC+9p7ll7yKTiwnkzrIf+aT/ZfuoCqj Fp6ZhykIoJQVF5YAEhz9O1t9FKOauo3baMDhaIvU4pUSm2b/hKlUFB8cwYr7KTjd MFGxTOG/D7blGuX6ZXbHlS5EkKeT1pDtfrd9GlnTKWHxfga/51ROWCG/33BWZxHR lyNLI07UPbo= =kFkC -----END PGP SIGNATURE----- Pat Farrell Grad Student http://www.isse.gmu.edu/students/pfarrell Info. Systems & Software Engineering, George Mason University, Fairfax, VA PGP key available on homepage #include <standard.disclaimer>

1 0

IDEAL FOR BEGINNERS WORK-AT-HOME
by rewards＠t-1net.com 17 Dec '03

17 Dec '03

/////////////////////////////////////////////////////////////////////////////// This Message was Composed using Extractor Pro Bulk E- Mail Software. If you wish to be removed from this advertiser's future mailings, please reply with the subject "Remove" and this software will automatically block you from their future mailings. //////////////////////////////////////////////////////////////////////////////// I have been a business owner for over 30 years, involved in various things, and I have found different strategies for making money, working at home.... I thought you might like to know, this really works, if you will only try it... For more information send e-mail to max(a)answerme.com

1 0