September 1993 - cypherpunks-legacy@lists.ogf.org

NSA response to EFF Clipper Q's
by L. Detweiler 02 Sep '93

02 Sep '93

An EFF Online newsletter previously reported highlights from a list of questions submitted to the NIST/NSA regarding Clipper. That entire document is now available on ftp.eff.org in pub/EFF/legislation/clipper-answers. It makes reference to attachments on chip specifications that are not present in the text file. Overall, the document has rather numerous typographical errors for a government document, and it's unclear whether this is the result of the EFF scanning or whether they are in the original document. Also, at this point in the swift-moving arena, the responses are fairly dated, coming out long before the close of the expert review of the algorithm and a CSSPAB meeting at the end of July. Items in this review of the Clipper comments: - encryption regulation - constitutionality - Mycotronx, VLSI rationale, history of Clipper - Presidential directive & review procedure - key escrow in software - history of Skipjack - identification information in key escrow databases - notes on wiretap protocol - NSA cryptographic control wish list - Capstone capabilities - policy review - Clipper: a status report Encryption Regulation --- The major revelation in this document as reported here previously is the statement that the Administration has progressed far enough in the `policy review' to determine that `regulating private encryption' would be `imprudent' and `drastic' and that no new legilsation will be proposed to `limituse of encryption technology'. Unfortunately, in the characteristically maddening bureacratic doublespeak of the NSA, the previous statements suggest that this is the case only `because these measures may be sufficient to make key escrow encryption [widespread]'. Nevertheless the statement is extremely significant given various ominous sound bites in the media that suggested very clearly that cryptographic regulation was definitely `on the table' for consideration. Constitutionality --- The other major revelations as reported in the EFF document are the explicit attention to constitutional issues. However, the response is not very meaningful except to deny that any are relevant. In particular, it does not indicate the constitutionality of any enforcement or regulation in the area. >The key escrow technology only ensures that government agencies, will be >able to decrypt intercepted communications when lawfully authorized. It >neither expands nor contracts federal, state or local law enforcement >authority to access and decrypt communications. The key escrow technology >simply assures the continued feasibility of lawful electronic surveillance >under statutes that have long since been determined to be constitutional. Mostly the document is just a reformulation of the following idea in various ways: >it became clear >that a strategy was needed that could accommodate the needs of the private >sector for top notch communications security; of U.S. industry to remain >competitive in the world's secure communications market; and of U.S. law >enforcement to conduct lawfully-authorized electronic surveillance. Clearly, the writers' favorite words are `authorized' and `lawful' and here we are doubly reassured. Mycotronx, VLSI --- Here are a few other significant details in the response. For the first time there is official confirmation that the proposal goes back far previous to the Clinton administration: >The logic design contract for the microcircuit was awarded to MYKOTRONIX, >Inc. of Torrance, California, in late 1991 Mykotronx was chosen because: >This company provided a >unique combination of (i) expertise to quickly design custom cryptographic >chips, (ii) secure facilities, and (iii) the cleared personnel (At the TOP >SECRET level) necessary for the successful execution of the contract >requirements. Which makes me wonder. Has anyone with any serious sway in the NSA noticed the stolen Mycotronx documents yet? I would love to see the response to an FOIA inquiry on this one. Do they care? Did any heads roll at Mycotronx? >VLSI Technology of San Jose, California, was chosen as the chip foundry >based primarily on its technological capabilities to fabricate >microcircuits resistant to reverse engineering Selection of the vendors was >in accordance with U.S. government rules for sole source procurement. >other manufacturers that wish to enter the market and can satisfy the >technology and security requirements will be approved to manufacture these >microcircuits. Here we have the highly implausible suggestion that other companies will be considered to manufacture the microcircuits. Fat chance. Presidential Directive --- The document gives more detail about the Presidential Review Directive and Presidential Decision Directive behind Clipper. >The PRD called for interagency studies examining a number >of issues including, for example, the impact of the key escrow strategy and >the feasibility of implementing the key escrow technique in software. >Another issue to be addressed in the course of the review is the impact of >advanced telecommunications on law enforcement. While analogous in the >sense that both encryption and advanced telecommunications technology can >impede the effectiveness of authorized law enforcement electronic >surveillance, the two technologies present different issues and are being >treated separately. The results of the reviews are expected early this >fall. Hence, the `feasibility of implementing the key escrow technique in software' is `under review.' Later in the document, we have the point: >Because software is easy to change, secure software implementations of the >key escrow technique have been difficult to devise. We would welcome the >participation of the software industry in a cooperative effort to meet this >technical challenge. of course, users may continue to use existing >software encryption products. I don't recommend cooperating with the NSA in trying to devise `secure software' -- first of all, the suggestion that they will even have `security' in chip hardware is a fantasy and illusion; secondly, software is inherently free and unchained and nothing the NSA invents can ever change that; thirdly, cooperating with the NSA can be hazardous to one's economic health; and finally, probably no one in the NSA seriously believes that secure software implementations are possible, and are just throwing this out for cynical effect. Skipjack --- Information on SKIPJACK, confirming suggestions by some (e.g. A. Walker on sci.crypt) that the algorithm is based on earlier defense-oriented schemes in a long line of development: >Was the encryption algorithm specifically designed for the key escrow >initiative? > >No. The algorithm chosen for the key escrow microcircuit was originally >developed by NSA for use in U.S. government communications systems, albeit >not in the management of our nuclear arsenal as some have speculated. >Essentially the same cryptographic technology was under government >development and analysis for more than ten years. Although NSA does not >comment on the details of its design and analysis, the algorithm has >undergone intense expert scrutiny comparable to that used in the analysis >of cryptography intended for classified government systems. While the >algorithm was originally developed for unclassified defense systems, it >will be considered for certain classified applications in the future. Key Escrow Databases --- What about identification associated with keys in the databases? The NSA is in a catch-22 here. If there is nothing but serial numbers in a database, how do the key escrow agencies ensure that key IDs requested for wiretapping are associated with the given entities named in warrants? If they are present, how could such a scheme be maintained in anything other than an Orwellian Totalitarian Dystopia? The following is the first explicit commitment to total lack of identification information in the databases: >Some have expressed concerns that personal information could be contained >in the key escrow databases. The only information held by a key escrow >agent will be the chip serial numbers and the key component associated with >that number. Since the information in the key escrow databases will not be >associated with any particular individual, the database would be of no use >in identifying individuals or otherwise obtaining personal information >about them. Therefore, a key escrow agent will have no information about >the person owning or using equipment containing a microcircuit for which it >holds keys. Requests for a key component will be for a particular chip >identification number. No information regarding the identity of the target >of the authorized electronic surveillance will be provided to the key >escrow agents. Wiretap Protocol --- Interestingly, they say that when a wiretapped device is moved to a new phone number, they don't have the authority to tap it any longer: >If the subject of A surveillance were to move the device to another >location (and another telephone number), law enforcement authorities could >not legally monitor communications at other locations. This is because, as >noted above, electronic surveillance of wire or electronic communications >must be directed at some identifiable telephone, cellular telephone, or >computer facility. Therefore, before law enforcement authorities can >legally monitor any other telephone number in an effort to locate the >subject's encryption device, they must first satisfy a court that there is >probable cause to believe that illegal communications will occur over that >line. Major criticism is based on the fact that once a given key has been released, a phone is forever in the future insecure. For the first time we have the assurance >As added protection, law enforcement will have access to a key only so long >as it has authority to conduct a surveillance. Systems are being designed >to ensure that keys are destroyed when the authority to conduct a >particular electronic surveillance has expired. NSA wish list --- We get a wish list of realms in which the NSA would like to control domestic cryptography: >Concerns have been expressed about use of this key escrow technology and >these chips, in particular, across the panoply of new emerging >technologies, such as ISDN, TDMA, Cellular, CDMA Cellular, ATM, SONET, >SMDS, etc. Don't forget PEM -- D.D. gets really excited about that one. >It impossible to design key escrow encryption techniques that >are almost totally transparent to the system, given the transmission media >together with its propagation characteristics. Optimally, the system >should be designed with the encryption, if possible. The government intends >to work cooperatively with industry toward this end. Yes, just what every cryptography company wants, their personal NSA consultant breathing down their circuits. Capstone Capabilities --- Here's some notes on Capstone. Most capabilities also indicated by D.D. in her writings: >In addition to the key escrow technology contained in the >encryption-only chip, the enhanced chip also includes a Digital Signature >Algorithm proposed by NIST as a FIPS; a Secure Hashing Algorithm (SHA) >recently approved as FIPS 180; a Key Exchange Algorithm based on a public >key exchange, a general purpose exponentiation algorithm; and a general >purpose, random number generator which uses a pure noise source. This chip >is now being considered for installation in PCMCIA electronic cards and for >use in the Defense Messaging System. Personally, I wonder if the NSA intends to phase out Clipper from the beginning. The implementation could encrypt the law enforcement field under that more low-level chip. The Capstone chip will be the NSA's little `black box' miracle in every machine. Policy Review --- Finally, there are the indications that the `policy review' done in the Fall will cover the exportability of key escrow and the future cryptographic export control policy in the country concerning `marketability and foreign competition'. While everyone is desperate for a breakthrough here, the likely announcement will be that `no export restrictions will be placed on Clipper' and since the technology is completely suitable for all cryptographic applications (smirk) no other cryptographic devices will be approved for export. That's my guess, anyway. Clipper: a status report --- Current progress report on Clipper: the most serious hurdles for the NSA right now are imposing the Clipper FIPS standard and the DSA patent arrangement with PKP. The NSA has long demonstrated its complete obliviousness and imperviousness to public opinion no matter how loud or negative (consider early DSS endorsement). However, for the previous two standards, it has reached unprecedentedly screeching levels. The government will find it *extremely* difficult to go ahead with either in the face of almost uniformly hostile reception to both. Doing so is likely to raise a much larger outcry and warrant more desperate approaches on the side of the opposition (ala Zimmermann's `guerilla cryptography'). The future revelations in the DSS, Clipper, and `policy review' topics will be critical in indicating whether the NSA will take a more low-key and unobtrusive stance in regulation of domestic cryptography, with the original Clipper announcment its boldest step ever, or whether it will become even more paranoid and volatile in attempting to control and strangle natural, evolving domestic cryptographic developments. If you value your freedom, pray for the former.

