- cypherpunks-legacy - lists.cpunks.org

Re: Florida Drivers Permits
by David K. Merriman 17 Dec '03

17 Dec '03

At 01:10 PM 8/25/95 -0400, you wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >- -----BEGIN PGP SIGNED MESSAGE----- > >[Welcome back, Professor] You posted: > > >>Will, starting next year, containg a digitized photo, plus the current >>info. > ><snip> > >>Anyone know any details about the technololgy? > ><snip> > >Not really. > I saw the same story. The name, address, age, & height mentioned >are already obvious on licenses, but this may preclude incorrect data entry >by FL cops, and counterfeiting (a problem here for *years*). I saw nothing >on the digitized photo, but we could be looking at different stories. >Phase-in in July, '96. The story I saw suggests that other data, such as >tickets, criminal violations (presumably convictions) and "other >biographical information" [welfare, credit info] could eventually be >included, depending on FL's state budgetary considerations. No author, >just "Associated Press," listed on the story, and the card uses a magnetic >strip "like those on credit cards" rather than a chip, which may be a >mistake [considering the renewal period & my experience with bank-cards]. >Story doesn't say it, but it sounds like FL *may* be the first state to do >this. Are any other states doing this already? Texas is now issuing similar cards - with the addition of a barcode on the back. Front is going to have UV-reactive writing, and be color-coded for class of license (commercial, chauffer, etc). Happily, I renewed just a couple months ago, so have plenty of time to figure out what I can do to the new DL when I get one :-) Dave Merriman This is a test (3 UUE lines) of the unconstitutional ITAR - 1/713th of the PGP executable. See below for getting YOUR chunk! ------------------ PGP.ZIP Part [015/713] ------------------- M=$<(&L`#*IPP",(G6(,,S,`P](<2RWU96XCW86/JBYV8A\D8@X'HB_9H#&\X MX'PCUB.,13B"X8`R?^J-:UB.M_`U\>[#)BS&5$0C,Y#^1CS>1`\T1QTXX6!3 M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/ <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> My web page: http://www.geopages.com/CapitolHill/1148

1 0

brutessl web keyservice
by David K. Merriman 17 Dec '03

17 Dec '03

Feh. I've been trying to get allocated some more keyspace from the brutessl web page, and keep getting timeouts. Last time, I requested 8 segments, got issued *3*. Dave Merriman This is a test (3 UUE lines) of the unconstitutional ITAR - 1/713th of the PGP executable. See below for getting YOUR chunk! ------------------ PGP.ZIP Part [015/713] ------------------- M=$<(&L`#*IPP",(G6(,,S,`P](<2RWU96XCW86/JBYV8A\D8@X'HB_9H#&\X MX'PCUB.,13B"X8`R?^J-:UB.M_`U\>[#)BS&5$0C,Y#^1CS>1`\T1QTXX6!3 M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/ <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> My web page: http://www.geopages.com/CapitolHill/1148

1 0

