- cypherpunks-legacy@lists.ogf.org

Re: (fwd'd) more Clipper inside?
by Jason Zions 01 Sep '93

01 Sep '93

Warning: rampant paranoia inside. >Check this out. >Clipper inside the Apple get you bothered? >How about Clipper inside all UNICES ? (all POSICES) Not bloody likely, for several dozen reasons. Most importantly, POSIX does not, indeed cannot, specify implementation. All it does is specify interfaces. That is, POSIX could define a standard API which accepts a clear-text message and some form of secure identification for a user and produces an authentication string which can be used by a recipient of that message to verify that it was sent by that user. The standard cannot state "You must use MD5" or "You must use Clipper". POSIX also produces "Profiles", which are standards that point at other standards. A profile might say "When the message-auth function is provided, it shall use MD5 as its mechanism." Another profile might say "When the message-auth function is provided, it shall use PGP." A customer would tell a vendor "I want to buy a system that conforms to the profile that says use Clipper for authentication." Other customers would tell that same vendor "I want to buy a system that conforms to the profile that says use PGP for authentication." The base POSIX standard is neutral on the issue. Competing profiles take stands on the issue. Customers buy systems that conform to profiles that match their own stand on the issue. The only way Clipper will appear in all POSIX-conforming systems is if one of the following events occur: 1) Only one profile is ever written, one that specified Clipper for message authentication and encryption. 2) Customers tell their vendors they want the Clipper profile and don't tell their vendors they want any other profile. Event (1) is pretty bloody unlikely. POSIX standards groups have substantial international involvement; there are enough people from enough countries where Clipper is recognized as stupid that other profiles will appear. Besides, given a profile that requires Clipper, I can generate a profile that requires PGP in about a day's work that will fly through ballot. Event (2) is the one you have to watch out for. Here, though, it's a case of the sheep going meekly to slaughter, which is what cypherpunks aim to stop anyway. Upshot: POSIX is a weak tool in the hands of the Clipper camp; don't sweat it. ] Cryptographic Services ] ]One proposal has been received, form NIST, which outlines interfaces for ]several areas of cryptographic services: user cryptographic database ]management, secret key cryptography services, and public key cryptography ]services. The secret key services include encryption and data integrity, ]as well as key management. The public key services include encryption ]and digital signatures, as well as key management. The proposal will ]be included in the POSIX mailing and will be discussed at the October meeting. ]Another proposal may be submitted by the October meeting and will also ]be discussed. Any additional proposals for crytpographic services will ]also be entertained. Looks like APIs to me. I suspect there will be substantial opposition to *all* cryptographic API standards from vendors, simply because they know that the f-ing US Government, in the person of the Commerce Department, will then tell them they cannot export those APIs and the mechanisms under them. There's no point in standardizing something when you can't sell it to more than half of your customers. All you have to do is figure out how to use a more positive cryptographic engine (like PGP) with each of the APIs that get defined; we push a profile, and we're done. Jason Zions Chair, IEEE P1003.8 POSIX Transparent File Access Note: I am speaking solely for myself. This is not an official statement of IEEE or any entity thereof.

1 0

Re: PGP: question
by peter honeyman 01 Sep '93

01 Sep '93

if you ask me, limiting $PGPPATH to length 50 is a bug (albeit most likely benign). peter

2 1

Able was I ere I saw Elba
by nobody＠alumni.cco.caltech.edu 01 Sep '93

01 Sep '93

Have recently heard from an official of the Advanced Logistical Planning board of the city of Plano TX. (near Dallas) vogon(a)alp.plano.gov Something about a proposed hyperspace bypass ...... Napoleon --ignore--

1 0

Mitch Ratcliffe's article re AOCE
by greg＠ideath.goldenbear.com 01 Sep '93

01 Sep '93