1 0

general purpose telnet bouncer.
by Mark 02 Sep '93

02 Sep '93

Several people have expressed interest in a utility such as this. It's existed for several years but Ive recently decided to fix it up into a releasable condition. Share and enjoy. flames to /dev/null Mark mark(a)cairo.anu.edu.au ---------------------- cut here ---------------------------- /* Name: ts2.c */ /* Author: Hal-9000, Richard Stevens, Xanadude, Avalon, Mark */ /* Distribution: Public */ /* Copyright: Held by the respective contributors */ /* Posted to USENET 1st September '93 by Mark mark(a)cairo.anu.edu.au */ /* This file was telserv.c, part of the Telnet Server package v. 1.0, written by "Hal-9000". Much of that package was developed by Richard Stephens and his thanks go to "Xanadude" for providing him with that section. Performance fix by Darren Reed. */ /* Reworked to add concurrency, password checking and destination selection on the fly. - Mark 31st Aug 93 Compiled and tested on: HPUX 9.01 9000/700 series NeXTStep 3.1 NeXT 68040 OSx Pyramid 90x BSD universe SunOS 5.2 sun4c Ultrix 4.3 DEC RISC To compile, type "cc -O -s ts2.c -o ts2". MY_PASSWORD and SERV_TCP_PORT are all that is required to be altered. */ #define MY_PASSWORD "pass" #define SERV_TCP_PORT 12345 /* port I'll listen for connections on */ #include <stdio.h> #include <sys/types.h> #include <sys/socket.h> #include <sys/time.h> #include <sys/resource.h> #include <sys/wait.h> #include <fcntl.h> #include <errno.h> #include <netinet/in.h> #include <netdb.h> #include <arpa/inet.h> #include <sys/ioctl.h> #define QLEN 5 char sbuf[2048], cbuf[2048]; extern int errno; extern char *sys_errlist[]; void reaper(); int main(); void telcli(); int main(argc, argv) int argc; char *argv[]; { int srv_fd, rem_fd, rem_len, opt = 1; struct sockaddr_in rem_addr, srv_addr; bzero((char *) &rem_addr, sizeof(rem_addr)); bzero((char *) &srv_addr, sizeof(srv_addr)); srv_addr.sin_family = AF_INET; srv_addr.sin_addr.s_addr = htonl(INADDR_ANY); srv_addr.sin_port = htons(SERV_TCP_PORT); srv_fd = socket(PF_INET, SOCK_STREAM, 0); if (bind(srv_fd, (struct sockaddr *) &srv_addr, sizeof(srv_addr)) == -1) { perror("bind"); exit(-1); } listen(srv_fd, QLEN); close(0); close(1); close(2); #ifdef TIOCNOTTY if ((rem_fd = open("/dev/tty", O_RDWR)) >= 0) { ioctl(rem_fd, TIOCNOTTY, (char *)0); close(rem_fd); } #endif if (fork()) exit(0); while (1) { rem_len = sizeof(rem_addr); rem_fd=accept(srv_fd, (struct sockaddr *) &rem_addr, &rem_len); if (rem_fd < 0) { if (errno == EINTR) continue; exit(-1); } switch(fork()) { case 0: /* child process */ close(srv_fd); /* close original socket */ telcli(rem_fd); /* process the request */ close(rem_fd); exit(0); break; default: close(rem_fd); /* parent process */ if (fork()) exit(0); /* let init worry about children */ break; case -1: fprintf(stderr, "\n\rfork: %s\n\r", sys_errlist[errno]); break; } } } void telcli(source) int source; { int dest; int found; struct sockaddr_in sa; struct hostent *hp; struct servent *sp; char gethost[100]; char getport[100]; char string[100]; bzero(gethost, 100); sprintf(string, "Password: "); write(source, string, strlen(string)); read(source, gethost, 100); gethost[(strlen(gethost)-2)] = '\0'; /* kludge alert - kill the \r\n */ if (strcmp(gethost, MY_PASSWORD) != 0) { sprintf(string, "Wrong password, got %s.\n", gethost); write(source, string, strlen(string)); close(source); exit(0); } do { found = 0; bzero(gethost,100); sprintf(string, "Host: "); write(source, string, strlen(string)); read(source, gethost, 100); gethost[(strlen(gethost)-2)] = '\0'; hp = gethostbyname(gethost); if (hp) { found++; #if !defined(h_addr) /* In 4.3, this is a #define */ #if defined(hpux) || defined(NeXT) || defined(ultrix) || defined(POSIX) memcpy((caddr_t)&sa.sin_addr, hp->h_addr_list[0], hp->h_length); #else bcopy(hp->h_addr_list[0], &sa.sin_addr, hp->h_length); #endif #else /* defined(h_addr) */ #if defined(hpux) || defined(NeXT) || defined(ultrix) || defined(POSIX) memcpy((caddr_t)&sa.sin_addr, hp->h_addr, hp->h_length); #else bcopy(hp->h_addr, &sa.sin_addr, hp->h_length); #endif #endif /* defined(h_addr) */ sprintf(string, "Found address for %s\n", hp->h_name); write(source, string, strlen(string)); } else { if (inet_addr(gethost) == -1) { found = 0; sprintf(string, "Didnt find address for %s\n", gethost); write(source, string, strlen(string)); } else { found++; sa.sin_addr.s_addr = inet_addr(gethost); } } } while (!found); sa.sin_family = AF_INET; sprintf(string, "Port: "); write(source, string, strlen(string)); read(source, getport, 100); gethost[(strlen(getport)-2)] = '\0'; sa.sin_port = htons((unsigned) atoi(getport)); if (sa.sin_port == 0) { sp = getservbyname(getport, "tcp"); if (sp) sa.sin_port = sp->s_port; else { sprintf(string, "%s: bad port number\n", getport); write(source, string, strlen(string)); return; } } sprintf(string, "Trying %s...\n", (char *) inet_ntoa(sa.sin_addr)); write(source, string, strlen(string)); if ((dest = socket(AF_INET, SOCK_STREAM, 0)) < 0) { perror("telcli: socket"); exit(1); } connect(dest, (struct sockaddr *) &sa, sizeof(sa)); sprintf(string, "Connected to %s port %d...\n", inet_ntoa(sa.sin_addr), ntohs(sa.sin_port)); write(source, string, strlen(string)); #ifdef FNDELAY fcntl(source,F_SETFL,fcntl(source,F_GETFL,0)|FNDELAY); fcntl(dest,F_SETFL,fcntl(dest,F_GETFL,0)|FNDELAY); #else fcntl(source,F_SETFL,O_NDELAY); fcntl(dest,F_SETFL,O_NDELAY); #endif communicate(dest,source); close(dest); exit(0); } communicate(sfd,cfd) { char *chead, *ctail, *shead, *stail; int num, nfd, spos, cpos; extern int errno; fd_set rd, wr; chead = ctail = cbuf; cpos = 0; shead = stail = sbuf; spos = 0; while (1) { FD_ZERO(&rd); FD_ZERO(&wr); if (spos < sizeof(sbuf)-1) FD_SET(sfd, &rd); if (ctail > chead) FD_SET(sfd, &wr); if (cpos < sizeof(cbuf)-1) FD_SET(cfd, &rd); if (stail > shead) FD_SET(cfd, &wr); nfd = select(256, &rd, &wr, 0, 0); if (nfd <= 0) continue; if (FD_ISSET(sfd, &rd)) { num=read(sfd,stail,sizeof(sbuf)-spos); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num==0) return; if (num>0) { spos += num; stail += num; if (!--nfd) continue; } } if (FD_ISSET(cfd, &rd)) { num=read(cfd,ctail,sizeof(cbuf)-cpos); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num==0) return; if (num>0) { cpos += num; ctail += num; if (!--nfd) continue; } } if (FD_ISSET(sfd, &wr)) { num=write(sfd,chead,ctail-chead); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num>0) { chead += num; if (chead == ctail) { chead = ctail = cbuf; cpos = 0; } if (!--nfd) continue; } } if (FD_ISSET(cfd, &wr)) { num=write(cfd,shead,stail-shead); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num>0) { shead += num; if (shead == stail) { shead = stail = sbuf; spos = 0; } if (!--nfd) continue; } } } } ----------- end of file ------ cut here -------