ssl challenge
by David K. Merriman 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- It would be Really Nice if the next version of the brutessl software had a couple of features (particularly for us folks with mini-LANs) - > option to output results to a file (or files, so we can maintain local logging of results: ie, CHAL2a.dat, CHAL2b.dat, etc). > a Windows 3.1 variant (or even win32s) I've got 3 machines (386sx-33, 386DX-20, 486DX2-80), with an option on my roommates machine (386DX-40), all connected via Windows for Workgroups. All 4 are set up with win32s, so could do a *lot* better at keysearches if the software was available. There's plenty of support for Unix variants, and even NT/95, but us humble Win/DOS users are kinda left hanging a bit. Maybe next challenge, we can pre-allocate keyspace based on the results of this one: look at how fast folks are reporting results, and allocate chunks of space accordingly (maybe based on an 8-hour 'cycle'). Sure take some of the load off the poor server :-) Dave Merriman -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMD4E48VrTvyYOzAZAQGSMwP8DWxgb5NVDgvIFuw1BGf0E5TP0swHdyZ1 I4gfIGMtjd1AbtJHbxwILSPwb8+BcqZxZtGQXnYRnyoAkK7FltsiGulWApMXmNUU gtSUMr9xngW+Mwq5ju865Ff5wp7s8Bv3BBTqKGLmXWON1ILbEbjUNwqs4i8+wQU0 PCOgvJndj5M= =dyvQ -----END PGP SIGNATURE----- This is a test (3 UUE lines) of the unconstitutional ITAR - 1/713th of the PGP executable. See below for getting YOUR chunk! ------------------ PGP.ZIP Part [015/713] ------------------- M=$<(&L`#*IPP",(G6(,,S,`P](<2RWU96XCW86/JBYV8A\D8@X'HB_9H#&\X MX'PCUB.,13B"X8`R?^J-:UB.M_`U\>[#)BS&5$0C,Y#^1CS>1`\T1QTXX6!3 M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/ <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> My web page: http://www.geopages.com/CapitolHill/1148

2 1

NIST Key Escrow Papers
by Dave Banisar 17 Dec '03

17 Dec '03

fyi... ---- August 25, 1995 MEMORANDUM FOR Registrants for the Sept. 6-7, 1995 Key Escrow Issues Meeting From: NIST - Ed Roback Subject: Discussion Papers Attached for your information are two discussion papers for the upcoming September 6-7, 1995 Key Escrow Issues Meeting to be held at NIST. If you have any questions on this material, you may reach me on 301-975-3696. I look forward to seeing you in September. Attachments ------------------------ Key Escrow Issues Meeting, September 6-7, 1995 Discussion Paper #1 Issues -- Export of Software Key Escrowed Encryption On August 17, 1995, the Administration announced its proposal to permit the ready 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. Under the proposal, products will be reviewed to verify that they satisfy the criteria and, if so, they will be transferred to the Commodity Control List administered by the Department of Commerce where the products can be exported under a general license (in much the same way that 40-bit RC2/RC4 encryption is licensed today). We are working toward creating broadly stated criteria that are in the nature of performance specifications. To meet these criteria, encryption products will need to implement key escrow mechanisms that cannot be readily altered or bypassed so as to defeat the purposes of key escrowing. The criteria, when finalized and published, will state the objectives, but not the exact technical method(s), by which those objectives are satisfied. This is to provide software publishers the flexibility to design methods for meeting our stated objectives in a manner that is compatible with the design of their products. There are, therefore, a number of questions we must work together to answer in order to draft effective criteria. These questions are: * Avoiding multiple encryption -- How can the product be designed so as to prevent doubling (or tripling, etc.) the key space of the algorithm? * Disabling the key escrow mechanism -- How can products be made resistant to alteration that would disable or circumvent the key escrow mechanism? How can the "static patch" problem be avoided? How can this be tested? * Access to escrow information -- What mechanisms must be designed into encryption products to allow authorized access to escrowed keys? This likely includes the identity of the key escrow agent(s) and a serial number for the key escrow agent to use to identify the key(s)/component(s) necessary to decrypt the message. What other information will be necessary to be provided to the escrow agent to identify the necessary key(s)/component(s)? Are there other comparable viable approaches? * Non-escrowed use -- How can products be made so that they do not function with non-escrowed products (or tampered escrowed products)? How can this be tested? * Limiting surveillance -- How can products be designed so that information both sent and received by the user can be decrypted without release of keys of other users? * Practical Key Access -- How can mechanisms be designed so that repeated involvement of escrow agents is not required for decryption for multiple files/messages during the specified access period? * Assurance that keys are escrowed -- How can it be assured that key escrow products are indeed satisfactorily escrowed? For example, products could be required to be escrowed at time of manufacture or be made inoperable until properly escrowed. * Ability to re-escrow keys -- How can products be designed so that new keys can be escrowed at the user's discretion with a U.S. Government approved escrow agent? * Certified escrow agents -- Can products be designed so that only escrow agents certified by the U.S. government (domestic, or under suitable arrangements, foreign) are utilized? What should be the criteria for an acceptable U.S. escrow agent? -------------- With your input, we are hopeful that this effort will lead to definitive criteria, which will facilitate the development of exportable products and help minimize the time required to obtain export licenses. The Administration seeks to finalize such criteria and make formal conforming modifications to the export regulations before the end of 1995. 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. 8/25/94 ----------------------------- Key Escrow Issues Meeting, September 6-7, 1995 Discussion Paper #2 Discussion Issues: Desirable Characteristics for Key Escrow Agents In the government's recent announcement of its intent to allow the export of 64-bit software key escrow encryption products, one stipulation was that the keys would be escrowed with an approved key escrow agent.(*1) Exactly what qualifications/considerations are appropriate for approval as a key escrow agent have not been defined. Some of the issues which need to be discussed and resolved include the following: * What kinds of organizations should be excluded from consideration as approved key escrow agents? * What sort of legal agreement between the government and the key escrow agent is necessary to stipulate the responsibilities of the agent? Should this include the terms and conditions under which release of a key is required? * How will liability for unauthorized release of key be handled? * Should, for example, intentionally misreleasing or destroying a key be criminalized? Should this include other actions? * How can the government's needs for confidentiality of key release be handled? * Should approval of key escrow agents be tied to a public key infrastructure (for digital signatures and other purposes)? * What procedures need to be developed for the storage and safeguarding of keys? * What are the acceptable performance criteria (e.g., around- the-clock availability, accessibility, reliability, etc.) for approved key escrow agents? * Under what circumstances will key escrow agents in foreign countries be approved? * What process will be used to approve escrow agents? Costs/who pays? --------- (*1) "Approved," for the purposes of this discussion, means that the government (or its agent) has formally granted permission for an organization to hold keys for exportable encryption products. 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. 8/25/95 _________________________________________________________________________ Subject: NIST Key Escrow Papers _________________________________________________________________________ David Banisar (Banisar(a)epic.org) * 202-544-9240 (tel) Electronic Privacy Information Center * 202-547-5482 (fax) 666 Pennsylvania Ave, SE, Suite 301 * HTTP://epic.org Washington, DC 20003 * ftp/gopher/wais cpsr.org

1 0

Security Mailing Lists
by Christopher Klaus 17 Dec '03

17 Dec '03

This was put together to hopefully promote greater awareness of the security lists that already exist. Most security mailing lists have been only announced once and it was only word of mouth that it would acquire new members. This list should hopefully make the membership grow for each mailing list. If you know of any mailing lists that have been skipped, please e-mail cklaus(a)iss.net with the info. The newest updates for this will be on http://iss.net/. This web site also contains info for the following security issues: Vendor security contacts Security Patches What to do if you are compromised Set up Anon ftp securely Sniffers attacks and solutions Security Mailing Lists The following FAQ is a comprehensive list of security mailing lists. These security mailing lists are important tools to network administrators, network security officers, security consultants, and anyone who needs to keep abreast of the most current security information available. General Security Lists * 8lgm (Eight Little Green Men) * Academic-Firewalls * Best of Security * Bugtraq * Computer Privacy Digest (CPD) * Computer Underground Digest (CuD) * Cypherpunks * Cypherpunks-Announce * Firewalls * Intruder Detection Systems * Phrack * PRIVACY Forum * Risks * Sneakers * Virus * Virus Alert Security Products * Tiger * TIS Firewallk Toolkit Vendors and Organizations * CERT * CIAC * HP * Sun ------------------------------------------------------------------------------- 8lgm (Eight Little Green Men) To join, send e-mail to majordomo(a)8lgm.org and, in the text of your message (not the subject line), write: subscribe 8lgm-list Group of hackers that periodically post exploit scripts for various Unix bugs. ------------------------------------------------------------------------------- Academic Firewalls To join, send e-mail to majordomo(a)net.tamu.edu and, in the text of your message (not the subject line), write: SUBSCRIBE Academic-Firewalls This is an unmoderated list maintained by Texas A&M University. Its purpose is to promote the discussion and use of firewalls and other security tools in an academic environment. It is complementary to the Firewalls list maintained by Brent Chapman (send subscription requests to Majordomo(a)GreatCircle.COM) which deals primarily with firewall issues in a commercial environment. Academic environments have different political structures, ethical issues, expectations of privacy and expectations of access. Many documented incidents of cracker intrusions have either originated at or passed through academic institutions. The security at most universities is notoriously lax or even in some cases completely absent. Most institutions don't use firewalls because they either don't care about their institution's security, they feel firewalls are not appropriate or practical, or they don't know the extent to which they are under attack from the Internet. At Texas A&M University we have been using a combination of a flexible packet filter, intrusion detection tools, and Unix security audit utilities for almost two years. We have found that simple firewalls combined with other tools are feasible in an academic environment. Hopefully the discussion on this list will begin to raise the awareness of other institutions also. ------------------------------------------------------------------------------- Best of Security To join, send e-mail to best-of-security-request(a)suburbia.net with the following in the body of the message: subscribe best-of-security REASONS FOR INCEPTION In order to compile the average security administrator it was found that the compiler had to parse a foreboding number of exceptionally noisy and semantically-content-free data sets. This led to exceptionally high load averages and a dramatic increase in core entropy. Further, the number, names and locations of this data appears to change on an almost daily basis; requiring tedious version control on the part of the mental maintainer. Best-of-Security is at present an un-moderated list. That may sound strange given our stated purpose of massive entropy reduction; but because best often equates with "vital" and the moderator doesn't have an MDA habit it is important that material sent to this list be delivered to its subscribers' in as minimal period of time as is (in)humanly possible. If you find *any* information from *any* source (including other mailinglists, newsgroups, conference notes, papers, etc) that fits into one of the acceptable categories described at the end of this document then you should *immediately* send it to "best-of-security(a)suburbia.net". Do not try and predict whether or not someone else will send the item in question to the list in the immediate future. Unless your on a time-delayed mail vector such as polled uucp or the item has already appeared on best-of-security, mail the info to the list! Even if it is a widely deployed peice of information such as a CERT advisory the proceeding argument still applies. If the information hasn't appeared on this list yet, then SEND IT. It is far better to run the risk of minor duplication in exchange for having the information out where it is needed than act conservatively about occasional doubling up on content. ------------------------------------------------------------------------------- Bugtraq To join, send e-mail to LISTSERV(a)NETSPACE.ORG and, in the text of your message (not the subject line), write: SUBSCRIBE BUGTRAQ This list is for *detailed* discussion of UNIX security holes: what they are, how to exploit, and what to do to fix them. This list is not intended to be about cracking systems or exploiting their vunerabilities. It is about defining, recognizing, and preventing use of security holes and risks. Please refrain from posting one-line messages or messages that do not contain any substance that can relate to this list`s charter. Please follow the below guidelines on what kind of information should be posted to the Bugtraq list: * Information on Unix related security holes/backdoors (past and present) * Exploit programs, scripts or detailed processes about the above * Patches, workarounds, fixes * Announcements, advisories or warnings * Ideas, future plans or current works dealing with Unix security * Information material regarding vendor contacts and procedures * Individual experiences in dealing with above vendors or security organizations * Incident advisories or informational reporting ------------------------------------------------------------------------------- Computer Privacy Digest To join, send e-mail to comp-privacy-request(a)uwm.edu and, in the text of your message (not the subject line), write: subscribe cpd The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is run by Leonard P. Levine. It is gatewayed to the USENET newsgroup comp.society.privacy. It is a relatively open (i.e., less tightly moderated) forum, and was established to provide a forum for discussion on the effect of technology on privacy. All too often technology is way ahead of the law and society as it presents us with new devices and applications. Technology can enhance and detract from privacy. ------------------------------------------------------------------------------- Computer Underground Digest To join, send e-mail to LISTSERV(a)VMD.CSO.UIUC.EDU and, in the text of your message (not the subject line), write: SUB CUDIGEST CuD is available as a Usenet newsgroup: comp.society.cu-digest Covers many issues of the computer underground. ------------------------------------------------------------------------------- Cypherpunks To join, send e-mail to majordomo(a)toad.com and, in the text of your message (not the subject line), write: SUBSCRIBE cypherpunks The cypherpunks list is a forum for discussing personal defenses for privacy in the digital domain. It is a high volume mailing list. ------------------------------------------------------------------------------- Cypherpunks Announce To join, send e-mail to majordomo(a)toad.com and, in the text of your message (not the subject line), write: SUBSCRIBE cypherpunks-announce There is an announcements list which is moderated and has low volume. Announcements for physical cypherpunks meetings, new software and important developments will be posted there. ------------------------------------------------------------------------------- Firewalls To join, send e-mail to majordomo(a)greatcircle.com and, in the text of your message (not the subject line), write: SUBSCRIBE firewalls Useful information regarding firewalls and how to implement them for security. This list is for discussions of Internet "firewall" security systems and related issues. It is an outgrowth of the Firewalls BOF session at the Third UNIX Security Symposium in Baltimore on September 15, 1992. ------------------------------------------------------------------------------- Intrusion Detection Systems To join, send e-mail to majordomo(a)uow.edu.au with the following in the body of the message: subscribe ids The list is a forum for discussions on topics related to development of intrusion detection systems. Possible topics include: * techniques used to detect intruders in computer systems and computer networks * audit collection/filtering * subject profiling * knowledge based expert systems * fuzzy logic systems * neural networks * methods used by intruders (known intrusion scenarios) * cert advisories * scripts and tools used by hackers * computer system policies * universal intrusion detection system ------------------------------------------------------------------------------- Phrack To join, send e-mail to phrack(a)well.com and, in the text of your message (not the subject line), write: SUBSCRIBE Phrack Phrack is a Hacker Magazine which deals with phreaking and hacking. ------------------------------------------------------------------------------- PRIVACY Forum To join, send e-mail to privacy-request(a)vortex.com and, in the text of your message (not the subject line), write: information privacy The PRIVACY Forum is run by Lauren Weinstein. He manages it as a rather selectively moderated digest, somewhat akin to RISKS; it spans the full range of both technological and non-technological privacy-related issues (with an emphasis on the former). ------------------------------------------------------------------------------- Risks To join, send e-mail to risks-request(a)csl.sri.com and, in the text of your message (not the subject line), write: SUBSCRIBE Risks is a digest that describes many of the technological risks that happen in today's environment. ------------------------------------------------------------------------------- Sneakers To join, send e-mail to majordomo(a)CS.YALE.EDU and, in the text of your message (not the subject line), write: SUBSCRIBE Sneakers The Sneakers mailing list is for discussion of LEGAL evaluations and experiments in testing various Internet "firewalls" and other TCP/IP network security products. * Vendors are welcome to post challenges to the Internet network security community * Internet users are welcome to post anecdotal experiences regarding (legally) testing the defenses of firewall and security products. * "Above board" organized and/or loosely organized wide area tiger teams (WATTs) can share information, report on their progress or eventual success here. There is a WWW page with instructions on un/subscribing as well as posting, and where notices and pointers to resources (especially if I set up an archive of this list) may be put up from time to time: http://www.cs.yale.edu/HTML/YALE/CS/HyPlans/long-morrow/sneakers.html ------------------------------------------------------------------------------- Virus To join, send e-mail to LISTSERV(a)lehigh.edu and, in the text of your message (not the subject line), write: SUBSCRIBE virus-l your-name It is an electronic mail discussion forum for sharing information and ideas about computer viruses, which is also distributed via the Usenet Netnews as comp.virus. Discussions should include (but not necessarily be limited to): current events (virus sightings), virus prevention (practical and theoretical), and virus related questions/answers. The list is moderated and digested. That means that any message coming in gets sent to me, the editor. I read through the messages and make sure that they adhere to the guidelines of the list (see below) and add them to the next digest. Weekly logs of digests are kept by the LISTSERV (see below for details on how to get them). For those interested in statistics, VIRUS-L is now up to about 2400 direct subscribers. Of those, approximately 10% are local redistribution accounts with an unknown number of readers. In addition, approximately 30,000-40,000 readers read comp.virus on the USENET. ------------------------------------------------------------------------------- Virus Alert To join, send e-mail to LISTSERV(a)lehigh.edu and, in the text of your message (not the subject line), write: SUBSCRIBE valert-l your-name What is VALERT-L? It is an electronic mail discussion forum for sharing urgent virus warnings among other computer users. Postings to VALERT-L are strictly limited to warnings about viruses (e.g., "We here at University/Company X just got hit by virus Y - what should we do?"). Followups to messages on VALERT-L should be done either by private e-mail or to VIRUS-L, a moderated, digested, virus discussion forum also available on this LISTSERV, LISTSERV(a)LEHIGH.EDU. Note that any message sent to VALERT-L will be cross-posted in the next VIRUS-L digest. To preserve the timely nature of such warnings and announcements, the list is moderated on demand (see posting instructions below for more information). What VALERT-L is *not*? A place to to anything other than announce virus infections or warn people about particular computer viruses (symptoms, type of machine which is vulnerable, etc.). ------------------------------------------------------------------------------- Security Products ------------------------------------------------------------------------------- Tiger To join, send e-mail to majordomo(a)net.tamu.edu and, in the text of your message (not the subject line), write: SUBSCRIBE tiger Discussion list for the UNIX security audit tool TIGER This is the TIGER users mailling list. It is for: 1. Update announcements 2. Reporting bugs in TIGER. 3. Discussing new features for TIGER. 4. Discussing use of TIGER. 5. Discussing anything else about TIGER. What is TIGER? TIGER is a set of shell scripts, C code and configuration files which are used to perform a security audit on UNIX systems. The goals for TIGER are to make it very robust and easy to use. TIGER was originally developed for checking hosts at Texas A&M University following a break in in the Fall of 1992. The latest version of TIGER is always available from the directory net.tamu.edu:/pub/security/TAMU. In addition, updated digital signature files for new platforms and new security patches will be maintained in the directory: net.tamu.edu:/pub/security/TAMU/tiger-sigs. ------------------------------------------------------------------------------- TIS Firewall Toolkit To join, send e-mail to fwall-users-request(a)tis.com and, in the text of your message (not the subject line), write: SUBSCRIBE Discussion list for the TIS firewall toolkit ------------------------------------------------------------------------------- Vendors and Organizations ------------------------------------------------------------------------------- CERT (Computer Emergency Response Team) Advisory mailing list. To join, send e-mail to cert(a)cert.org and, in the text of your message (not the subject line), write: I want to be on your mailing list. Past advisories and other information related to computer security are available for anonymous FTP from cert.org (192.88.209.5). ------------------------------------------------------------------------------- The CIAC (Computer Incident Advisory Capability) of DoE CIAC has several self-subscribing mailing lists for electronic publications: 1. CIAC-BULLETIN for Advisories, highest priority - time critical information and Bulletins, important computer security information; 2. CIAC-NOTES for Notes, a collection of computer security articles; 3. SPI-ANNOUNCE for official news about Security Profile Inspector (SPI) software updates, new features, distribution and availability; 4. SPI-NOTES, for discussion of problems and solutions regarding the use of SPI products. To join, send e-mail to ciac-listproc(a)llnl.gov and, in the text of your message (not the subject line), write any of the following examples: subscribe ciac-bulletin LastName, FirstName PhoneNumber subscribe ciac-notes LastName, FirstName PhoneNumber subscribe spi-announce LastName, FirstName PhoneNumber subscribe spi-notes LastName, FirstName PhoneNumber e.g., subscribe ciac-notes O'Hara, Scarlett 404-555-1212 You will receive an acknowledgment containing address, initial PIN, and information on how to change either of them, cancel your subscription, or get help. ------------------------------------------------------------------------------- HP, Hewlett Packard To join, send e-mail to support(a)support.mayfield.hp.com and, in the text of your message (not the subject line), write: subscribe security_info The latest digest of new HP Security Bulletins will be distributed directly to your mailbox on a routine basis. ------------------------------------------------------------------------------- Sun Security Alert To join, send e-mail to security-alert(a)sun.com and, in the subject of your message write: SUBSCRIBE CWS your-email-addr The message body should contain affiliation and contact information. ------------------------------------------------------------------------------- Copyright This paper is Copyright (c) 1995 by Christopher Klaus of Internet Security Systems, Inc. Permission is hereby granted to give away free copies electronically. You may distribute, transfer, or spread this paper electronically. You may not pretend that you wrote it. This copyright notice must be maintained in any copy made. If you wish to reprint the whole or any part of this paper in any other medium excluding electronic medium, please ask the author for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. Address of Author Please send suggestions, updates, and comments to: Christopher Klaus <cklaus(a)iss.net> of Internet Security Systems, Inc. <iss(a)iss.net> Internet Security Systems, Inc. Internet Security Systems, Inc, located in Atlanta, Ga., specializes in the developement of security scanning software tools. Its flagship product, Internet Scanner, is software that learns an organization's network and probes every device on that network for security holes. It is the most comprehensive "attack simulator" available, checking for over 100 security vulnerabilities. -- Christopher William Klaus Voice: (770)441-2531. Fax: (770)441-2431 Internet Security Systems, Inc. "Internet Scanner lets you find 2000 Miller Court West, Norcross, GA 30071 your network security holes Web: http://iss.net/ Email: cklaus(a)iss.net before the hackers do."

1 0

Auto-pgp for pine/elm/tin (fwd)
by P.J. Ponder 17 Dec '03

17 Dec '03

In Garfinkel's book, he talks about the risks of running PGP on a multiuser system where others (sys. admins, eg) have higher levels of authority than you do. I have PGP installed on my pc and if I want to use it, I can save the message in ascii, then upload it to the server where I have my Internet account, then mail it. maybe not entirely transparent, but at least it seems to me that the convenience of running it on the server with something like Mr. Wilcox's BAP is not worth the added risk. Besides, how often do you need to use it? -- pjp ---------- Forwarded message ---------- Date: Fri, 25 Aug 1995 12:03:52 -0400 (EDT) From: Henry W. Farkas <hfarkas(a)ims.advantis.com> To: cypherpunks(a)toad.com Subject: Auto-pgp for pine/elm/tin -----BEGIN PGP SIGNED MESSAGE----- > Does anyone know of an addon to the Pine mailer that supports PGP? > the only PGP software i could find required me to first compose a > letter in an editor then run it through a pgp signature program > then finally read it into my favorite mailer. > > I'm looking for something that is hopefully transparent, or if not > relatively quick to do. > ________________________________________________________________________ > Sameer Manek Seawolf(a)challenger.atc.fhda.edu > ________________________________________________________________________ - ------------------------------------------------------------------------ Yes, it exists, and I'm using it now. I've tried competing products and found this to be the cleanest, smoothest and easiest to install. I have no personal, commercial or financial interest in this product. It does "auto-pgp" for pine, elm and tin. *********************************************************************** * BAP v.1.01 * * Written August 1995 by Bryce Wilcox * * e-mail: <bryce.wilcox(a)colorado.edu> * * PGP key id: <617C6DB9> * * snail mail: <2228 Canyon Blvd, Apt. 1E, Boulder, CO, 80302> * * URL: <http://cs.colorado.edu/~wilcoxb/home.html> * * BETA TEST VERSION! DO NOT DISTRIBUTE! * * (Note that documentation, among other things, is still unfinished.) * *********************************************************************** I also found the author responsive to my comments and suggestions. Just please do *-NOT-* put your pass phrase in a cleartext file! - ------------------------------------------------------------------------ =========================================================================== Henry W. Farkas | Me? Speak for IBM? Fat chance. hfarkas(a)ims.advantis.com |------------------------------------------------ hfarkas(a)vnet.ibm.com | http://newstand.ims.advantis.com/henry henry(a)nhcc.com | http://www.nhcc.com/~henry - --------------------------------------------------------------------------- PGP 6.2.2 Key fingerprint: AA D0 F5 44 C1 8C 11 52 B3 80 34 1C CE 38 EC 53 Public key at: pgp-public-keys(a)pgp.mit.edu, and other popular key servers. - --------------------------------------------------------------------------- Brought to you by Henry's Hardware: Home of the Pretty Good Hack "We're not fast, but it's not bad, and we're cheaper than the guy down the street!" =========================================================================== -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Auto-signed with Bryce's Auto-PGP v1.0beta iQCVAwUBMD30WaDthkLkvrK9AQF6sQP/fVen7ZI4DbgC14y+NPdZYOjaRQ9/jQNT d4StD638OoBRkO7b8efiTd/rNULwuzSPKDiplKwRdE8Bboh4FdSWYvz6wfqgNJcd D3imouQcEt+erjEC2H5haQyZwBHeNNR9mTYhkzoBt4+jMqsRCECduaExyHUOTWFj euOkRqTJ0l4= =2q74 -----END PGP SIGNATURE-----

4 3

SSL CHALLENGE: I told you so....
by monty.harder＠famend.com 17 Dec '03

17 Dec '03

PT> I've been looking at the allocated list of keys, and I notice a possible PT> problem: One user has allocated 50,000 segements: PT> PT> 0c2b-cf7a NOACK 0c2b 50000 Joe Thomas <jthomas(a)ogi.com> -o- PT> I can't contact the server to request keyspace anymore - I get a PT> '500 Server error' PT> PT> It looks like 12 hours on a P5/90 are going to waste (could have done PT> 90 segments) -o- RL> The bottleneck at the server is pretty awful. My clients are spending RL> most of their time in timeout, waiting for keyspace. <rant> As I watch you fumbling for keyspace IN REAL TIME.... This is a great time for me to say "I told you so" WRT the doling of keyspace. It is far better to sign up your volunteers, CHECK THE ALLOCATION, and hand out starting keys, before there is even a challenge to brute. The quad-coverage scheme I outlined before allows sufficient protection against dropouts (whether accidental or malicious), so that a single person who asked for some keyspace, but was unable to actually sweep it, would not hurt the effort. Those who fail to ACK (once it is certain that the client does in fact issue it - should have some parallel means of acking) should have their allocation, based on my evolving formula available_mips = mips * idle_rate * .5**(unacks/sweeps) for the next challenge reduced, reflecting previous unreliability. Set up a sign-up period, add up the total available mips, figure the share that each person should get, and assign keyspace accordingly via direct Imail to each participant. The next level of abstraction is to not only give a start..end and direction, as I previously outlined, but supply a scaling factor in the challenge release. That way, any late entries can automagically be inserted into the keyspace, by squeezing everyone according to the final total of available_mips. Once the proverbial clock is running, there should be no need to discuss who will do what. That is what the huddle is for. Or, to string along the analogy, I guess Steve Young should just go up to the line, take the ball from center, and then give hand signals to Jerry Rice while a 300-pound defensive lineman is zeroing in on him, because the linemen are standing around wondering whom to block. Geez. It would be better not to even have a damned keyserver at all, but to just have everybody pick a random start location, than to do it this way. </rant> * A child said "Mommy, why is the man with the crown naked?" * A child said "Mommy, why is the man with the crown naked?" --- * Monster(a)FAmend.Com *

3 2

Wide Release (Re: PGPfone (BETA TEST) is released)
by anon-remailer＠utopia.hacktic.nl 17 Dec '03

17 Dec '03

ftp host: net-dist.mit.edu, AKA bitsy.mit.edu 220 bitsy FTP server (Version wu-2.4(1) Thu Apr 14 20:21:35 EDT 1994) ready. USER ftp 331 Guest login ok, send your complete e-mail address as password. PASS ***** 230-Welcome, archive user! This is an experimental FTP server. If have any 230-unusual problems, please report them via e-mail to ftp-bugs@bitsy 230-If you do have problems, please try using a dash (-) as the first character 230-of your password -- this will turn off the continuation messages that may 230-be confusing your ftp client. 230- 230-Please read the file README 230- it was last modified on Sat May 28 19:19:36 1988 - 2643 days ago 230 Guest login ok, access restrictions apply. PWD 257 "/" is current directory. MACB E 500 'MACB E': command not understood. TYPE A 200 Type set to A. CWD /pub/PGPfone 250-Please read the file README 250- it was last modified on Fri Aug 25 15:52:05 1995 - 0 days ago 250 CWD command successful. PORT 199,117,100,36,7,146 200 PORT command successful. LIST 150 Opening ASCII mode data connection for /bin/ls. total 29 -r--r--r-- 1 0 1001 4287 Aug 25 15:52 README drwxr-x--- 4 1 27 512 Aug 25 17:00 dist -r--r--r-- 1 0 1001 2172 Aug 24 22:02 mitlicen.txt -r--r--r-- 1 0 1001 19546 Aug 24 23:43 rsalicen.txt 226 Transfer complete. CWD /pub/PGPfone/dist 250 CWD command successful. PORT 199,117,100,36,4,177 200 PORT command successful. LIST 150 Opening ASCII mode data connection for /bin/ls. total 2 drwxr-xr-x 2 435 27 512 Aug 25 15:24 U.S.-only-XXXX drwxrwxr-x 2 0 27 512 Aug 25 15:13 secret99 226 Transfer complete. CWD /pub/PGPfone/dist/secret99 250 CWD command successful. PORT 199,117,100,36,7,178 200 PORT command successful. LIST 150 Opening ASCII mode data connection for /bin/ls. total 2271 -r--r--r-- 1 0 27 764444 Aug 25 15:12 PGPfone10.sea.Hqx -r--r--r-- 1 0 27 751220 Aug 25 12:50 PGPfone10.sea.Hqx.OLD -r--r--r-- 1 0 27 750964 Aug 24 23:30 PGPfone10.sea.Hqx.OLDER -r--r--r-- 1 0 27 2172 Aug 24 22:02 mitlicen.txt -r--r--r-- 1 0 27 19546 Aug 24 23:43 rsalicen.txt 226 Transfer complete. CWD /pub/PGPfone/dist/U.S.-only-XXXX 250 CWD command successful. PORT 199,117,100,36,6,161 200 PORT command successful. LIST 150 Opening ASCII mode data connection for /bin/ls. total 760 -r--r--r-- 1 0 27 764444 Aug 25 15:12 PGPfone10.sea.Hqx 226 Transfer complete.

3 3

Re: ADMIN: You might not be on the list anymore!
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 2:14 AM 8/26/95, Robert A. Hayden wrote: >I administrate several mailing lists. Bounce as of late have gotten so >bade, especially from AOL, C$erv, etc (and I expect soon from MSN.COM) >that I also just nuke the person out of hand. It's better in the long >run :-) I agree. Kill them all. God will know his own. --Tim the Impaler (I'm seeing bounces on all Compuserve addresses for the simple Cypherpunks Santa Cruz I administer manually.) ---------:---------:---------:---------:---------:---------:---------:---- 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."