I received a nice message today from Mitch Ratcliffe (I misspelled his name in my earlier post to C-punks) re my posting of the sidebars from his AOCE article. I'm not forwarding his E-mail as I was raised to consider that impolite :), but feel safe in summarizing thus: 1. There are a number of weaknesses in AOCE, but it is also a step forward in some senses. Discussion/elaboration of these weaknesses is precluded by space limitations of MacWeek, as well as other trade or mainstream magazines. 2. Editing for space accounts for some lack of detail in the sidebars; they are also intended for a general audience. Mitch suggests Apple as a source of further technical information re AOCE, and mentions a talk given by Gursharan Sidhu at the Apple Worldwide Developers' Conference in May, in which Sidhu suggests the government should be able to crack a system's security in some cases. Sidhu is the technical director of collaboration systems development at Apple. Mitch's e-mail address is godsdog(a)netcom.com; I've written back asking for clarification about other points raised in the article. -- Greg Broiles greg(a)goldenbear.com Golden Bear Computer Consulting +1 503 342 7982 Box 12005 Eugene OR 97440 BBS: +1 503 687 7764

2 1

(fwd'd) more Clipper inside?
by cme＠ellisun.sw.stratus.com 01 Sep '93

01 Sep '93

Check this out. Clipper inside the Apple get you bothered? How about Clipper inside all UNICES ? (all POSICES) Sorry if this is a repeat for folks.. - Carl Date: Mon, 30 Aug 1993 10:03:00 EDT Reply-To: TC11-I IFIP TC11 Global information <TC11-I(a)HEARN.nic.SURFnet.nl> Sender: TC11-I IFIP TC11 Global information <TC11-I(a)HEARN.nic.SURFnet.nl> From: Ambuel(a)DOCKMASTER.NCSC.MIL Subject: Call for Participation - POSIX Security Group X-To: tc11-i(a)HEARN.NIC.SURFNET.NL X-Cc: smaha(a)DOCKMASTER.NCSC.MIL, snapp(a)DOCKMASTER.NCSC.MIL, emery(a)D74SUN.MITRE.ORG, tsig(a)WDL1.WDL.LORAL.COM, wbr(a)MITRE.ORG, chang(a)ST1.NCSL.NIST.GIV, p1003.6(a)PERCH.NOSC.MIL, p1003.22(a)PERCH.NOSC.MIL, tc11(a)CIPHER.NL To: Multiple recipients of list TC11-I <TC11-I(a)HEARN.nic.SURFnet.nl> Status: RO _____________________________________________ Call for Participation The POSIX security working group will be concentrating on several new areas of security functionality at the October 18 meeting in Bethesda, Maryland. The group believes that these areas must be completed in order for the defined interfaces in P1003.6.1 and P1003.6.2 to be fully useful. These new areas include: Identification and Authentication Services Portable Data Formats Cryptographic Services Administrative Services Identification and Authentication Services POSIX 1003.1 and 1003.2 provide little functionality in the areas of identification and authentication. The security working group believes that services for identifying users and authenticating those identities is essential for protecting resources within a system. One proposal, from ICL, has been received to date on this subject. It will be distributed in the POSIX mailing and will be discussed at the October meeting. In addition, distributed issues of identification and authentication will be discussed so that a resulting standard will accommodate distributed identification and authentication technology. Any additional proposals for identification and authentication services will also be entertained. Portable Data Formats POSIX 1003.6.1 has defined several interfaces to create and manipulate security-related data items - access control lists, labels, capabilities, and audit records. However, the data items are not described to the level of detail necessary to use them in a portable way. For true application portability the format of these data items must be known. One proposal has been received, from Haystack Laboratories, for a common audit trail interchange format. This proposal will be included in the POSIX mailing and will be discussed at the October meeting. Any additional proposals for portable data formats will also be entertained. Cryptographic Services One proposal has been received, form NIST, which outlines interfaces for several areas of cryptographic services: user cryptographic database management, secret key cryptography services, and public key cryptography services. The secret key services include encryption and data integrity, as well as key management. The public key services include encryption and digital signatures, as well as key management. The proposal will be included in the POSIX mailing and will be discussed at the October meeting. Another proposal may be submitted by the October meeting and will also be discussed. Any additional proposals for crytpographic services will also be entertained. Administrative Services The security working group met with the administrative services working group (P1003.7) to discuss what interfaces and utilities need to be defined to provide portable application writers with a standard method for administering security-related data items. The original scope of P1003.6 excluded this functionality because P1003.1 and P1003.2 excluded this functionality. However, these utilites and functions are essential for application writers to provide truly portable applications. Any proposals in this areas are encouraged and will be discussed at the October meeting. Proposals in these, or other, security-related areas are welcome and can be mailed to the chair for enclosure in the POSIX mailing and the agenda for the meeting. This will allow members of the working group to review the proposal and be prepared for discussion at the meeting. Proposals will also be accepted at the meeting, but only in written form. This makes it more likely that a proposal has been thought out and keeps discussion focused on a tangible document. In order to plan for the agenda for the working group meeting, please forward your name, email address, area of interest, and expected duration that you will be at the Bethesda meeting. Addresses for the chair are listed below. The hope is that a large group will be available for discussion all week, but sometimes that is not quite reality. If you can only attend a few days, or would like to present something on a specific day, please provide that inforamtion and the agenda will be created accordingly. Questions and written proposals can be sent to the chair in any of the following ways: U.S. Mail: Lynne Ambuel Attn: I94 Department of Defense Fort G.G. Meade, MD 20755-6000 Internet: Ambuel @ dockmaster.ncsc.mil FAX: (410) 850-7166

2 1

Adv Pgm: 1st ACM Conf. on Computer and Communications Security
by remail＠tamsun.tamu.edu 01 Sep '93

01 Sep '93

***** 1st ACM Conference on Computer and Communications Security ****** Nov 3-5 1993, Fairfax, Virginia Sponsor: ACM SIGSAC Hosts: Bell Atlantic and George Mason U In cooperation and participation from: International Association of Cryptologic Research IEEE Communications Society TC on Network Operations and Management IEEE Computer Society TC on Security and Privacy Washington DC Chapter ACM CONFERENCE HIGHLIGHTS: We invite your participation in this exciting new conference whose purpose is to bring together researchers and practitioners of computer and communications security. Our program offers a unique blend of cryptography and security theory and practice, with emphasis on the practical. The conference will be held in the Holiday Inn, Fair Oaks, in Fairfax, Virginia; minutes from the Nation's Capital. We welcome you to enjoy an informative and invigorating program, and Washington's pleasant mid-fall sight-seeing weather. Registration form and hotel information: --------------------------------------- Is given at the end, or can be obtained from George Mason University at: Ph\#: +1 703-993-2090, Fax\#: +1 703-993-2112, email: acmccs93\(a)isse.gmu.edu ADVANCE TECHNICAL PROGRAM (subject to change) =============================================== November 3rd ------------ Welcome (Dorothy Denning & Ray Pyle) Session: Applications-1 (Ravi Sandhu) - Does Licensing require new Access Control Techniques? (Ralf Hauser) - A Cryptographic File System for UNIX (Matt Blaze) - A Particular Solution to Provide Secure Communication in an Ethernet environment (Jordi Forne, Miguel Soriano, Jose Melus and Francisco Recacha) Session: Cryptographic Protocols - 1 (Michael Weiner) - Lower Bounds on Messages and Rounds for Network Authentication Protocols (Li Gong) - Optimality of Multi-Domain Protocols (Raphael Yahalom) - On Simple and Secure Key Distribution (Gene Tsudik and Els Van Herreweghen) Session: Digital Signatures (Ravi Ganesan) - The History of RSA -- Invited Talk (Ronald Rivest) - A New Signature Scheme Based on the DSA Giving Message Recovery (Kaisa Nyberg and Rainer Rueppel) - Random Oracles are Practical: A Paradigm for Designing Efficient Protocols (Mihir Bellare and Phillip Rogaway) - Sorting Out Signature Schemes (Birgit Pfitzmann) Session: Legal and Policy Issues (Richard Graveman) - Avoiding Cryptographic Information Anarchy in Enterprises: Invited Talk (Donn Parker) - Digital Signatures: Can They Be Accepted As Legal Signatures in EDI? (Patrick Brown) Session: Short Talks (Virgil Gligor) - Design of the Commercial Data Masking Facility (CDMF) Data Privacy Algorithm (Don Johnson, Stephen Matyas, An Le and John Wilkins) - Adding Time to a Logic of Authentication (Paul Syverson) - NetCash: A design for practical electronic currency on the Internet (Gennady Medvinsky and Clifford Neuman) - Considerations for Security in Personal Communications Systems (PCS) (Dan Brown) - A Framework for Distributed Authorization (Thomas Woo and Simon Lam) November 4th ------------ Session: Multilevel and Database (Carl Landwehr) - A Pump for Rapid, Reliable, Secure Communication (Myong Kang and Ira Moskowitz) - Authorizations in Relational Data Base Mgmt. Systems (Elisa Bertino, Pierangela Samarati and Sushil Jajodia) - High Assurance Discretionary Access Control for Object Bases (Elisa Bertino, Pierangela Samarati and Sushil Jajodia) Session: Applications - 2 (Victoria Ashby) - Denial of Service - Invited Talk (Roger Needham) - Analysis of an Algorithm for Distributed Recognition and Accountability (Terrance Goan, Deborah Frincke, Calvin Ko, Todd heberlein, Karl Levitt, Biswanath Mukherjee and Chris Wee) - Integration of DCE and Local Registries (Ping Lin) Session: Cryptology (Rainer Rueppel) - Multiple Encryption and the Economics of DES - Invited Talk (Whitfield Diffie) - Systematic Generation of Cryptographically Robust S-boxes (Jennifer Seberry, Xian-Mo Zhang and Yuliang Zheng) - Differential Cryptanalysis of Hash Functions Based on a Block Cipher (Bart Preneel) - Verifiable Secret Sharing for Monotone Access Structures (Marcus Otten, Han-Joachim Knobloch and Thomas Beth) Session: Telecommunications Security (Ravi Ganesan) - Securing a Global Village and its Resources: Baseline Security for Interconnected Signaling System 7 Telecommunications Networks - Invited Talk (Hank Kluepfel) - Panel: How Secure is the Public Switched Network? November 5th ------------ Session: Reliability of Security Systems (Ravi Sandhu) - Cryptanalysis and Protocol Failure - Invited Talk (Gustavus Simmons) - Why Cryptosystems Fail (Ross Anderson) - Panel: How to Engineer Reliable Security Session: Cryptgraphic Protocols - 2 (Yacov Yacobi) - Towards Practical `Proven Secure' Authenticated Key Distribution (Yvo Desmedt and Mike Burmester) - Applying Formal Analysis Techniques to Authenticated Diffie-Hellman Protocols (Paul Van Oorschot) - Augmented Encrypted Key Exchange: A Password-Based Protocol Secure Against Dictionary Attacks and Password File Compromise (Steve Bellovin and Michael Merritt) ****************************** General Chairs Program Committee -------------- ----------------- Dorothy Denning Victoria Ashby (MITRE) (Georgetown University) Steve Bellovin (Bell Labs) Whitfield Diffie (Sun) Raymond Pyle Taher El Gamal (Oki Data) (Bell Atlantic) Deborah Estrin (USC) Joan Feigenbaum (Bell Labs) Program Chairs Virgil Gligor (U. Maryland) -------------- Li Gong (SRI) Richard Graveman (Bellcore) Ravi Ganesan Sushil Jajodia (GMU) (Bell Atlantic) Paul Karger (GTE) Carl Landwehr (NRL) Ravi Sandhu E. Stewart Lee (U. Toronto) (George Mason University) Giancarlo Martella (U. Milan) Michael Merritt (Bell Labs) Invited Speakers Jonathan Millen (MITRE) ---------------- Clifford Neuman (USC ISI) Whitfield Diffie (Sun) Steven Rudich (CMU) Hank Kluepfel (Bellcore) Rainer Rueppel (R3 Sec. Eng.) Roger Needham (Cambridge U) Eugene Spafford (Purdue U) Donn Parker (SRI) Jacques Stern (DMI-GRECC) Ronald Rivest (MIT) Michael Wiener (BNR) Gustavus Simmons Yacov Yacobi (Bellcore) ****** 1st ACM Conference on Computer and Communications Security ******* Nov 3-5 1993, Fairfax, Virginia REGISTRATION FORM Mail or fax (+1 703-993-2112) this form to: ACMCCS '93 Registration Center for Professional Development-Business Office George Mason University Fairfax, VA 22030-4444 REGISTRATION CONTACT: Diane Waters, GMU (Phone: +1 703-993-2090, fax: +1 703-993-2112) NAME: AFFILIATION: ADDRESS: Phone: Fax: ACM/IEEE Member Number: Special Meal Requirements: Kosher Vegetarian REGISTRATION FEE: (Circle one) ACM/IEEE Member $300 (before 10/1/93) $325 (after 10/1/93) Non-Members $360 (before 10/1/93) $400 (after 10/1/93) Students $100 $100 Fees include continental breakfast (11/3-5), lunch (11/3-4) and banquet (11/4). Student fee is restricted to full-time students, or part-time students who are unemployed. In either case an advisor's endorsement is required. Advisor Name and Signature: Make checks or money orders payable, in US currency, to GMU/ACMCCS'93 Payment can also be made by purchase order (US organizations only) or credit card (Visa or Mastercard only). Cirle one of: VISA Mastercard Card No: Expiration: Name on Card: Signature: HOTEL: Holiday Inn at Fair Oaks, Phone: +1 703 352 2525, Fax: +1 703 352 4771 Rate: $69 (single/double) available until Oct 12 Mention 'ACM Security Conference' to get this rate

1 0

Encryption policies of Fidnet, etc.
by remail＠tamsun.tamu.edu 31 Aug '93

31 Aug '93

Forwarded from alt.cyberspace: ------------------------------ ->> Joseph T Dickinson was mumbling something about Encryption <<- JTD> It is illegal to encrypt messages period. JTD> E-mail encryption is illegal Depends on your network and where you live. It is illegal to use PGP in the United States due to its use of a copyrighted algoritm. It is *NOT* illegal to use it anywhere else in the world. Other encryption methods are legal. In Fidonet (the largest *amatuer* mail network), it is against policy to encrypt 'echomail' (Fido version of newsgroups), but perfectly acceptable to encrypt *direct* netmail (Fido email delivered directly to the recieving system without regard to its location). Routed netmail (email passed from system to system before eventually arriving at its destination) may be encrypted provided each sysop whose node the message passes through agrees that the message may be encrypted, otherwise, it has to be sent en claire. On RIME (Relaynet International Mail Exchange, the *2nd* largest amatuer run network), email is regularly encrypted as part of the networking and routing software in use by the network. Sending routed, reciever-only mail is not only common, but *encouraged*, since it cuts down on the overhead of the other systems in the net. You'd have to look at the network's topology to see why; it's basically a 'tree' formation in which nodes at the bottom feed their newsgroups up to the topstars and recieve them from the topstars. Keven ... Get the facts first - you can distort them later! ___ Blue Wave/QWK v2.12

1 0

Re: What's wrong with PEM?
by cme＠ellisun.sw.stratus.com 31 Aug '93

31 Aug '93

-----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 2001,MIC-CLEAR Originator-Name: cme(a)ellisun.sw.stratus.com Originator-Key-Asymmetric: MIGbMAoGBFUIAQECAgP+A4GMADCBiAKBgCl79/jl0DEVl1GQzOHlzjDmChDDxnWO Acd7jShj2x1vclFh6vbHx9IJqkQdwNhNAWf8XnTrqBDN+VSBc1qdT6nSEAbNPxHD XcvY2DudhuRaRBVLgUQ4scTK657m90Q+bTL5yIh2MaFipUw9BgbIXPTDlksSskWP 9oHjo+pCJC+lAgMBAAE= MIC-Info: RSA-MD5,RSA, D6p2f/wP8D4TOg3vWp7JGoGdKw4iL3bQeSFiany6kDNAdS8Tt65pSqb99zUpBN7v 13Cu+LQhS0OA0jpyv+/DpkdjiW3GgECX05YkfIzd4iOF0CI/76pPoV65hIgdi5ze tcnBn6hr/fcBUByM+nWp0BIi/tApWp1xl/iEUOBiuwU= >Message-Id: <9308311508.AA08669(a)newton.apple.com> >Date: Tue, 31 Aug 1993 08:08:33 -0800 >From: collins(a)newton.apple.com (Scott Collins) Hi Scott. I think you have PEM right -- except that there's RIPEM which does file encryption/decryption just like PGP. I've built a shell script for my mailer (Mail) which invokes either RIPEM or my own secret key algorithm so it's a bit more convenient. Once I get purchased PGP, I'll add PGP to that list. I hope to use the same key for PGP and RIPEM. (1024 bit RSA). - <<Disclaimer: All opinions expressed are my own, of course.>> - Carl Ellison cme(a)sw.stratus.com - Stratus Computer Inc. M3-2-BKW TEL: (508)460-2783 - 55 Fairbanks Boulevard ; Marlborough MA 01752-1298 FAX: (508)624-7488 - -----BEGIN RIPEM PUBLIC KEY----- User: cme(a)ellisun.sw.stratus.com PublicKeyInfo: MIGbMAoGBFUIAQECAgP+A4GMADCBiAKBgCl79/jl0DEVl1GQzOHlzjDmChDDxnWO Acd7jShj2x1vclFh6vbHx9IJqkQdwNhNAWf8XnTrqBDN+VSBc1qdT6nSEAbNPxHD XcvY2DudhuRaRBVLgUQ4scTK657m90Q+bTL5yIh2MaFipUw9BgbIXPTDlksSskWP 9oHjo+pCJC+lAgMBAAE= MD5OfPublicKey: 39D9860686A9F075A9A83D49589C677A - -----END RIPEM PUBLIC KEY----- -----END PRIVACY-ENHANCED MESSAGE-----

1 0

Re: anonymous mail
by markh＠wimsey.bc.ca 31 Aug '93

31 Aug '93

> PEM, on the other hand, reveals in the clear who signed the message, outside > of the encrypted portion. Also note that to be PEM compliant, you *must* > always sign your messages. So much for anonymous encrypted messages... There are also performance concerns here. There is no reason to take the substantial amount of time it takes to sign, if you don't want to sign a message. On the other hand, in terms of anonymity, you can always generate a self-signed key with TIS/PEM (I forget the exact term they use in the TIS/PEM docs, but you can just make yourself a certificate which doesn't really say anything about your identity). -- Mark Henderson markh(a)wimsey.bc.ca (personal account) RIPEM key available by key server/finger/E-mail MD5OfPublicKey: F1F5F0C3984CBEAF3889ADAFA2437433

1 0

article in Science News
by bill＠twwells.com 31 Aug '93

31 Aug '93

For those into such things, it might be worthwhile to check out the articles on the last page of Science News, Vol. 144, No. 9, August 28, 1993. Interesting tidbits are "...computer scientist Dorothy E. Denning..." and mention of the panel that evaluated SKIPJACK. (Isn't Denning a lawyer turned ersatz cryptography expert? Or do I have her confused with some other "expert"?)

1 1