1 0

Info Security News article on Clipper (fwd)
by Anonymous 02 Sep '93

02 Sep '93

Info Security News Volume 4, Number 5 September/October 1993 page 14 --- D.C. Dateline --- New Crypto Standards in Contention by Charlotte Adams Experts are hotly debating the Clipper initiative, a plan to standardize on a voice-encryption device with built-in law-enforcement access. Although de facto or mandatory acceptance of Clipper or similar hardware now seems remote, the potential cost of such action makes it worth considering. The rationale for Clipper was to maintain the government's information-eavesdropping capability as the use of encryption spreads. The hope was that the market would follow the government's lead, making Clipper the de facto standard. The National Institute of Standards and Technology sees benefits in making Clipper the accepted standard. "If we deny [criminals] the use of the national communications net, [that's a] nontrivial accomplishment," says Ray Kammer, NIST's acting director. If the network standard is Clipper, he reasons, criminals would "have to set up their own [communications] system, an interesting and formidible task." NIST is pushing ahead with a proposed Escrowed Encryption Standard. If all goes well, this Federal Information Processing Standard could be in place by October, an important step toward widespread use by the federal government. The key-escrow mechanism should be in place by autumn, government sources say. A related issue is NIST's Digital Signature Standard, which was developed in secret by the National Security Agency. NIST added a new issue to the DSS debate last summer when the agency announced a proposed settlement with Public Key Partners giving PKP control over commercial use of the standard. Clipper pros and cons. The key-escrow concept, allowing access to law-enforcment agencies, will have to become mandatory because it makes no sense on a voluntary basis, critics say. "It clearly has implications for data transmission, as well," says Phil Karn of Qualcomm, a San Diego maker of cellular telephones. Government contractors, in fact, are already fine-tuning another chip, called Capstone, which will be much more convenient for data-security applications. Capstone will add the NIST's secure hash, digital signature and key-exchange algorithms to Clipper's Skipjack encryption algorithm and escrow support. "Clipper is good for voice, for telephony, but not as a coprocessor inside a PC, selectively encrypting fields," says Richard Ankney, a technical consultant with Fischer International Systems Corp. "Capstone is better in that regard." The trouble with Capstone is that it is big and expensive, a full custom, very-large scale-integration ciruit design, says John Droge, vice president of program development for chip designer, Mykotronx Inc., of Torrance, Calif. VLSI Technology Inc., in San Jose, is actually fabricating the chip. Mykotronx expects the chips initially to sell at $100 apiece in quantities of 10,000. PCMCIA (Personal Computer Memory Card International Association) cards initially will sell in the $300 range, he predicts. That's a far cry from the government's $100 target price for the PCMCIA module. If the hardware becomes mandatory, space would have to be found for the chips inside notebooks and palmtops, as well as in laptop and desktop computers. Estimates on the markup to customers vary from 25 to 200 percent. The cost of retrofitting Clipper or Capstone into existing machines would be tremendous, says Fred Gluck, director of marketing for control products with Datamedia Corp., a Nashua, N.H. security software and token vendor. Simply multiply the $25 to $30 per half-hour you pay for technical people times the 100 million or so PCs out there, he says. But much of the cost may be hidden from the end user, Ankney counters. "You could take the hit and not raise the price at all." The Digital Signature Standard. Although eclipsed by the Clipper controversy, DSS nevertheless remains an issue. Even though its algorithm is not secret, NSA "played a very dominant role" in creating it, says David Sobel, legal counsel for the Computer Professionals for Social Responsibilty. The secrecy surrounding NSA's role in DSS goes beyond the will of Congress in the Computer Security Act of 1987 for the "[standards] development process to be open and accountable," Sobel says. The PKP angle is also a problem, CPSR says. The arrangement by which NIST allows PKP to control commercial use of the Digital Signature Standard "really comes down to ... almost paying them off," says Marc Rotenberg, director of CPSR's Washington office. People shouldn't read too much into the proposal, NIST says. "It means ... the government wants to move on and get this out of the way ... without any acknowledgement of [the validity of the PKP] infringement action," explains F. Lynn McNulty, NIST's associate director for computer security. The "big payoff" of the proposed agreement is that individual citizens communicating with the government won't have to pay royalties, he says. More information needed. Almost everyone agrees that more information is necessary before a policy decision can be made. "Are we talking about completely revamping the communications infrastructure to facilitate 800 wiretaps?" asks Daniel Weitzner, senior counsel for the Electronic Frontier Foundation. EFF coordinates the activities of the Digital Privacy and Security Working Group, a coalition of information security technology companies and non-profit groups that has raised many questions about Clipper. "We want a real, solid understanding of the problems from [the administration's] perspective and a fact-based risk assessment," Weitzner says. NIST's own security and privacy advisory panel refused to rubberstamp the Clipper initiative at first sight and various interest groups have demanded a more thoughtful and open review. The Digital Privacy and Security Working Group has been asked to contribute substantively to the ongoing interagency crypto policy review, EFF's Weitzner says. CPSR, however, is forming its own policy review group. The administration's approach of taking outside imput is still essentially a closed process, CPSR says. "The point we're trying to make [is that] the public has an interest in its privacy and consumers have an interest in what they ultimately might end up paying, " Rotenberg says. ---------------------------------------- Charlotte Adams is a free-lance journalist covering technology issues in the Washington D.C. area for a variety of magazines. Copyright (c) 1993 by MIS Training Institute Press, Inc. Ye olde Spooge Meister spooge /spooj/ 1. Inexplicable or arcane code <spooge(a)dev.null.net> or random and probably incorrect output from a computer program.