1 0

John Walker releases encrypting Speak Freely/Netfone
by John Gilmore 17 Dec '03

17 Dec '03

[John lives in Switzerland and renounced his US citizenship, so there's no export issue...] Date: Wed, 23 Aug 1995 07:14:10 -0400 Forwarded-by: farber(a)central.cis.upenn.edu (David Farber) From: John Walker <kelvin(a)fourmilab.ch> Subject: Free secure Internet voice communication I've just released to the public domain Release 5 of Speak Freely for Windows and its Unix counterpart, Netfone for Sun and Silicon Graphics workstations. Assuming you have a fast enough connection to the Internet (with reasonably consistent packet delivery time) and/or a fast enough CPU to perform audio compression in real time, you can talk to anybody on Earth connected to the Internet who's also running the program. The Windows and Unix versions have entirely different user interfaces, but can intercommunicate. Complete source code is available. For communications security, IDEA, DES (less initial and final permutations), and one-time pad (re-used for each sound packet) encryption are available. The intensely paranoid can enable any combination of these. The documentation explains how to use PGP to securely exchange session keys before a conversation; an automatic session key generator is provided. DES is included for commercial users who don't have a license to use the IDEA patent. One-time pad encryption is for those with machines too slow to run IDEA or DES in real time. I didn't include a public key mechanism because I wanted to avoid all the confusion. If somebody wants to navigate the narrow strait between the RSA patent Scylla and Charybdis of export controls, the programming work to implement public keys is straightforward and the source code is yours to hack. For further information, see: http://www.fourmilab.ch/netfone/windows/speak_freely.html which describes the Windows version in detail and contains pointers to the Sun and SGI editions, as well as links to download source code and a ready-to-run executable for Windows. You can also obtain the program by anonymous binary FTP: Unix source code: ftp://ftp.fourmilab.ch/pub/kelvin/netfone/netfone5.tar.gz Windows executable: ftp://ftp.fourmilab.ch/pub/kelvin/netfone/windows/speakfb.zip Windows source code (for Visual C 1.5): ftp://ftp.fourmilab.ch/pub/kelvin/netfone/windows/speakfs.zip The Sun and SGI versions of this program are quite stable, and should work for just about anybody with an adequate network connection. Porting the code to other Unix workstations with audio hardware should be relatively straightforward. The Windows version has just been finished and until it's shaken down on a variety of machines, networks, sound cards, etc. may not work for everybody. The Windows version requires a sound card with Windows Multimedia drivers (I've tested it on a variety of Sound Blasters of various generations) and a TCP/IP stack that supports WINSOCK (I'm using NetManage Chameleon NFS). Since multimedia and network hardware and drivers vary tremendously from machine to machine, I wouldn't be surprised if some tweaking were needed for various configurations. The CPU speed required interacts with the speed of your network connection; if you have a high-bandwidth connection to the Internet, or you're talking to another person on a high-speed LAN, there's no need to compress sound and the CPU load is minimal; just about any machine will do. If you need to compress in order to squeeze 8000 samples per second into a dial-up connection, then you need a CPU fast enough to run GSM compression in real time: basically we're talking a very fast 486 or Pentium. If you turn on IDEA and/or DES encryption, that also consumes CPU time. Based on my experience with other Windows programs, it will probably take months to track down misbehaviour due to strange hardware and software configurations. Complete, detailed bug reports are welcome. I may not be able to respond individually, but the Web page will track updates as they're released. I have tested the program only on vanilla 16 bit Windows 3.1. The Windows version contains preliminary code to support direct dial-up modem connections, acting as a phone scrambler. Serial port support in most Windows machines is so poor (unless you have a 16550A UART and appropriate drivers, which most people don't) that this feature isn't usable at present. I've left the code in just in case somebody with suitable hardware wants to bash it into working form. If you add features, port the program to 32 bits, fix bugs, etc., let me know so I can make your contributions generally available. -------------------- <http://www.fourmilab.ch/> ------------------- John Walker | A sufficiently advanced Internet: kelvin(a)fourmilab.ch | technology is indistinguishable | from a rigged demo.

1 0