1 0

[EVENTS]: security related
by jet＠netcom.com 02 Sep '93

02 Sep '93

[marginal interest to this list. -eric] Last update: 08/31/93 COMPUTER SECURITY EVENTS CALENDAR This file contains a list of upcoming computer security events. The absence or inclusion of any particular event does not imply criticism or endorsement by the National Institute of Standards and Technology or the sysop. Because of the nature of this material and how it is obtained, it is impossible to include every event. If you know of computer security events that are not listed, please send the conference/course literature to the following: Lawrence B. Keys National Institute of Standards and Technology Room A-216, Bldg. 225 Gaithersburg, MD 20899 DATE: 09/09/93 TITLE: 3rd International Virus Bulletin Conference LOCATION: Amsterdam SPONSOR: CONTACT: Editor, Virus Bulletin ADDRESS: 21 The Quadrant, Abingdon Science Park CITY_ST: Abingdon, OX14 3YS, UK PHONE: +44 (0)235 559935 DATE: 09/15/93 TITLE: Information Warfare Conference LOCATION: Montreal, CANADA SPONSOR: National Computer Security Association CONTACT: Michael E. Kabay, Ph.D. ADDRESS: P.O. Box 509 CITY_ST: Westmount, QC/H3Z2T6 CANADA PHONE: 514-931-6187 DATE: 09/20/93 TITLE: 16th National Computer Security Conference LOCATION: Baltimore, MD SPONSOR: NCSC and NIST CONTACT: NCSC, Attn: NCS Conference Secretary, AS11 ADDRESS: National Computer Security Center CITY_ST: Fort George G. Meade, MD 20755-6000 PHONE: (410) 850-0272 DATE: 10/04/93 TITLE: 4th USENIX UNIX Security Symposium LOCATION: Santa Clara, CA SPONSOR: USENIX Association CONTACT: USENIX Conference Office ADDRESS: 22672 Lambert Street, Suite 613 CITY_ST: El Toro, CA 92630 PHONE: (714) 588-8649 DATE: 10/04/93 TITLE: 13th Conference on Control, Audit & Security of Information Sys. LOCATION: Boston, MA SPONSOR: MIS Training Institute CONTACT: MIS Registration ADDRESS: 498 Concord St. CITY_ST: Framingham, MA 01701-2357 PHONE: (508) 879-7999 DATE: 10/04/93 TITLE: 2nd Annual Pacific Conference on Information Systems Auditing LOCATION: Seattle, WA SPONSOR: EDP Auditors Association & CANAUDIT Inc. CONTACT: CANAUDIT Inc. ADDRESS: P.O. Box 4150 CITY_ST: Simi Valley, CA 93093 PHONE: (805) 583-3723 DATE: 10/04/93 TITLE: Information Security Principles and Practices LOCATION: Fairfax, VA SPONSOR: Center for Professional Development (Gerorge Mason University) CONTACT: Catherine M. Hoover ADDRESS: Center for Professional Development (George Mason University) CITY_ST: Fairfax, VA 22030-4444 PHONE: (703) 993-2090 DATE: 10/04/93 TITLE: Recent Developments in Information Security LOCATION: Fairfax, VA SPONSOR: Center for Professional Development (George Mason University) CONTACT: Catherine M. Hoover ADDRESS: Center for Professional Development (George Mason University) CITY_ST: Fairfax, VA 22030-4444 PHONE: (703) 993-2090 DATE: 10/12/93 TITLE: UNIX Security LOCATION: Fairfax, VA SPONSOR: Center for Professional Development (George Mason University) CONTACT: Catherine M. Hoover ADDRESS: Center for Professional Development (George Mason University) CITY_ST: Fairfax, VA 22030-4444 PHONE: (703) 993-2090 DATE: 10/20/93 TITLE: 10th World Conference on Computer Security, Audit & Control LOCATION: Westminster, London, UK SPONSOR: Compsec International CONTACT: Karen Giles ADDRESS: Elsevier Advanced Technology, Mayfield House, 256 Banbury Road CITY_ST: Oxford OX2 7BR, United Kingdom PHONE: +44 (0) 865 512242 DATE: 10/25/93 TITLE: Protecting Networks and Small Systems LOCATION: Gaithersburg, MD SPONSOR: CSI, Hosted by NIST (gov. employees/contractors only) CONTACT: CSI Conference Registration ADDRESS: 600 Harrison St. CITY_ST: San Francisco, CA 94107 PHONE: (415) 905-2626 DATE: 10/28/93 TITLE: Building Information Security Awareness LOCATION: Gaithersburg, MD SPONSOR: CSI, Hosted by NIST (gov. employees/contractors only) CONTACT: CSI Confrence Registration ADDRESS: 600 Harrison St. CITY_ST: San Francisco, CA 94107 PHONE: (415) 905-2626 DATE: 11/01/93 TITLE: 7th USENIX Systems Administration Conference (LISA VII) LOCATION: Monterey, CA SPONSOR: USENIX CONTACT: USENIX Conference Office ADDRESS: 22672 Lambert St., Suite 613 CITY_ST: Lake Forest, CA 92630 PHONE: (714) 588-8649 DATE: 11/03/93 TITLE: 1st ACM Conference on Computer and Communications Security LOCATION: Fairfax, VA SPONSOR: Bell Atlantic & George Mason University CONTACT: Ravi Ganesan ADDRESS: Bell Atlantic, 7th floor, 11720 Beltsville Dr. CITY_ST: Beltsville, MD 20705 PHONE: (301) 595-8439 DATE: 11/08/93 TITLE: 20th Annual Computer Security Conference & Exhibition LOCATION: Anaheim, CA SPONSOR: Computer Security Institute CONTACT: CSI Conference Registration ADDRESS: 600 Harrison St. CITY_ST: San Francisco, CA 94107 PHONE: (415) 905-2626 DATE: 12/01/93 TITLE: 4th Annual EICAR Conference LOCATION: St. Alabans, Hertfordshire, ENGLAND SPONSOR: Eicar CONTACT: Ms. Allison Sweeney ADDRESS: S&S International Ltd., Berkley Ct. Mill St. CITY_ST: Berkhamsted, Herts, HP2 4HW, England PHONE: +44 442 877877 DATE: 12/06/93 TITLE: 9th Annual Computer Security Applications Conference LOCATION: Orlando, FL SPONSOR: Aerospace Computer Security Association CONTACT: Dr. Ronald Gove ADDRESS: Booz-Allen & Hamilton, 8283 Greenboro Drive CITY_ST: McLean, VA 22102 PHONE: (703) 902-5280 DATE: 01/04/94 TITLE: 4th IFIP Working Conference on Dependable Computing for Critical LOCATION: San Diego, CA Applications SPONSOR: IFIP Working Group CONTACT: Dr. Gerard Le Lann, INRIA -Project REFLECS ADDRESS: BP 105 CITY_ST: 78153 Le Chesnay Cedex, FRANCE PHONE: + (33) 1 39 63 53 64 DATE: 02/04/94 TITLE: Internet Society Symposium on Network and Distributed Sys. Sec. LOCATION: San Diego, CA SPONSOR: Internet Society CONTACT: Robert W. Shirey, MS Z202 ADDRESS: Mitre Corp. CITY_ST: McLean, VA 22102-3481 PHONE: (703) 883-5397 DATE: 05/17/94 TITLE: 6th Annual Canadian Computer Security Symposium LOCATION: The Ottawa Congress Centre SPONSOR: The Canadian System Security Centre (Government of Canada) CONTACT: Karen Lowther ADDRESS: Canaian System Security Center, P.O. Box 9703, Terminal CITY_ST: Ottawa, Ontario K1G 3Z4 PHONE: (613) 991-7513 DATE: 06/14/94 TITLE: IEEE Computer Security Foundations Workshop VII LOCATION: Franconia, NH SPONSOR: IEEE Computer Society CONTACT: Ravi S. Sandhu ADDRESS: ISSE Department, George Mason University CITY_ST: Fairfax, VA 22030-4444 PHONE: (703) 993-1659 DATE: 10/04/94 TITLE: 1st European Dependable Computing Conference LOCATION: Berlin, GERMANY SPONSOR: Joint Technical Interest Group CONTACT: Erik Maehle, University of Paderborn/FB14 ADDRESS: Warburgerstr. 100 CITY_ST: D-W-4790 Paderborn GERMANY PHONE: ++49 (5251) 602209

1 0

Non-Cash Schemes -- precedent?
by collins＠newton.apple.com 01 Sep '93

01 Sep '93

This mornings (1 Sep 93) Wall Street Journal, page B2, Enterprise column: "'Scrip' ATMs Appeal to Growing Number of Retailers". The artical describes retailers who are installing ATM machines that hand out 'scrip', deducted from a clients account, for use in the stores. Less attractive to thieves, cheaper to build and maintain. A physical precedent for digital schemes ? Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins(a)newton.apple.com Apple Computer, Inc. 1 Infinite Loop, MS 301-2C Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst(a)netcom.com

1 0

Re: Encryption policies of Fidnet, etc.
by Jason Zions 01 Sep '93

01 Sep '93

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. Jeez, talk about misinformation. If it were copyright, then a US copyright is indeed restrictive world-wide; that's the point of the Berne Convention. However, it's not copyright; it's pretty tought to copyright an algorithm, all one can do is copyright the exact expression of one implementation of that algorithm. What's involved here is a patent, which is (as you note) not binding outside the US. Finally, is it certain that PGP indeed infringes on a valid patent? >... Get the facts first - you can distort them later! Ah. This explains much. Jason

5 5

anonymous mail
by remail＠tamsun.tamu.edu 01 Sep '93

01 Sep '93

PEM also reveals who signs messages, even when the message is encrypted. In other words, if I send you a PGP encrypted message which I also signed, the signature is hidden under the encryption. You do not know who sent you the PGP message (assuming a cypherpunks remailer or equivalent was used) until after you decrypt the first "packet" and gaze inside. 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 is something to be said for the PGP encapsulated approach...

3 2

Re: NY TAXES CYBERSPACE, CRAM REACTS
by Jason Zions 01 Sep '93

01 Sep '93

Y'know, a two-paragraph summary in calm tones, followed by the text of the tax notice, would have been more effecitve; breathless hyperbole turns some people off. In any event, I see no reference to retroactivity. At worst, if someone paid an annual fee, tax is owed only on the prorated portion of services to be rendered after September 1. That is, if someone paid $30 on January 1 for one year's service, tax is owed only on the "unused" $10 covering Sept 1 through December 31. This is relatively clear from the wording regarding "service to be rendered after...". Yes, it's monumentally stupid. You think you got it bad? I can't believe the brokerage houses on Wall Street let this one go; NYSE ticker feeds are covered by this, as are all generic reuseable information feeds, which means transmission of credit reports and the like. This is gonna jack up most things related to the US finance industry, especially NYSE and large arbitrage. I left New York State years ago; seems the state's IQ really *did* get stupider after I left. :-) Jason

2 1

Re: Encryption policies of Fidnet, etc.
by doug＠netcom4.netcom.com 01 Sep '93

01 Sep '93

khijol!erc(a)apple.com (Ed Carp) said: >I hate to jump into the fray, but according to Public Key Partners, if you >use RSA for educational, (etc.) purposes, you are not infringing on their >patent. > It has long been held that there is an exemption to 'patent infringment' >for educational or other "non-commercial" uses. Hmm. I would love to interpret this as meaning that I can freely use their technology in freeware software that I write for and release to the net. However there would seem to be reason to doubt this. ;-) Any opinions on how much/how little one could get away with on such things? Would it make a difference if the piece of software were intended for a focused education/research area (say groupware research) rather than being highly general (as a mailer is)? I'm less familiar with patent exemptions than copyright exemptions, so this is all somewhat opaque to me. And there's always the old issue of whether someone will be motivated to sue you, and whether you want to spend time & money on defense, quite aside from the hypothetical legality or illegality that might eventually be established. Urk. Doug

1 0

Re: NY TAXES CYBERSPACE, CRAM REACTS
by plmoses＠unix.cc.emory.edu 01 Sep '93

01 Sep '93

Arguably the NY tax is a violation of the Commerce Clause of the Constitution. Is the state's local interest more compelling than the burden this law places on interstate commerce? Doubtful. Paul

1 0