From: rtregn@immd3.informatik.uni_erlangen.de (Robert Regn) 24-FEB-1989 23:11:22 To: misc-security@decwrl.dec.com Subj: [361] Want programs from P. Wood and S. Kochan I would like to get the programs in the appendix of "Unix system security" form P. Wood and S. Kochan (Hayden Books). But the written mail addresses {ihnp4|harpo}!bellcore!phw5!secure are no more valid. Can someone - send me these programs or - give the new mail address ?? Thanks Robert Regn rtregn@faui32.uucp rtregn@immd3.informatik.uni-erlangen.de From: 34AEJ7D@CMUVM.BITNET 24-FEB-1989 23:23:24 To: Security Digest Subj: [728] Re: Friction is your friend >This thinking can be applied to numerous other types of locks including ... Along these same lines, not long ago an individual received a certain dubious notoriety for picking the "impossible to crack" (press term, not mine) locks securing coin-operated public telephones. Is *anything* really "impossible to crack"? I may be wrong, but this sounds to me like another case of media hype surrounding a breach of relatively poor security. Yes? No? Maybe? [Moderator add-on: Yes, the "pay phone thief" was discussed at length around a year ago. Nobody ever really knew if it was for real. I can dig up the old msgs if anyone's *really* interested, but without real facts, further arm-waving about it is discouraged... _H*] From: Stephen Crawley 24-FEB-1989 23:30:03 To: security@rutgers.edu Subj: [1205] Re: Zero knowledge passwords? > At least you know you've been had, and can get off > and back on and change your (just-compromised) passsword. That of course assumes that you are alert! A typical user logs in with his/her brains in neutral. Anyhow, it is not enough to protect you against a more sophisticated attack. A year or so back, users of the Cambridge University Computing Service were hit by a password grabber which infested the BBC Micros used as terminals. This program passed through all data in both directions, and kept a record in RAM of the characters that users typed in response to certain prompts (like "Password: "). > And the really good ones are set up so that each invocation of the > login process gives you an authentication at the conclusion of > your login (or maybe at your logout). When you login again, > after you give your userid and before you give your password, > the login processor gives you its authentication counter-sign. That doesn't work either. If there is a possibility of someone EITHER tampering with your terminal OR eavesdropping on your comm's system, you must have an authentication scheme that uses encrypted timestamps and challenges to get secure login. -- Steve From: Tony Ivanov 24-FEB-1989 23:50:10 To: misc-security@tektronix.tek.com Subj: [2128] Password encryption...want feedback. [Moderator note: Please reply to him directly...] Hello out there! I have developed a UN*X lookalike encryption algorithm that does not have the eight character password limit. I am interested in critisism/comments on weak/strong points. Here it is: /* * tcrypt - generate hashing encryption * This function performs an encryption that produces hashed passwords that * look like the ones produced by the UN*X algorithm. The major difference * is that it allows input passwords of unlimited length (as opposed to the * UN*X algorithm which only uses the first eight characters). * * SYNOPSIS: * char *tcrypt (key, salt) * char *key, *salt; */ # define tcrypt_char(a) (_tcrypt_char[((int)a)&63]) char _tcrypt_char[] = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789./"; char * tcrypt (key, salt) char *key; char *salt; { static char buff[14]; /* Buffer to hold encrypted password. */ char *pb; /* Pointer into buffer. */ char *pk; /* Pointer into key (unencrypted password). */ char tmp; /* Value from last encryption loop. */ char s; /* Alternates between first and second character of salt. */ int size_key; /* Length of the key. */ int count; /* Loop variable. */ /* Set up initial conditions. */ strcpy (buff, "Initial_value"); pk = key; tmp = 0; size_key = strlen(key); /* Repeatedly encryt buffer. */ for (count=0; count < 100; count++) /* Re-encrypt passwd this many times. */ { s = salt[count&1]; for (pb=buff; pb < buff+14; pb++) { tmp = *pb = tcrypt_char ( *pb + *pk + s + tmp + ((*pk + s) >> (1+(count&1))) + (pk-key) ); pk++; if (pk >= key+size_key) pk = key; } } /* Set first two characters to the salt, and terminate string. */ buff[0] = salt[0]; buff[1] = salt[1]; buff[13] = '\0'; return (buff); } -- /* My opinions... * Tony Ivanov MS-4B * ...ucbvax! */ /* shared by my company?!... * Grass Valley Group, Inc. * tektronix! */ /* you've got to be kidding! * P.O. Box 1114 * gvgpsa! */ /* "tony@gvgpvd.GVG.TEK.COM" * Grass Valley, CA 95945 * gvgpvd!tony */ From: AMSTerDamn System 25-FEB-1989 0:01:04 To: dlists/amsterdamn.dl@andrew.cmu.edu Subj: [6301] Amsterdamn Vol IV 16 [ Via AMSTerDamn v2.1A ] [ with AMS-auto3.2D/SAM2A/AMSv2A ] From: bee@PURDUE.EDU Subject: Viruses and System Security (a story) The following story was posted in news.sysadmin recently. The more things change, the more they stay the same... Back in the mid-1970s, several of the system support staff at Motorola (I believe it was) discovered a relatively simple way to crack system security on the Xerox CP-V timesharing system (or it may have been CP-V's predecessor UTS). Through a simple programming strategy, it was possible for a user program to trick the system into running a portion of the program in "master mode" (supervisor state), in which memory protection does not apply. The program could then poke a large value into its "privilege level" byte (normally write-protected) and could then proceed to bypass all levels of security within the file-management system, patch the system monitor, and do numerous other interesting things. In short, the barn door was wide open. Motorola quite properly reported this problem to XEROX via an official "level 1 SIDR" (a bug report with a perceived urgency of "needs to be fixed yesterday"). Because the text of each SIDR was entered into a database that could be viewed by quite a number of people, Motorola followed the approved procedure: they simply reported the problem as "Security SIDR", and attached all of the necessary documentation, ways-to-reproduce, etc. separately. Xerox apparently sat on the problem... they either didn't acknowledge the severity of the problem, or didn't assign the necessary operating-system-staff resources to develop and distribute an official patch. Time passed (months, as I recall). The Motorola guys pestered their Xerox field-support rep, to no avail. Finally they decided to take Direct Action, to demonstrate to Xerox management just how easily the system could be cracked, and just how thoroughly the system security systems could be subverted. They dug around through the operating-system listings, and devised a thoroughly devilish set of patches. These patches were then incorporated into a pair of programs called Robin Hood and Friar Tuck. Robin Hood and Friar Tuck were designed to run as "ghost jobs" (daemons, in Unix terminology); they would use the existing loophole to subvert system security, install the necessary patches, and then keep an eye on one another's statuses in order to keep the system operator (in effect, the superuser) from aborting them. So... one day, the system operator on the main CP-V software-development system in El Segundo was surprised by a number of unusual phenomena. These included the following (as I recall... it's been a while since I heard the story): - Tape drives would rewind and dismount their tapes in the middle of a job. - Disk drives would seek back&forth so rapidly that they'd attempt to walk across the floor. - The card-punch output device would occasionally start up of itself and punch a "lace card" (every hole punched). These would usually jam in the punch. - The console would print snide and insulting messages from Robin Hood to Friar Tuck, or vice versa. - The Xerox card reader had two output stackers; it could be instructed to stack into A, stack into B, or stack into A unless a card was unreadable, in which case the bad card was placed into stacker B. One of the patches installed by the ghosts added some code to the card-reader driver... after reading a card, it would flip over to the opposite stacker. As a result, card decks would divide themselves in half when they were read, leaving the operator to recollate them manually. I believe that there were some other effects produced, as well. Naturally, the operator called in the operating-system developers. They found the bandit ghost jobs running, and X'ed them... and were once again surprised. When Robin Hood was X'ed, the following sequence of events took place: !X id1 id1: Friar Tuck... I am under attack! Pray save me! (Robin Hood) id1: Off (aborted) id2: Fear not, friend Robin! I shall rout the Sheriff of Nottingham's men! id3: Thank you, my good fellow! (Robin) Each ghost-job would detect the fact that the other had been killed, and would start a new copy of the recently-slain program within a few milliseconds. The only way to kill both ghosts was to kill them simultaneously (very difficult) or to deliberately crash the system. Finally, the system programmers did the latter... only to find that the bandits appeared once again when the system rebooted! It turned out that these two programs had patched the boot-time image (the /vmunix file, in Unix terms) and had added themselves to the list of programs that were to be started at boot time... The Robin Hood and Friar Tuck ghosts were finally eradicated when the system staff rebooted the system from a clean boot-tape and reinstalled the monitor. Not long thereafter, Xerox released a patch for this problem. I believe that Xerox filed a complaint with Motorola's management about the merry-prankster actions of the two employees in question. To the best of my knowledge, no serious disciplinary action was taken against either of these guys. Several years later, both of the perpetrators were hired by Honeywell, which had purchased the rights to CP-V after Xerox pulled out of the mainframe business. Both of them made serious and substantial contributions to the Honeywell CP-6 operating system development effort. Robin Hood (Dan Holle) did much of the development of the PL-6 system-programming language compiler; Friar Tuck (John Gabler) was one of the chief communications-software gurus for several years. They're both alive and well, and living in LA (Dan) and Orange County (John). Both are among the more brilliant people I've had the pleasure of working with. Disclaimers: it has been quite a while since I heard the details of how this all went down, so some of the details above are almost certainly wrong. I shared an apartment with John Gabler for several years, and he was my Best Man when I married back in '86... so I'm somewhat predisposed to believe his version of the events that occurred. -- Dave Platt Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303 From: elevav@mcdurb.Urbana.Gould.COM 25-FEB-1989 9:29:48 To: misc-security@uxc.cso.uiuc.edu Subj: [305] Re: SCOMP I don't know about SCOPM Plus, but from conversations with NCSC people I concluded that if submitted for evaluation nowdays SCOMP would not have been approved as an A1 system. Erez Levav @ Motorola, UDC erez@xenurus.gould.com uunet!uiucuxc!mcdurb!erez [expect addresses to change in a few months] From: *Hobbit* 25-FEB-1989 9:49:48 To: security Subj: [968] more sophisticated medecos Our campus key shop guru told me that we have even a more advanced Medeco than the standard, and was almost foolproof... I believe that these are the biaxials. They are no big deal; the chisel points are offset forward or back by .025". It effectively gives each pin twice the keying versatility, since the key cut can be the right depth and twist, but if it's not under the chisel tip, you lose. A master key for this system would have two cuts right next to each other that would address either offset [and I believe they would be at the same height, since it's difficult to cut two different heights only .050" apart and have enough "meat" left to turn the pin]. With regard to picking, it essentially makes no difference. In fact, it was a biaxial that I first started working with to develop the current theory.. Lessee, (6 cuts * 3 rotations * 2 offsets) = 36 positions per pin, to the 6th power gives you something like 2 gigapossibilities... _H* From: jjq@prlb.philips.be (Jean_Jac. Quisquater) 25-FEB-1989 10:13:19 To: misc-security@uunet.uu.net Subj: [2817] collision in DES We (Jean-Paul Delescaille and Jean-Jacques Quisquater) were able to find 3 collisions in DES using a network of workstations during some weeks. Definition of a collision: given a message M and an cryptographic algorithm f with 2 parameters M and K (the key), a collision is a pair (K1, K2) such that f (M, K1) = f (M, K2), that is, for a fixed message M and using a cryptographic algorithm f, the key K1 and the key K2 give the SAME encrypted message. Jean-Jacques devised a new probabilistic distributed asynchronous algorithm for finding collisions without any sorting and with a small storage (a la Pollard). We used a fast implementation of DES in C (by Jean-Paul: about 2000 * (encryption + change of key) /second/machine) We used the idle time of a network of 20 SUN-3's and 10 microVAXes (a la Lenstra and Manasse). Total: about 100 Mips during one month. 37 2 encryptions performed (about 20 potential collisions) only in software! The message M is 0404040404040404 (hexadecimal form) for the 3 collisions. Collision 1: found Fri Jan 13 23:15 GMT (birthday of Jean-Jacques! Yes, it is another birthday attack (Hi! Don Coppersmith)). cipher = F02D67223CEAF91C K1 = 4A5AA8D0BA30585A K2 = suspense! Collision 2: found Fri Jan 20 19:13 GMT cipher = E20332821871EB8F K1, K2 = suspense! Collision 3; found Fri Feb 3 03:22 GMT suspense! Conclusion: Friday is a good day for finding collisions :-) Well, there is a problem because there is no proof we effectively found such collisions. Question 1: Find a protocol for proving or for convincing you that we know K2 for collision 1 (zero-knowledge protocols are useful in this context). Question 2: Find a protocol for proving or convincing that we know K1 and K2 for collision 2 (idem). Question 3: Find a protocol for proving or convincing that we know 3 different collisions (idem). Useful information: the nice paper by Brassard, Chaum and Crepeau, ``Minimum disclosure proofs of knowledge'', 1987. The complete information will be given at EUROCRYPT '89, Houthalen, Belgium, with the restriction that the submitted abstract is accepted :-) The paper will be sent in April if you want it. Thanks are due to Paul Branquart, Frans Heymans, Michel Lacroix, Vincent Marlair, Marc Vauclair, the members of PRLB for permission and active help in the effective implementation of the distributed algorithm on their workstations. Warning: There is no implication about the security of DES used for encryption. Indeed these experiments only prove that DES is a good random mapping (a necessary property for any cryptographic algorithm). However the use of DES for protecting the integrity of files is not very easy and needs very careful studies. Jean-Jacques Quisquater, (Program chairman of EUROCRYPT '89) From: wcs@skep2.ATT.COM (Bill.Stewart.[ho95c]) 25-FEB-1989 10:29:47 To: security@pyrite.rutgers.edu Subj: [469] Re: Sargent & Greenleaf Lock I assume you mean the kind mounted on a door, as opposed to a padlock or something? We had to break one once - one of the screws holding it to the door came loose and wedged inside the mechanism, so it wouldn't open. Took the locksmith about 1.5 - 2 hours to drill it. Shouldn't be hard to reset, though - find a good locksmith. -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs # # News. Don't talk to me about News. From: 28-FEB-1989 23:22:13 To: security@pyrite.rutgers.edu Subj: [1786] Desperately seeking research help... Dear fellow Netlander: I am developing research for a thesis, tentatively titled, "Computer Security in the Process Control Environment". I am seeking anyone's assistance in obtaining information relevant to this topic, as there currently exists no published data. Specifically, I would like to reach people who have (or have had) involvement in Computer Integrated Manufacturing (CIM), Computer Aided Manufacturing (CAM), process control, and related fields. Helpful information could include policies and procedures (current or past), actual experiences, etc., regarding this area, in its broadest interpretation. Suggestions gladly considered. Please feel free to pass along a copy of this letter to anyone who might be of further help. *ANY* information, even if just deemed peripheral, would be of great value, as such data can lead to other relevent information. Please, if you think you might have some helpful info, or think you might know someone or somewhere that more info can be obtained, send me a note! Data obtained will be compiled and published in Spring 1989, as my thesis. Thank you for your attention, and please excuse any inconvenience... +----------------------------------+ | Michael Kielsky | +----------------------------------+ \ Bitnet: AGMGK@ASUACVAX.BITNET \ \ \ \ 1902 East St. Catherine Ave. \ \ Phoenix, Arizona 85040 \ \ (602) 276-4663 (Home) \ \ (602) 891-6927 (Work) \ +----------------------------------+ | All opinions expressed are the | | author's and in no way reflect | | the opinions of the Sane. :-) | +----------------------------------+ From: kerchen@iris.ucdavis.edu (Paul Kerchen) 28-FEB-1989 23:22:39 To: security Subj: [1036] Re: "Viri Logicum" Here at UC Davis, we are doing research on computer viruses under the direction of Lawrence Livermore Nat'l Lab. Here at UCD, we write anti-viral programs and virus detectors. We ship them to LLNL and they test them there on a completely isolated system with viruses which they have. Now, supposed that someone accidentally attached an Ethernet cable to this isolated system. What happens now? A virus is released on the Internet unintentionally. No one gets any satisfaction from seeing this happen. However, there is a legitimate purpose for writing these viruses. If R. Morris really didn't mean to release his worm onto the Internet, imagine the horror he probably felt when he realized what he had done (put yourself in his shoes! :-) No flames, please. I don't want to debate RTM's guilt or innocence.). So, what's the point? The point is that there are legitimate reasons for writing viruses, worms, etc. How can one defend against a virus unless they have one to look at? Paul Kerchen | kerchen@iris.ucdavis.edu From: jjmhome!cpoint!martillo@cloud9.stratus.com 28-FEB-1989 23:24:46 To: security Subj: [3035] Layer Encapsulation in OSI [This was forwarded from comp.protocols or some such. _H*] >Anyone know of any references to layer encapsulation in official >OSI or CCITT documents. The problem is as follows: >LLC type II is reliable and one might want to provide security >on a per logical link basis, Unless you want to provide reliability >in the security layer itself, to make sure that applications which >run in a secure environment, you want to put the security layer >between LLC and the MAC layer, but at that point in the stack >the protocol software should only be looking at the MAC addresses >and security cannot be provided on a per logical link basis. >And if the security layers lives at the top of LLC, then the >security layer has to provide reliability. >I vaguely remember having this problem at Bell Labs when working >on Data Teleconferencing and the solution was layer encapsulation >where the security procedures would encapsulate the protocol >layer, but I simply don't remember where this was described in >the CCITT or OSI documents. If someone could give a pointer, >I would be grateful. I am following the current deliberations of the 802.10 committee on this issue. Tony Bono had what I consider a good original proposal for an architecture to deal with the issue. Apparently, the committee could not shoot down the proposal, but because he did not give a detailed functional specification (which was not what I understood to have been originally requested), the committee decided that they would only provide security procedures at the boundary between LLC and the MAC (based on pairwise MAC addresses) and not at the boundary between the Network Layer and LLC based on LSAP/DSAP pairs for a given MAC layer connection. Personally, I can think of many reasons why one might want to provide pairwise LSAP/DSAP security rather than simply point-to-point MAC address based security. It seems to me perfectly reasonable that Network Management communications streams, OSI communications streams or TCP/IP communications streams might all require different security procedures at the boundary between LLC and the network layer. Personally, I would think distributed multi-level security would be a nice thing. Providing security procedures on a per LSAP/DSAP basis would give the possibility of multi-level security at the link-layer, so that a given host might be able to realize that a given data stream from a host was trusted at a secret level because the user had logged into the console in a room guarded by guys with machine guns while another data stream from the same host was not trusted at all because the user had dialed in from outside. I see this situation all the time. Everytime someone wants to incorporate some new idea into OSI which actually give some reason to switch from TCP/IP to OSI, it gets shot down at the committee level. Now I understand why the best standards are those which were ad hoc standards first, and only much later standardized by the international committees. Any comments? From: KARYN@nssdca.gsfc.nasa.gov 28-FEB-1989 23:57:22 To: security@pyrite.rutgers.edu, (cbds080@ccs.csuscc.calstate.edu) Subj: [2105] Virus Legislation Spock, In answer to your questions... 1. Background behind viri: Everybody's stories differ. 2. Good Books on Viri: None. Now, to answer your question: Books are present, but they may not be good: I have one called: "The Computer Virus Crisis" authors: Fites/Johnson/Kratz Publisher: Van Nostrand Reinhold, NY NY I bought this one because it has skads of references in the back, & its copyright Jan 1989. I found it in a local B. Dalton store (in the nonfiction section) 3. Legislation: You asked the right person. My office-mate is now looking through his stash of info, and already has found a 20-page paper titled, "Computer Crime Legislation" dated Nov 1987. I won't bore the readers of this list with a long-winded description of which states have what laws, but in general, there are: "The Computer Fraud and Abuse Act" Fed Law TITLE 18 Part I Sect. 1029; (same law) Part I Chapt 47 Sect 1030 Chapt 119 sects 2510-2521 Chapt 121 sects 2701-2709 All states except Arkansas, Indiana, Vermont, and West Virginia had at least one statute as of the time of the paper. 4. Newer Legislation: Rep Wally Herger (R-Cal) introduced HR 5061 last July (The Computer Virus Eradication Act of 1988) but Congress was not able to vote on it last year. He re-introduced the same bill (now called HR 55) on Jan 3, 1989; 42 House members are currently co-sponsors. Who knows when this one will be voted upon. This is different from the above law because this one covers EVERYONE, while the above law only covered Government computers. 5. The "Computer Security Act of 1987" (HR 145), which you may have heard of, has nothing to do with Computer Fraud or Viruses. 6. I heard a rumor through the mill that Morris is getting off with nothing but a slap on the wrist because the places he affected don't want to get together to really give it to him. for more info, send mail to: Karyn@nssdca.gsfc.nasa.gov From: FLORY 1-MAR-1989 12:01:07 To: security@pyrite.rutgers.edu Subj: [1334] Virus psychology information In response to "Commander Spock"'s question about sources of information on why people write virus's, I suggest he look at a few recent magazine articles (I really doubt any books have been on the topic as of yet) In the Summer issue of 2600 magazine there is an article by "The Plague" called "How to Write a Virus: The Dark Side of Viruses". He claims to have written a viruse called CyberAIDS which attacks the Apple II series, but besides his "qualifications" you can get a pretty good idea of the twisted kind of mind who enjoy this kind of thing (Mr. "Plague" claims to have no moral objections to trashing people's hard work) The article goes into the theory of virus writing (not system specific) A careful reading between the lines can provide a psycological outline of one kind of virus writer. you can get a back issue of 2600 by writing to 2600 Magazine, PO Box 752, Middle Island, NY 11953-0752. You also may want to look up the Winter 1988 issue of "High Frontiers Reality Hackers" for an article called "Cyber Terrorists / Viral Hitman" Reading it between the lines also reveals a lot about the type of person who would voluntarily release a virus. David James Flory PS I don't support, condone, or agree with any of these authors, I am just bringing them up for a view of why people would write these things. From: "H.Ludwig Hausen +49_2241142426" 1-MAR-1989 12:11:12 To: security@pyrite.rutgers.edu Subj: [1395] Certification of Software Hello netters, we are going to start a European initiative on software certification (SWC) and therefor we would appreciate to receive any information on - needs for SWC - objectives for SWC - effective procedures for SWC - tools for SWC - who is doing SWC - who should do SWC - etc. Certification, in our view, includes all methods and procedures do validate, verify, test examine, measure or assess software as a product or software beeing developed by a 'certified' development process. Thanks for any help. H. L U D W I G H A U S E N .................................. : Telephone +49-2241-14-2440 or 2426: : GMD Schloss Birlinghoven Telefax +49-2241-14-2618 or 2889: : D-5205 Sankt Augustin 1 Teletex 2627-224135=GMD VV : : West GERMANY Telex 8 89 469 gmd d : : E-mail hausen@dbngmd21.BITNET : : hausen@kmx.gmd.dbp.de : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . : GMD (Gesellschaft fuer Mathematik und Datenverarbeitung) : : German National Research Institute of Computer Science : : German Federal Ministry of Research and Technology (BMFT) : ...................................................................... From: "Kevin S. McCurley" 1-MAR-1989 12:28:27 To: security@pyrite.rutgers.edu Subj: [4179] Crypto '89 The following conference may be of interest to this distribution list: ====================================================================== CRYPTO '89 CALL FOR PAPERS The Ninth Annual Crypto Conference sponsored by the International Association for Cryptologic Research (IACR) in cooperation with the IEEE Computer Society Technical Committee on Security and Privacy, and the Computer Science Department of the University of California, Santa Barbara, will be held on the campus of the University of California, Santa Barbara, on August 20-24, 1989. Original research papers and technical expository talks are solicited on all practical and theoretical aspects of cryptology. It is anticipated that some talks may also be presented by special invitation of the Program Committee. INSTRUCTIONS FOR AUTHORS: Authors are requested to send ten copies of a detailed abstract (not a full paper) by March 17, 1989, to the Program Chairperson at the address given below. Abstracts should contain sufficient detail, as well as references to and comparisons with relevant extant work, to enable Program Committee members to appreciate their merits. It is recommended that abstracts start with a succinct statement of the problem and discussion of its significance and relevance to cryptology, appropriate for a non-specialist reader. In order to facilitate blind refereeing, the names of authors and their affiliations should only appear on the cover page of the paper; it should be possible to remove this page and send the papers to Program Committee members. Limits of 10 double-spaced pages and 2500 words (not counting the bibliography and the cover page) are placed on all abstracts. If the authors believe that more details are essential to substantiate the main claims of the paper, they are asked to include a clearly marked appendix that will be read at the discretion of the Program Committee. Abstracts that significantly deviate from these guidelines risk rejection without consideration of their merits. Abstracts received after the March 17 deadline WILL NOT BE CONSIDERED, unless they are postmarked not later than March 13 and arrive a reasonable time thereafter. Authors will be informed of acceptance or rejection in a letter mailed not later than May 26. A compilation of all abstracts accepted will be available at the conference. Authors of accepted papers will be given until July 14, 1989 to submit revised abstracts for this compilation. Complete conference proceedings will be published in Springer-Verlag's Lecture Notes in Computer Science series at a later date. The Program Committee will consider abstracts that have also been submitted to other conferences. However, if a submission is accepted for presentation at more than one conference, the authors may present the results more than once, but may publish them in at most one proceedings. The Program Committee consists of Josh Benaloh (University of Toronto) Russell Brand (Special session chairperson, Lawrence Livermore Laboratory) Gilles Brassard (Committee chairperson, Universite de Montreal) Claude Crepeau (Massachusetts Institute of Technology) Whitfield Diffie (Bell Northern Research) Joan Feigenbaum (AT&T Bell Laboratories) James Massey (ETH Zentrum, Zurich) Jim Omura (Cylink Corporation) Gustavus Simmons (Sandia National Laboratories) Scott Vanstone (University of Waterloo) Send abstracts to the For other information, program chairperson: contact the general chairman: ---------------------------- --------------------------- Gilles Brassard, Crypto '89 Kevin McCurley Departement IRO IBM Research, K53/802 Universite de Montreal 650 Harry Road C.P. 6128, Succursale ``A'' San Jose, CA 95120-6099 Montreal (Quebec) U.S.A. CANADA H3C 3J7 telephone: (408) 927-1708 telephone: (514) 343-6807 Internet: mccurley@ibm.com email: brassard@iro.umontreal.ca Bitnet: mccurley@almvma From: hollombe@ttidca.tti.com (The Polymath) 1-MAR-1989 13:51:12 To: misc-security@sdcsvax.ucsd.edu Subj: [1411] Re: Security equipment }If you install an alarm }system... you may be eligible for a discount (on your insurance). I asked my insurance company about this when I lived in an apartment. We'd had some burglaries and people were putting up window bars (the landlord wouldn't )-: ). They told me there was no insurance discount for window bars. A friend (Hi, Marvin!) explained the rationale: If you have a fire, you generally lose everything and the insurance company is stuck for the maximum payout. So, smoke alarms get you a premium reduction. Burglars, on the other hand, generally only take a few items. The insurance company isn't all that much out of pocket (unless you're a multi-millionaire with lots of expensive toys to be stolen) and the relevant premium reduction isn't worth offering. Bars also hinder fire fighters. Except for hindering fire fighters, I'd guess the same logic applies to alarm systems. They might save you some inconvenience by scaring away a burglar, but they generally don't save the insurance company enough for them to take an interest. Not that they're a bad idea, mind you. They just won't save you any insurance money. -- The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimati Nil Citicorp(+)TTI Carborundum 3100 Ocean Park Blvd. (213) 452-9191, x2483 Santa Monica, CA 90405 {csun|philabs|psivax}!ttidca!hollombe From: "Craig Finseth" 1-MAR-1989 14:17:15 To: security@pyrite.rutgers.edu Subj: [1952] Additional security to login Cc: Makey@logicon.arpa Unfortunately, you missed the point. The supplied permissions: > drwxr-xr-x 13 root 1024 Jan 9 13:31 / > drwxr-xr-x 2 root 3584 Jan 23 03:42 /etc > -rw------- 1 root 2899 Jan 10 12:48 /etc/passwd will break most UNIX systems as /etc/passwd must br readable to the world: -rw-r--r-- 1 root 2899 Jan 10 12:48 /etc/passwd Shadow password files are in theory not required. In practice, when someone can read the entire file (and hence all encrypted passwords), run a password cracking program over it (that allows me to test candidate passwords at at rate a thousand times faster than simply attempting to log in), and people pick lousy passwords to begin with, the assumptions behind the publicly-readable encrypted passwords break down. Hence, one would like to move the encrypted passwords to a place where no one can read them, but otherwise leave the password file unchanged (so that UNIX still runs fine). > This scheme will have virtually no benefit on a well-administered UNIX > system, whereas the cost is moderate and may be very high (if early > implementations are easy to subvert). Since I feel that the assumptions behind the current UNIX system are violated, I disagree with this statement. I feel that the (shadow password file) scheme should be considered *mandatory* on a well-administered UNIX system and the cost is minimal (you need to change login, passwd, and su, less than a week's work even if you don't have source). While subvertable in principle, the shadow password file scheme is definitely less so than the current system. Craig A. Finseth fin@msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375 [Moderator note: Sun already has one in their version 4.0 and up; it sits in /etc/security/passwd.adjunct and is protected -rw-------. It seems reasonable that producers of other unix systems would soon come up with something similar... _H*] From: Mark Nelson 2-MAR-1989 0:29:51 To: misc-security@uunet.uu.net Subj: [338] Network security references? A friend of mine (without access to news) plans to write a survey paper on network security techniques. Does anyone have any good references they could recommend? I know this is pretty vague, but I don't think he has narrowed the topic yet. I will summarize if there is any demand. Thanks. Mark Nelson nelson@dewey.udel.edu From: goldstein%star.DEC@src.dec.com (Andy Goldstein) 2-MAR-1989 0:36:03 To: security@rutgers.edu Subj: [793] RE: using RSA Cryptographic Algorithm In a recent posting, James Galvin solicits implementations of and experiences with the RSA public key algorithm. Please be aware, folks, that the RSA algorithm and most of its applications are protected by a patent held by MIT and licensed to RSA, Inc. While I don't think anyone could mind if you read the textbooks and implemented your own version for some private hacking around, any sort of public distribution or serious use without a license from RSA, Inc. is likely to draw unfavorable attention from their lawyers. Don't get me wrong - I've met R & S and they're incredibly nice guys. But the corporation paid MIT a considerable amount of money for its license and it's going to get its money's worth. Anyway, the RSA patent is one of the few that's really worthy of being patented. From: (Tom, Tech. Support) 2-MAR-1989 0:39:42 To: SECURITY@pyrite.rutgers.edu Subj: [1415] Burglar tools In this state, trespassing is considered a crime and that crime, by itself, _can_ sustain a charge of burglary. This would especially be true in the case where a search incidental to the arrest produced a set of lock picks. In that situation I would charge with Criminal Trespass, Burglary, and Possession of Instruments of Crime. Safe to assume that a plea bargain would result, the felony charge of Burglary would be dropped and the deft. would plead guilty to the misdemeanors. (Unless I forgot to Mirandize him, which is another issue). I would say it would depend on a jury. If burglar tools (lock picks, and the like) are in possession, then there _IS_ a presumed intent. And, in our state, as I noted earlier, the entrance into a building with intent to commit _any_ crime constitutes burglary. Therefore, an unlawful entry into a building while in possession of burglar tools pretty well nails it. >Consider the *incidental* thief who is also regularly and >legitimately employed as a carpenter/plumber/construction worker/whatever >and just happens to carry all these around in his vehicle I agree with what you have said in context; but once the tools of the ligitimate trade have been removed from the vehicle and used to gain access to a locked building you have another situation. No luck needed - the tools become burglar tools ("instruments of crime" per PA Crimes Code). From: Joe Keane 2-MAR-1989 5:49:52 To: security@pyrite.rutgers.edu Subj: [184] Re: Hard disk protection There's really no way to protect a PC's hard disk, since the user has full control of the machine. The right thing to do is get some networking software and a dedicated file server. From: Jon Loux 2-MAR-1989 6:06:57 To: security@pyrite.rutgers.edu Subj: [2004] Re: Hard disk protection In regards to locking hard disks on IBM type PC's used for student labs, there are several security packages available for this kind of thing. At the University of Connecticut, we have been testing a product called PC/DACS. (Pyramid Development Corp. 20 Hurlbut St, West Hartford, Ct. 06110). This product will allow you to create user ID's and profiles similar to a Mainframe configuration. There must be at least one security administrator, who can create new ID's and write resource rules. A PC can be set up with a default user ID which gets automatically logged on when the machine is booted from the C drive. We use this feature in the labs, where we what the PC to boot without any user intervention. The default ID is given read only access to the entire hard disk. In one lab, they set it up so that the default ID has write access to a \TEMP directory so they can keep data for graphics programs on the hard drive while running the programs. The /TEMP directory gets purged at every boot. There is a boot protect option, which, when activated, will make your hard drive unrecognizable if you boot from the A drive. I think it relocates the FAT, or something insidious like that. There is also a disk encrypt option which will scramble your entire hard disk for you, if you're into scrambled hard disks. I haven't played with this option, since we really don't need anything quite that cloak and dagger here. We are mostly guarding against accidentally deleted files and cluttered hard disks. A new feature in the latest release of PC/DACS allows you to write resource rules for floppy drives as well. I've been thinking of using this to disallow the running of programs from floppies. If it works out, this may be an acceptable way of limiting the spread of viral programs. By the way, The State of Connecticut has contracted Pyramid Development Corp. for the use of PC/DACS in all State agencies. This is not intended to be an endorsement of the product, merely a critique. From: heilpern@tbd.ARPA (Mark A. Heilpern ) 2-MAR-1989 6:09:23 To: misc-security@uunet.uu.net Subj: [598] Re: Hard disk protection One way is to put all 'restricted' programs on one hard disk, or one section of the hard disk, and simply unmount that section when students are in the area. This is rather drastic, but the most secure. Another method: assign group access to the files and place all users who need to access them inside this group. One final, and least secure method: (If you are assured to what times students will have access) set up an 'at' daemon to remove/restore all permissions to the required files. NOTE: If you choose this method, think about the possible login via modem at these times... Mark From: lg@cl.cam.ac.uk (Li GONG) 2-MAR-1989 6:09:52 To: security@rutgers.edu Subj: [1575] A Simple Trick (Re: Dangers of password changes) Prof. Wheeler mentioned a scheme which is being recommended to customers of a credit company to securely remember ALL your PINs. This could be adopted to remember those passwords a user has to change periodically. The trick is simply as this: suppose you want to remember your PIN for VISA card which is 1234 and that for ACCESS card which is 3456 and that for Diners which is 7890. 1) Write down A to Z and choose a word (gray, for example). 2) Write down your PINs in such a way that each PIN is on a separate line and the 4 digits are under the four letters g, r, a, y. Leave other places blank. A B C D E F G H I J K L M N O P Q R S T U V W X Y Z VISA 3 1 2 4 ACCESS 5 3 4 6 Diners 9 7 8 0 3) Fill in all blank spaces with random digits. Now the task to remember a number of passwords is reduced to remember an easy word. Also, this list can be made public with virtually no loss in security ( although try to keep it secret). There are many variations, for example to allow repeated letters in a word. Well, then what ? ____________________________________________________________________________ | Li GONG (+44223-334650) University of Cambridge, Computer Laboratory | | InterNet/CSnet : lg%cl.cam.ac.uk@cunyvm.cuny.edu (or @nss.cs.ucl.ac.uk) | | UUCP : ...!ukc!nss.cs.ucl.ac.uk!cam-cl!lg Bitnet/EAN : lg%cl.cam@ac.uk | ---------------------------------------------------------------------------- From: "Tarjei T. Jensen" 2-MAR-1989 8:49:52 To: Subj: [937] Re: Hard disk protection Somebody did something like this at our place. I don't know what they did, but here is my suggestion of how I would do it: I would write a program that would write protect all directories. I know that I could use something like Xtree to do this, but I think that a program will give me more flexibility. I could for example make it leave some directories writeable (scratch files). I would also think of putting the unprotected files in their own partition (drive) on the hard-disk. E.g. dirve C protected and drive D unprotected and in addition perhaps make D small. I would also write a program that would unprotect a drive (for maintenance). These programs would probably make a nice little student project (or assignment). Lastly I would get a program that would reformat the drive without destroying the data. I've heard that one should do a low level format on a hard drive once every 6 to 12 months. I hope this sounds sensible. From: "Kenneth R. van Wyk" 2-MAR-1989 8:58:23 To: Security List Subj: [1149] Re: Hard disk protection There are a number of products that are designed to do the sort of thing that you're looking for. I've tried Pyramid's PC/DACS (Data Access Control System), and it works pretty well if you install all of the options (hard disk boot protection AND disk encryption). You can set up individual users, with each one having access to whatever directories and files that you choose. With the encryption installed, it seems rather thorough; without it, it's child's play to get around. Of course, the encryption adds a bit of overhead to disk activities, but it's pretty reasonable. Pyramid Development Corp. can be reached at (203)-524-9832. I have no connection with Pyramid other than being a satisfied customer. Ken van Wyk Kenneth R. van Wyk Calvin: Mom, I'm going to grow a LONG User Services Senior Consultant beard like the guys in ZZ Top! Lehigh University Computing Center Mom: That's great Calvin, do it! Internet: Calvin: Wow, I thought she'd put up more BITNET: of a fuss than that! From: GREENY 2-MAR-1989 20:57:51 To: Subj: [1020] re: Hard disk protection > We are about to install a lab with a number of hard drives that will support > training and general student use. When students have access, we would like > to make those programs and files...to be "locked" in some way. What kind of machine are we talking about here? Mac, IBM, etc... On the Mac, it's relatively easy to do -- just set the FILE PROTECT bit in the files that you don't want duplicated or moved (although it will let you TRASH them I think...). A utility such as MacSnoop, or FEdit will usually do the job (I know RESEDIT wont let ya....) As for a PC, well, you could set the HIDDEN bit on them to true so they dont show up in the directory, and then have a batch file call em...This ought to work (but seeing as how I use Macs, and rarely get on PC's...it might not...) Although I have had hidden directories, with the files showing and had batch files like that.... Hope this helps... Bye for now but not for long Greeny BITNET: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU From: "Craig Finseth" 3-MAR-1989 19:25:03 To: security@pyrite.rutgers.edu Subj: [863] Login Insurance, CDC style Cc: jimkirk@outlaw.uwyo.edu "Out of band" signalling is great, assuming that you have an out of band path. If you're one of the enlightened (:-) Emacs users, "obscure" sequences that "no one will ever type" are ordinary command sequences. Another important question is "where is the trusted path TO?" In the olden days when all terminals were hardwired to serial ports, you could follow a wire and know where it went. In the current trend towards Ethernet terminal servers, my wire goes to that box. A trusted path could only be guaranteed to that box, not to the host (at least until we improve the network protocols). Unfortunately, the current situation leads to the operating assumption that you don't have a trusted path. "Don't worry, be suspicious," is thus the motto of the day. Craig A. Finseth fin@msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375 From: eleazar!matthews@dartvax.dartmouth.edu (Jim Matthews) 3-MAR-1989 19:45:00 To: misc-security@rutgers.edu Subj: [1007] Re: Breaking into computers is a crime, pure and simple >A real-life example in early November involved a so-called computer virus (a >self-replicating program spread over computer networks and other media as a >prank or act of vandalism), which nearly paralyzed 6,000 military and academic >computers. According to the MIT report on the worm this figure was derived from the infection rate at MIT (10% of MIT hosts were hit, and there are ~60,000 Internet hosts). Has any more credible estimate emerged? The 6,000 figure was a guess but it is becoming a fact by virtue of repetition. In fact, according to published reports the Computer Virus Industry Association furnished the FBI an estimate of $100 million in damages from the worm. The estimate was based on the 6,000 machine estimate and therefore postulates a cost of $16,700 per machine. We had around thirty machines infected here at Dartmouth but I don't think it cost us close to $500,000. Again, is there reason to believe these kind of estimates? Jim Matthews Dartmouth Software Development From: gwyn@smoke.brl.mil (Doug Gwyn ) 4-MAR-1989 0:13:03 To: misc-security@uunet.uu.net Subj: [701] Re: Friction is your friend -[Moderator add-on: My impression was always that Cipher locks [electronic, -five bidirectional rocker switches in a big klunky box] were different from -Simplex locks [all mechanical, five buttons in a column or a circle]. Is -there some name crossover or am I confused? _H*] You're not confused; the reason I put "Cipher" in quotes is because they aren't really Cipher electrical locks, they're just called that around here (actually "cipher" without capitalization). I don't know how this misusage started, but probably it was similar to calling all tissues "kleenex". Simplex locks can be manipulated. Genuine electronic locks cannot, although I'm sure there are other ways to defeat them. From: Will Martin __ AMXAL_RI 4-MAR-1989 0:29:44 To: Doug Gwyn Subj: [984] Re: MIT hacking ethics Cc: misc-security@uunet.uu.net Glad to hear that steam-tunnel exploration was common at many different universities. There must be some sort of common mindset amongst the particular student subculture that enjoys such things. Myself, I was a charter member of the "WUASS" - Washington University Artificial Spelunkers Society -- back in '63-'67 at Wash U in St. Louis. There were about 6 of us in that group. There may have been others doing it during the same timeframe, but we never ran into them. I'm sure people did it in the decades before we discovered the pastime, but they left no records that we knew of, either written or in verbal folk culture. I wouldn't be surprised if the activity stopped after we graduated, simply because that later period was one of campus unrest (building-burning, etc.) which would have led to tighter security that might have cut off the relatively easy tunnel access we enjoyed. Things might have loosened up again in the 70's and early 80's, though. Regards, Will Martin From: jad@dayton.dhdsc.mn.org (John A. Deters) 5-MAR-1989 4:10:37 To: security@rutgers.edu Subj: [685] Re: Friction is your friend There is some name confusion going on here. We use both Cypher locks and Simplex locks in our stores. You're right about the (lack of) security of a Cypher lock -- I was trying to work in a store after the last person who knew the combination had left, and I had it open in under three minutes (using only a flashlight). The Simplex locks can be much more secure from the viewpoint of 'breaking' the combination, but seem to be physically weaker IMHO. Also, with the Simplex locks, visual surveillance of the combination can be a problem. And they can be defeated by the oldest trick in the book -- sales consultants who tape the locks open because they 'get in the way'. :-) -j From: ron@ron.rutgers.edu (Ron Natalie) 5-MAR-1989 4:54:00 To: misc-security@rutgers.edu Subj: [1116] Re: Friction is your friend Hobbit is right. Cipher locks are as he described. Five rocker switches run to a box usually above and inside the door. You can program a 4 digit sequence in them by these little patchcords inside the box. Simplex locks are purely mechanical which are programmed by opening them, putting in the old combination, pushing a plunger, entering the new combination, and then clearing it. BRL never had any Cipher locks that I knew about, only Simplex. The Simplex weren't really regarded as any more secure than the plain old Seargent key locks, key distribution was easier. Generally they were used for things like printout rooms and labs where they were used by a large class of people. The secure facilities were actually deadbolted and alarmed when not attended. Even when we used Cipher locks in the SCIF's at other jobs, they were used only when the room was attended inside anyhow. At night we turned on the alarm and spun the big ol' S&G lock on the door. What was amazing to me is the number of people who never bother to change the Simplex locks from the 2-4, 3 combo they all get shipped with. -Ron From: christevt@wpafb_ams1.arpa 5-MAR-1989 5:37:23 To: "security" Subj: [1216] Re: MIT hacking ethics Just a quick comment about Doug Gwyn's comment about what happened at Rice...this time regarding MIT hackers who decided to wander up the Chuck a piece to a little business school called Hahvahd... Not much happened, mainly because the group was too large...the Hahvahd CPs saw this group of people wandering around suspiciously (at about midnight or so) and immediately questioned them about why they were there, what they were doing, etc... The main point of all this is to show, once again, that not all universities tolerate (and NONE, of course, OFFICIALLY approve of) hacking... and probably especially when the hackers are from another school (who can forget the great Hahvahd-Yale game where MIT won?!!!)...In general, Hahvahd DOES NOT approve of MIT hackers...sigh...so what! ET B ME VIC ! Victor ET Christensen "To the last I grapple with thee, christevt@wpafb-ams1.arpa From Hell's heart I stab at thee, christevt@p6.ams.wpafb.af.mil For Hate's sake I spit my last breath christevt%amsp6.decnet@wpafb-ams1.arpa at thee!!!" ~ Khan From: Fred Blonder 5-MAR-1989 9:37:08 To: Jeff Makey Subj: [1051] Re: Additional security to login The /dev/passwd could be made write-only. (well, write and compare only.) If it were implemented properly in hardware it could emulate what the Unix one-way encryption is trying to do. In fact it wouldn't need to store the passwords in encrypted form if you could trust the hardware. It would just need to answer a request of the form: "Is this uid/password combination valid?" Presumably it would have some built-in delay and maybe an alarm it could ring if too many invalid attempts were made in a short time. ... would no doubt be subject to its own special class of attacks. Well, the only weakness I can see here (other than a hardware attack, in which case all bets are off anyway) is if someone emulates root and changes someone else's password, which can be done in "standard" Unix already. In fact, the /dev/passwd thingy would be slightly better against even this attack, because the cracker wouldn't be able to restore the old password to clean up after the fact. ----- Fred Blonder Fred@Mimsy.umd.edu uunet!mimsy!fred From: zeleznik@cs.utah.edu (Mike Zeleznik) 5-MAR-1989 9:45:39 To: security Subj: [1209] Re: Zero knowledge passwords? On the subject of reverse authentication (proving to the user that they are talking to the system), something like the Security Dynamics SecurID card can provide this. A displayed number on the card changes every so many seconds; to authenticate you simply type in the current number and the system can authenticate you since it is time synced. By then requiring the system to provide the NEXT number, you can compare it with the next one on your card, thus being assured you are talking to the actual system. If the Racal-Guardata product would simply allow the response from one challenge to become another challenge (rather than forcing a random challenge), then I think it also could provide reverse authentication. System issues challenge, you type response. Then your card calculates a response from that response, which the system must also do, thus proving who it is. Since each challenge/response is unique, this seems immune to replay and as safe as the original challenge/response was. Michael Zeleznik Computer Science Dept. University of Utah zeleznik@cs.utah.edu Salt Lake City, UT 84112 (801) 581-5617 From: gmz@pbhyg.pacbell.com (Gerry Zeitlin) 5-MAR-1989 12:32:12 To: misc-security@ames.arc.nasa.gov Subj: [862] Re: EMP (Electro-Magnetic-Pulse) According to conversations I had last fall with Bob Oechsler, a radio journalist in the Baltimore area, two EMP barges - Empress I and II - were actually deployed near the Patuxent River Naval Air Station and in the Chesapeake Bay. They may have been responsible for several calamities, including the destruction of millions of fish, the irreparable damage to the piers of a new bridge which has now been permanently closed, and the explosion of a Cessna 182 as it flew over one of the barges. The pilot of the Cessna was killed. His family hired a salvage firm to dredge for the remains of the airplane, but no debris was ever found. When I spoke to him, Oechsler was pressing for Congressional action on this affair. He probably wouldn't mind my mentioning his address, which is 136 Oakwood Rd., Edgewater, MD 21037. Gerry Zeitlin 415-841-5910 well!gmz From: (Stephen Tihor) 5-MAR-1989 12:42:44 To: Subj: [1557] Password Length versus Duration Glenn is right in that password length and lifetime can probably be traded back and forth holding some metric of security constant. If one of my users complains about our relatively long password lifetimes I offer them a double for double deal on their password: twice the lifetime for twice the minimum length. Glenn is raising an interesting human interface issue when he disparages VMS's password set of {A-Z0-9$_}*36 for not including random punctuation since the space of possible inputs is about the right size (informationally speaking) to collapse into an 8 byte hashed password. [Various studies I have seen quoted assert that english text has 2-4 bits of real information content bet letter because of its high redundancy. A good citation would be appreciated.] This more realistic than the otherwise plausible idea of taking eight ASCII characters typed in at a terminal. Most terminals require contortions or surgery to generate many of the possible characters and thus most passwords will fall in a very restricted portion of the possible space. [Still a large one but not as large as possible or even I would contend desirable.] Is it is better to ask for fewer characters from a wider range or more characters that people are likely to enter? That sounds like an interesting problem for some student in a human factors program to consider. The question of how many characters people can type without visual feedback and maintain a low error rate also enters into it. All in all I am suprised someone hasn't done a thesis on it. From: Dr. T. Andrews 6-MAR-1989 11:06:48 To: security@pyrite.rutgers.edu Subj: [704] Re: Computer virus crime Cc: KARYN@nssdca.gsfc.nasa.gov ) ... Congressman from California spoke about a proposed law, HR 55, ) which would specifically make it a crime to prance about in others' ) computer areas ... The problem with such laws is that they are generally made by congress. I would not trust congress to formulate a law which was both useful in prosecuting those cases which I would want prosecuted, and not applicable in cases where I would not want it to apply. Consider that sending e-mail is dangerously close to "prancing about in others' computer areas", as is news. As for control messages (eg: sendsys, newgrp, rmgrp), well, I'd sure hate to pay a lawyer to try the case. Dr. T. Andrews, Systems CompuData, Inc. DeLand From: "Dennis G. Rears (FSAC)" 6-MAR-1989 11:26:48 To: KARYN@nssdca.gsfc.nasa.gov Subj: [988] Re: Computer virus crime Cc: security@rutgers.edu >Also this law would allow civil cases to recover damages from the >creator of such an item... You don't need a specific law to collect damages. It's already covered under existing tort law. Do you mean creator or distributor? If you mean creator, you will have to prove that he knew or should have known that it could have been released without his permission or knowledge. What if he publishes it? You get into free speech problems. I hope you mean the distributer. I agree something should be done. DON'T COMPLETELY RELY ON LEGAL REMEDIES. They normally don't work. The system is screwed up enough as it is. Dennis -------------------------------------------------------------------------- Dennis G. Rears ARPA: drears@ac4.pica.army.mil UUCP: ...!uunet!ac4.pica.army.mil!drears AT&T: 201-724-6639 USPS: Box 210, Wharton, NJ 07885 Work: SMCAR-FSS-E, Bldg 94, Picatinny Ars, NJ 07806 -------------------------------------------------------------------------- From: *Hobbit* 7-MAR-1989 18:24:36 To: security@pyrite.rutgers.edu Subj: [569] Administrivia Some of you have asked about archives and such. During the great worm upheaval, pyrite.rutgers.edu didn't have anonymous FTP turned on. At long last I've installed the fixed ftpd and placed the latest archives in /security/security.3 -- there are other files of possible interest there too -- for internet folks to freely swipe. If you need a different format and can't create it on your own, let me know and I'll see what I can do for simple fixes. I won't talk about the continual backlog problem that makes all the messages two weeks out of date... sigh.. _H* From: "David.J.Ferbrache" 8-MAR-1989 7:15:34 To: security Subj: [6407] Virus Technical Review This request has appeared on the bitnet virus-l mailing list, and has been crossposted to the appropriate comp.sys groups and to comp.risks. I apologise for any readers who receive duplicate copies. ------------------------------------------------------------- A review of the threat posed to the security and integrity of microcomputer systems posed by self-replicating code segments ------------------------------------------------------------- I am in the process of compiling information on existing computer viruses, with a view to the production of a technical paper reviewing the threat to system security posed by both present computer viruses and likely future developments. To this end I would be very grateful for information on individual infections, preferably detailing the symptoms observed, damage caused and disinfection techniques applied. Naturally I am also interested in details of the operation of the viruses, although I appreciate the reticence shown by infected parties to disseminate any details of virus operation, on the basis that it could lead to development of further viruses. The technical report is part of a Doctoral research thesis in computer security, and will be available in late May. Distribution of the technical report will be restricted to people who have a legitimate interest (ie systems managers, commercial concerns, research), as I expect to review the techniques exploited by viruses in a fair degree of detail at the BIOS/DOS interface level. The report will consider the techniques used by virus to duplicate, the ways in which viruses gain control of the computer system, the camouflage techniques adopted and a brief overview of the existing computer viruses. Finally the report will consider the likely development of the threat from viruses, and how this developing threat can be addressed by protective software in both virtual and non-virtual machine operating environments. At the moment I know of the following viruses: IBM PC MS/DOS 1. Lehigh variant 1 and 2 2. New Zealand (stoned) 3. Vienna (Austrian, 648) 4. Blackjack (1701, 1704) 5. Italian (Ping Pong) 6. Israeli variant 1 (Friday 13th, 1813, PLO, Jerusalem), variant 2, variant 3 (April 1st), variant 4 7. Brain (Pakastani) and variants 8. Yale Also potentially variant of the Rush Hour and VirDem viruses developed during the CCC's work on viruses. APPLE MAC 1. NVir variant A and B, Hpat 2. Scores 3. INIT 29 4. ANTI 5. Peace (MacMag) APPLE II 1. Elk AMIGA 1. SCA 2. Byte Bandit 3. IRQ ATARI ST 1. Boot sector 2. Virus construction set viruses Mainframe OS worms 1. Internet worm 2. DECNET worm 2. BITNET Xmas chain letter I would be grateful for any information on these, or any other viruses. Reports of infection may be given in confidence, in which case they will only be used as an indication of geographical distribution of infection. A summary of known viruses, their symptoms, geographic distribution and known disinfection measures will be posted to the list as soon as sufficient information is available to prepare an interim report. As part of the paper I will also be reviewing the effectiveness of viral disinfection software, and would thus be interested in details of any software you use, its effectiveness, and availability. Thanks for your time! For those interested here is a summary of a few of the virus reports published on virus-l and usenet, Subject, author and date Virus Virus-l issue THE AMIGA VIRUS - Bill Koester (CATS) SCA LOG8805 comp.sys.amiga, 13 November 1987 New Year's Virus Report - George Robbins IRQ 1 January 1989, comp.sys.amiga The Elk Cloner V2.0 - Phil Goetz ELK 26 Apr 1988 THE ATARI ST VIRUS - Chris Allen ATARI ST 22 March 1988, comp.sys.atari Features of Blackjack Virus, Otto Stolz BLACKJACK v2.24 24 Jan 1989 Comments on the "(c) Brain" Virus BRAIN LOG8805 Joseph Sieczkowski, Apr 1988 Brain and the boot sequence, Dimitri Vulis BRAIN v2.5 5 Jan 1989 The Israeli viruses, Y.Radai ISRAELI LOG8805 2 May 1988 VIRUS WARNING: Lehigh virus version II LEHIGH v2 v2.35 Ken van Wyk, 3 Feb 1989 The Ping-Pong virus, Y.Radai ITALIAN v2.18 17 Jan 1989 Known PC Viruses in the UK and their effects MOST PC v2.23 Alan Solomon, 1989 Yale Virus Info, Chris Bracy, YALE LOG8809a 2 Sep 1988 New Macintosh Virus, Robert Hammen ANTI comp.sys.mac, 7 Feb 1989 Hpat virus-it is a slightly modified nVIR HPAT Alexis Rosen, comp.sys.mac, 7 Jan 1989 INIT 29: a brief description, INIT 29 v2.18 Joel Levin, 18 Jan 1989 A detailed description of the INIT 29 virus INIT 29 v2.30 Thomas Bond, 27 Jan 1989 The Scores Virus, John Norstad SCORES LOG8804 info-mac digest, 23 Apr 1988 Macintosh infection at Seale-Hayne College TSUNAMI LOG8808d Adrian Vranch, 8 July 1988 DEFENCE DATA NETWORK MANAGEMENT BULLETIN, DECNET (see also v1.59a) 50, 23 Dec 1988, The internet worm program, an analysis INTERNET Gene Spafford, Nov 1988 I apologise for any researchers whose articles I have not cited, in what is currently an incomplete list of references. Hopefully, this article will be of some use in providing a general list of viruses which have affected computer systems in the past. Thanks for your time, and I look forward to any information you can supply me with. Dave Ferbrache Personal mail to: Dept of computer science Internet Heriot-Watt University Janet 79 Grassmarket UUCP ..!mcvax!hwcs!davidf Edinburgh,UK. EH1 2HJ Tel (UK) 31-225-6465 ext 553 From: ron@ron.rutgers.edu (Ron Natalie) 8-MAR-1989 14:00:31 To: misc-security@rutgers.edu Subj: [225] Re: Simplex locks In addition, SIMPLEX had a line in some of their sales literature to the effect that "10,000 possible combinations makes guessing to right one a million to one." We should send their marketing department to Prob 101. -Ron From: 34AEJ7D@CMUVM.BITNET 8-MAR-1989 14:13:03 To: Security Digest Subj: [470] appearances vs. actualities An area firm has an office area separated from the factory floor by large windows. Recently, The management thereof decided to enhance the security of their office area, so they installed bullet-proof glass in those windows. The trouble is, the windows are set in a wall made of nothing more than 3/4" plywood and 2x2's. Thus they have given themselves the reassuring *appearance* of increased security, without actually increasing their physical protection one whit! From: Gary J. Rosenblum 8-MAR-1989 14:21:19 To: security-request@pyrite.rutgers.edu Subj: [985] Request for patches to improve security I'm not sure if this has been talked about here before, but I was starting to add the code to sendmail (I'm running MORE/bsd from Mt. Xinu, sendmail version 5.61) to log the IP address and socket # on smtp connects. This was part one in a general beefing up of security and logging capabilities. It dawned on me that this was done before - and indeed, many other patches to different programs/daemons have been made by many people. I was wondering if it was possible for people to post these mods (as diffs, or whatever) to the mailing list. I know that there might be some licensing problems, etc. This would free my time, and others, from reinventing the wheel. Thanks. Gary J. Rosenblum UNIX Systems Manager rosenblg@nyu.edu New York University gary@nyu.edu [Moderator add-on: I would have just pointed him at ucbvax for the sendmail distribution, but there may be other things that he needs. In any case, please mail things to him, *NOT* the Security list... _H*] From: nugent@anubis.uchicago.edu 8-MAR-1989 14:33:04 To: *Hobbit* Subj: [981] Re: more sophisticated medecos Cc: security@pyrite.rutgers.edu > I believe that these are the biaxials ..... A master key for this > system would have two cuts right next to each other that would address > either offset..... Actually one problem with the Medecos is that within a given master key system (typically a building), all of the pin rotations are the same for all of the changes. If you have the lowest key to, say the garbage room, you know the pin rotations to the grandmaster key which opens all doors. Because of this, the Medecos are only marginally better than other precision locks at preventing the usual university problem, which is a student adding a little solder to his office/dorm key and using a file to turn it into a master key. It probably belongs in RISKS, but I can't help commenting that when the Biaxials first came out, the Medeco keying software had some problems with cross-keying, with the result that one of our office keys was also a submaster for a different series....that student had fun! Todd From: nichols@cbnewsc.att.com (robert.k.nichols) 8-MAR-1989 14:35:16 To: misc-security@att.att.com Subj: [3086] Re: Simplex locks Some time ago I computed 1152 (as I recall) as the number of possible combinations -- not exactly what is implied by the "thousands of possible combinations" claimed by the Simplex folks (recently I saw some blurb that claimed "more than 2000" combinations). Incidentally, if (through psychoanalysis of the user) you suspect a "complex" combination involving 3 buttons simultaneously, your guessing job is greatly reduced. There are only 10 such 3-button sets, each with only 2 other buttons to consider. There IS a way to generate some additional combinations, although it violates the instructions of the manufacturer to "remove your fingers from the buttons before turning the knob," risking damage to the lock if you're not careful when opening it. At the end of the sequence, an otherwise unused button can be pressed lightly, just to the point of increased resistance, and HELD THERE as the knob is turned. Such a combination is distinct both from pressing the button all the way and from not pressing the button at all. The basic principles for setting/changing such combinations still apply: set the combination using the same actions you're going to use to open the lock; to change the combination, press the present combination and, while holding the final button(s) activate the "change" slide. It is possible to detect such combinations through manipulation and determine the buttons involved, but such combinations would confound the unaware. It never ceases to amaze me the way these very useful locks are mis-applied (largely due to mis-information supplied by the manufacturer). The locks are primarily suited (at least in my mind) to preventing casual entry to a restricted area, provided that the location of the lock is such that anyone attempting manipulation would be immediately observed and challenged. -*- -*- -*- Now that I have located the papers with my old calculations, I find that the actual number of combinations for a Simplex lock is 1082 (even worse than the 1152 I remembered). Just for kicks, I calculated the effect of the "trick" I mentioned (lightly pressing some of the unused buttons and holding them while turning the knob). There are a total of 2163 combinations if you allow this. Perhaps this is what the manufacturer had in mind when claiming "greater than 2000" combinations, but the operating instructions expressly forbid doing this. What puzzles me is why the lock wasn't made with 6 buttons instead of 5. The number of combinations then rises to over a million (without "tricks") and security against manipulation is also improved, at least for combinations that use all the buttons. [Moderator add-on: The above-mentioned "trick" is Simplex's "high-security- mode", which in theory they only point out to their high-muckymuck military customers. Years ago at a locksmith show I had one of the Simplex reps set "some random combo" on one of their demos to see if I could open it; he used one of these and I couldn't get it open at the time, although I rolled out of bed with the answer the next morning... _H*] From: bobd@nisca.ircc.ohio_state.edu (Bob Debula) 8-MAR-1989 20:52:31 To: misc-security@cis.ohio-state.edu Subj: [476] NBS Encryption program for MVS or VM Does anyone know of a public domain or inexpensive encrytion/decryption package written using the NBS standard for IBM's MVS or VM operating systems? Please e-mail me directly. Thanks for your help. -- ------------------------------------------------------------------------------- Bob DeBula | Internet: debula-r@osu-20.ircc.ohio-state.edu The Ohio State University | | Disclaimer: These are my views, not the U's From: jimkirk@outlaw.uwyo.edu (Jim Kirkpatrick) 8-MAR-1989 20:57:15 To: security@pyrite.rutgers.edu Subj: [831] On DES' "breakability" It has often been said that DES *could* be broken by brute-force using lots of Cray-2 time and so on, and that the NSA caused the DES' key to be just short enough that they could break it but nobody else could. It appears now that such networks of workstations, fiddling in their "spare time" might also be able to pull off the same trick. Having not studied the DES in great detail yet, how easy is it to increase the key to 64 bits or more? Do the key scheduling tables need lots of work to derive? I heard once that the research behind parts of the algorithm were still classified. RSA keeps sounding better and better, if it could only be made reasonably quick. T. Okamoto proposed a much faster method that unfortunately results in ciphertext much larger than the plaintext (3:1); has this method been discredited yet? From: jimkirk@outlaw.uwyo.edu (Jim Kirkpatrick) 8-MAR-1989 21:38:57 To: security@pyrite.rutgers.edu Subj: [3225] RE: Burglar Invitations I suppose the following possibilities exist regarding lost keys -- 1. Permanently lost. In a field, down a rain gutter, dropped in curing cement, accidentally thrown out with the trash. Obviously no concern about how they're marked. 2. Lost, then found by an honest person who returns them. 3. Lost, found by an honest person who decides calling is too much bother, or that mailing them to the address is too much bother. Finder throws them away. 4. Lost, found by a dishonest person who would like to burgle you but is put off by the lack of a usable address. 5. Lost, found by a dishonest person who is both clever and intent on using the key(s). That last, and probably least likely, is what worries me. Given just phone number, what can be done? 1. Sequential search of the phone book. Not too likely, even here in Laramie :-) 2. Call Phone company and trick them into giving customer name and address, or just even name. I've heard varying stories on this such as claiming you got billed for a long-distance call to that number and wanting to know name & address to jog your memory before really getting angry at the company; or posing as a telco employee who needs address to work on the line. Bribes might work well too if you know the right people. Telling the truth might even work ("I found this key with the number..."). 3. There may be on-line ways to get this info, legitimately or otherwise. 4. There may be published cross-references (or maybe I'm thinking of street number back to name). 5. Call the phone number and ask for a street address so a free trip to Las Vegas can be awarded (YOU may not fall for this, especially if you KNOW you recently lost your key, but what about your 13-year old son?) Variations include long-lost cousins, and so on. Clearly, using a work number as described reduces possibilities. However, some companies may be more lax about giving out phone information or lists than THE phone company, and the list may be small enough to make a sequential search feasible. Given just a PO box number -- 1. Walk up to box, peek in window (if windowed) to try and find a readable name. Go to phone book. Even if you have an unlisted number or use your PO box in the phone book, there are other publications in the county library that may list your name and address given name. County records might also be a source. 2. Get the street address from the window jockey (may involve fast talk and/or bribe). I had to give this when I got my box in the first place. I don't know what the rules are on the USPS giving out this info or what they want it for in the first place. The only really safe thing to do is mark keys with somebody else's identity such as a trusted friend or a security service bureau. Or don't mark them, and if you lose one, either don't worry or re-key. Disclaimer -- I do not mean to imply that USPS or telco employees accept bribes, or to defame them in any way. Just considering possibilities, and you have to admit it must happen even if only infrequently. From: Steve Lesh (ISC | howard) 8-MAR-1989 22:43:41 To: security-request@pyrite.rutgers.edu Subj: [282] UNIX security programs If anyone has or knows where I can get a copy of the security programs in the book UNIX System Security by Patrick Wood & Stephan Kochan, I would appreciate hearing from you. I have the book but would like to avoid typing all these programs. Thanks in advance, Steven Lesh From: jimkirk@outlaw.uwyo.edu (Jim Kirkpatrick) 8-MAR-1989 22:52:53 To: security@rutgers.edu Subj: [1927] Question on block ciphers I have been reading up on DES and RSA encryption. I have a question that may or may not point out my ability to read :-) Let's take public-key encryption as typified by RSA. It is a "block" cypher in that any large message must be broken into a set of small pieces, then each piece is separately encrypted. For example if you have a 200-digit key, each piece should be no larger than 200 digits. Let's say I want to send the message -- DO NOT (block 0) DELETE (block 1) FILE 1 (block 2) If I encrypt these and send them to the destination, but the first block simply gets lost, the resulting message is quite different! An active eavesdropper will not be able to decypt them, but if he wants to be mischevious (at the expense of possibly exposing himself) he could, knowing my block length (after all the key is public), just drop a block. Likewise, upon gathering several messages I've signed, he could mix and match blocks, and end up with something that I have "provably" signed (since each block was signed) but is gibberish or by bad luck damaging. The latter is possible because he has access to both the ciphertext and plain text (by decrypting using my public key) and could "cut and paste" previously received encypted blocks. Unless I'm reading things wrong, RSA can only prove you signed a block, not the entire document. Am I missing something in the algorithm, that "binds" blocks in some way to prevent this, or is there an underlying assumption that external means will be taken to glue the blocks in some way? Clearly you could include block numbers inside each block to ensure block sequence and reception of all blocks, but this does not solve the issue of authentication of signed messages (which could still be cut-and-pasted), and it adds more overhead (though cheap overhead for RSA where blocks are large, this is bad news for DES where the blocks are only 64 bits). From: smiller@cs.umn.edu (Steven M. Miller) 9-MAR-1989 11:08:26 To: misc-security@rutgers.edu Subj: [342] Callback program wanted I'm looking for a "callback" program. i.e. a utility that will when a user dials into a computer and logs in over a phone line he is automatically logged out and the computer phones the user. Does anyone know of such a program for Unix machines? Preferably PD, but I will pay for one too. Thanks, -Steve -- -Steve Miller, U of MN From: James (J.G.)Borynec 9-MAR-1989 11:19:56 To: security@rutgers.edu Subj: [591] Shrink wrap not safe- yet another virus story Do not believe that shrink wrap is the safest way to go to avoid viral infection. In the last week, we have been hit by two garden variety nVIR viri. Both came from reputable companies. In fact, one came on the distribution disks for our Texas Instruments MicroExplorer. TI phoned us about it, and sent a virus remedy however. I can control what software I get from other people that I know, but it seems to me that I can't control, or even find out what precautions were taken before the shrink wrap was put on. Cheers ... J. Borynec Borynec@bnr.ca.bitnet (Bell Northern Research) From: eugene@eos.arc.nasa.gov (Eugene Miya) 9-MAR-1989 11:29:29 To: misc-security@ames.arc.nasa.gov Subj: [2646] Re: "Viri Logicum" >How can one defend against a virus unless they have one to look at? Yes there are very legit reasons for writing worms. You see the problem is that the biological analogy has overpowered your understanding of some of these programs. That is all they are, programs. At one time writing compilers and operating systems had a mystic "above" other programs. Then it was learned mere morals could do them (well, more mortals at least). This is even less so with worms and viruses which are much simpler. These programs are destructive in some way only because of intent. Programs of this structure can be found in system daemons, and they will become more prevalent as we increase our use of networks, distributed systems, remote servers, multiprocessors, and so on. The seeds of these issues could be found on Schoch et al's CACM paper on Worm Programs. When they were testing on the Xerox research net, were they stealing other people's evening cycles? Its gets worse. The problem is sort of like the popularity of the old TV show: Mission Impossible. They did neat things technically, but no one questioned whether they were doing legal or right things. The show went out of fashion during Watergate, perhaps during a fit of conscience. But now in the days of Lt. Col. Ollie North, the show reappears. The same sort of goes with computer security. Proposed laws are written by people who do not completely understand these issues. Security experts don't completely understand. It's interesting to note how many "experts" can't write a simple Trojan horse shell script. Remember they are just programs. Their harm is subject to human intepretation, and machines will have an even harder time discriminating. Will virus killing programs kill daemons by mistake? One last note: a short story. I work on some machines which are very fast. During the testing of one, I had a script of a workload which "got away." The point was to run continuously by forking a new child and dying. I tried killing it, but before I could, it always forked. This happened about 2 weeks before Morris. The initial shock (panic) hit me: multi-million dollar machine running amuck. If Morris did accidnetly lose his program, I think I know how he felt. I was at least able to kill mine. Another gross generalization from --eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov resident cynic at the Rock of Ages Home for Retired Hackers: "Mailers?! HA!", "If my mail does not reach you, please accept my apology." {uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene "Post follow ups. Contribute to network noise." From: haynes@ucscc.ucsc.edu (Jim Haynes) 14-MAR-1989 11:54:13 To: misc-security@ames.arc.nasa.gov Subj: [907] Re: Zero knowledge passwords? >A year or so back, users of the Cambridge University Computing Service were >hit by a password grabber which infested the BBC Micros used as terminals. Well, sure, if you're using micros as terminals, and the micros are publicly accessible or shared, then there are all kinds of possibilities for security cracking. In our environment the users who use public terminals seem to like the personalized password prompts, both for security and because they can be cute. All we claim for them is that they will sometimes defeat the most simple-minded password grabber programs; and that was the kind we tended to see often in the past. Now the method of attack has shifted to modern high-performance password guessing programs. haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ..ucbvax!ucscc!haynes "Any clod can have the facts, but having opinions is an Art." Charles McCabe, San Francisco Chronicle From: "John P. McNeely" 14-MAR-1989 12:14:13 To: security@rutgers.edu Subj: [1133] More virus references There are two other books I know of: 1) Dr. Fred Cohen offers a book entitled 'Computer Viruses'. It is based more on the theory and mathematical side of viruses. The book is very interesting. In order to get the book you must first contact Fred himself: Fred Cohen c/o Advanced Software Protection PO Box 90069 Pittsburgh, PA 15224 The book costs $20.00, which is supposed to include mailing expenses, with checks payable to Advanced Software Protection. 2) Recently, Abacus publishing has released a book which is causing some disturbance among the computer virus "authorities"; the book is entitled "Computer Viruses - A High-Tech Disease". This book gets extremely detailed whith actual code for various viruses on different systems. I'm still waiting on my copy but from what I hear it is a really good book. You can contact your local computer book store to get more info. Hope this helps. John P. McNeely BITNET: JMCNEELY@UTCVM.BITNET From: watrous@athos.rutgers.edu (Don Watrous) 14-MAR-1989 14:34:13 To: misc-security@rutgers.edu Subj: [405] Re: "Viri Logicum" Unlike their biological counterparts, computer viruses, worms, or what-have-you can be designed to die should they escape their test environment. I would *hope* these test viruses have such precautions included! If R. Morris didn't think to take such precautions, I can't have much sympathy for him. Don -- uucp: {ames, cbosgd, harvard, moss}!rutgers.edu!watrous arpa: watrous@aramis.rutgers.edu From: Xc60039@PORTLAND.BITNET (Douglas Howell) 14-MAR-1989 14:45:22 To: Security@pyrite.rutgers.edu Subj: [761] Fred Cohen Hi all, I was wondering there might be anyone who might be able to send me a copy of Fred Cohen's disertation on computer viruses? I've tried getting it thru the college's library but they have not gotten yet and I really wonder if they can. I was told that Mr. Cohen may be at the U. of Cincinatti, but as of yet I have not had the chance to confirm that. Anyone who has a copy of the disertation and is willing to send me a copy of it let me know okay. I've heard a lot about the paper and would really like to read it. Douglas Morrison Howell | Disclaimer: Niether the U. nor my boss Student of Engineering | knows what I'm saying so don't hold University of Southern Maine | them responsible for my inept behavior. From: eugene@eos.arc.nasa.gov (Eugene Miya) 14-MAR-1989 14:54:14 To: misc-security@ames.arc.nasa.gov Subj: [959] "Entering" by daemons The discussion about networks, distributed security, etc. brings up several issues. The issues are similar to the software licensing issue of program generators (like YACC). If programs execute programs which perform "irresponsible" acts, who is responsible? If daemons (written intentionally, obviously) do destructive acts, can increasing levels of indirection eliminate responsibility? The issue raised by program generators and licenses was who owns the generated program. The issue of daemons and program generators and security is whether continued abstraction will become a problem. Another gross generalization from --eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov resident cynic at the Rock of Ages Home for Retired Hackers: "Mailers?! HA!", "If my mail does not reach you, please accept my apology." {uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene "Post follow ups. Contribute to network noise." From: 14-MAR-1989 14:55:46 To: SECURITY@OHSTVMA Subj: [1288] Computer folklore Hello, My name is Mark Dawson. I am a student of Folklore and a computer consultant at Indiana University. I am currently working on a folklore project collecting computer folklore. I am sending this letter to several listservers to request contributions on the subject. What is computer folklore? I leave this to you decide. Some subjects I am interested in include: Hacking (feats and/or tech.) Phone Preaking (feats and/or tech.) The "Electronic Tribunal" Electronic executions These are just my particular interests, I am taking a "shotgun" approach to the subject. If you have any sort of computer story please send it on, whether you think it is folklore or not. It is not important if the information is first hand, second hand or 12th hand. Nor is it important -whether you may think the material is true or not . Myth and legend has reached the computer age, and has been going strong for 20 years. All contributions are greatly appreciated. Please send information to: Mark Dawson bitnet: DAWSONM@IUBACS ACCESS MicroCenter IMU 059b Indiana University 1(812)335-0910 Bloomington, In. 47405 This message has already been posted to the FOLKLORE list, please feel free to forward this to any other list though. Thank you M. Dawson From: hollombe@ttidca.tti.com (The Polymath) 14-MAR-1989 19:34:14 To: misc-security@sdcsvax.ucsd.edu Subj: [861] Re: Network security references? } A friend of mine (without access to news) plans to write a survey }paper on network security techniques. Does anyone have any good references }they could recommend? DOD 5200.28-STD Department of Defense Trusted Computer System Evaluation Criteria, December 1985 (aka "The Orange Book") NCSC-TG-005, v1 National Computer Security Center Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria, 31 July 1987 (aka "The Red Book") Both available for a minimal fee from the U.S. Government Printing Office in Washington, D.C. -- The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimati Nil Citicorp(+)TTI Carborundum 3100 Ocean Park Blvd. (213) 452-9191, x2483 Santa Monica, CA 90405 {csun|philabs|psivax}!ttidca!hollombe From: Keith Natschke <9070NATSCHKE@MUCSD.BITNET> 14-MAR-1989 19:54:14 To: security@pyrite.rutgers.edu Subj: [1219] VAX Encryption [Moderator injection: Replies to him, pls.. _H*] Hello, I'm interested in any information anybody has on DEC's VAX Encryption. As an educational site we can obtain it for just the cost of the media and documentation under DEC's CSLG program. We would be using it for encryption of confidential data such as payroll information. I'm mostly interested in: 1. How well does it work? 2. Is it easy to use? 3. Has anybody had any problems with it? 4. Can it be called from a program to encrypt specific fields in a file? 5. How is the key given to programs accessing the data? Thanks in advance! MM MM UU UU Keith S. Natschke Analyst/Programmer MMM MMM UU UU Marquette University Systems & Programming MMMM MMMM UU UU Computer Services Division MM MMMM MM UU UU 517 N. 14th Street MM MM UU UU Milwaukee, WI 53233 MM MM UUU UUU Phone: (414) 224-3765 MM MM UUUUUU BITNET: 9070NATS@MUCSD Marquette University INTERNET: 9070NATS%MUCSD.BITNET@CUNYVM.CUNY.EDU UUCP: ...psuvax1!mucsd.bitnet!9070nats From: ssr@cos.com (Dave Kucharczyk) 14-MAR-1989 20:14:15 To: misc-security@uunet.uu.net Subj: [4052] Spying on Consumers stolen from sci.electronics: From the "Security" column of the February/March 1989 issue of _Retailing Technology & Operations_, a supplement to _Women's Wear Daily_/_Daily News Record_. Reprinted without permission. MEET MISS ANNIE DROID By Hassell Bradley Denver (FNS) -- Don't look now, but that snazzy looking mannequin over there may be watching you -- and eavesdropping too. With a camera in her eye and a microphone up her nose, Anne Droid is the latest weapon in the growing arsenal of antishoplifting technology. Jerry Gutierrez, who owns Anne Droid Mannequins, a nationally known mannequin repair firm here, has developed a surveillance system that shoots videotape through a mannequin's eye and ties in to closed circuit TV networks. Besides its potential for spying on thieving shoppers or employees, the system also could be used to record customers' reactions to new products. According to Gutierrez, it fits into any type or size of mannequin head -- infant or adult -- as long as there is an eye opening of one-half inch. In the past two years Gutierrez has perfected Annie, named his company Anne Droid (he credits "Start Trek" with inspiring the name) and initiated patent proceedings. Although he manufactures mannequins himself, Gutierrez designed the surveillance system to fit just about any style mannequin a visual merchandiser wants. Gutierrez manufactures the various glass and metal fittings for his surveillance system. They include a special camera carriage, acrylic eyeballs through which the video camera films, special tubes, and contact lenses. "I went to an optometrist and had a prescription written out for exactly what I wanted for the eyeball," he said. "Then I went to a lens cutter and had him grind the lenses for me. But I soon learned to do that for myself." The camera has automatic iris control and automatic focusing, so every- thing is in focus within a range of lights and distances. Once Annie is installed inside a mannequin, the result is a fixed, closed circuit TV camera that shoots only in black and white. Gutierrez said he's received a positive reception from the stores he's shown the system to, but none have bought it yet. Peter Berlin, who runs a shrinkage consulting firm in Jericho, N.Y., was skeptical. "I want people to know that we have cameras," he pointed out. "I want to prevent theft, not detect it. I want a camera capable of shooting in more than one place at a time." Gutierrez maintained this device is intended to keep watch over specific, troublesome areas that the sweep cameras may be missing. "Anne Droid is not meant to be a full system," he noted. "It's meant to enhance dead spots -- for example, if you want to watch a particular cash register." The system shoots videotape in real time and can be hooked up with most VCRs, Gutierrez said. He suggested, however, that it be used with surveil- lance systems, which normally use time-lapse VCRs. The microphone, which is part of the camera, has a range of about 10 feet, depending upon background noise. "Most people believe, and they are correct, that it is illegal to record a private conversation. However, when a conversation takes place in a public setting, it can no longer be deemed private. Annie makes it possible for retailers to listen to customers discuss new products or services a store offers. Annie could be installed in dressing rooms, or at counters. And she would be ideal at trade shows." Gutierrez also can install Annie "blind:" (sic) After employees see certain mannequins have cameras in them, he can make all the mannequins look as though they too contain the system. Basic price, including the camera, four-inch monitor and 66 feet of cable, runs between $1100 and $1200. Including a Decter, Co. mannequin, it would be $1800. The cable length can be extended to 198 feet, but coaxial cable must be used if the cable has to be any longer. Annie hooks up to most closed circuit TV systems. From: (If it doesn't kill you, it's good for you.) 15-MAR-1989 3:26:13 To: security@pyrite.rutgers.edu Subj: [312] Unix passwords Regarding root/etc/passwd: Is there a known algorithm of reasonable running time that can decrypt passwords from passwd? (Not encode random combinations & compare the result, but work with the encrypted text to find the plaintext.) Seems an important question to me. Phil Goetz PGOETZ@LOYVAX.bitnet From: eugene@eos.arc.nasa.gov (Eugene Miya) 15-MAR-1989 3:32:19 To: misc-security@ames.arc.nasa.gov Subj: [620] Who really is CVIA? >In fact, according to published reports the Computer Virus Industry >Association Who really is this group? They appeared in the paper in prominence during the November Worm. What makes anyone think they can be trusted? Or are they a reactionary group? Another gross generalization from --eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov resident cynic at the Rock of Ages Home for Retired Hackers: "Mailers?! HA!", "If my mail does not reach you, please accept my apology." {uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene "Post follow ups. Contribute to network noise." From: rja 15-MAR-1989 3:34:18 To: security@uunet.uu.net Subj: [986] Secure Sun Workstations I am looking for information on the Sun Workstations that have a rated security in the OS and that have passed Tempest. Among the areas that I am interested in are: usability as compared with the standard Sun workstations ballpark cost differences the actual rating of SunOS by the NCSC or other agencies availability of such systems ability to connect to fibre-optic ethernets I imagine that these aren't of very general interest, so if people will Reply to me at one of the addresses below, I will summarise to the net. If you don't wish your reply quoted in my net summary, please clearly indicate that in your mail. Thanks ______________________________________________________________________________ GE-Fanuc North America, Charlottesville, VA, USA 22906 Internet (preferable): rja@edison.CHO.GE.COM UUCP (if you must): ...uunet!virginia!edison!rja ______________________________________________________________________________ From: Yuko Murayama (+44_1_387_7050 ext.3695) 15-MAR-1989 7:38:05 To: misc.security@purple.cs.ucl.ac.uk Subj: [260] an enquiry on papers Cc: murayama@purple.cs.ucl.ac.uk Could anyone give me the pointers to papers or books which present a good survey on existing symmetric and asymmetric encryption algorithms, please? I would like to know their pros and cons. Yuko Murayama Dept of Computer Science, University College London From: gwyn@brl.mil 15-MAR-1989 7:43:20 To: security@pyrite.rutgers.edu Subj: [280] Re: Breaking into computers is a crime, pure and simple There is no credible way to assess the true cost of that worm incident. For example, it is possible that the damage at BRL might have slipped improvements to armored fighting vehicles by a week. What would be the true cost of that, anyway? Dollars aren't a sufficient measure. From: lfoard@wpi.wpi.edu (Lawrence C Foard) 16-MAR-1989 0:16:54 To: misc-security@husc6.harvard.edu Subj: [2219] Re: Hard disk protection Remember on a PC unless there is hardware with a lock&key any one can still do anything they want. This software will certainly slow people down but I wouldn't trust it any more than a mainframe with public access. Even if DOS doesn't recognize the hard drive it is still possible to write software to access any section of the hard drive. The Encryption option may provide some more protection but I have seen programs that will let you crack DES encryption in about 30 minutes. Suppose this system has a UNIX like password file and you have just failed a course and your grades are on this system.... Reading data from the hard drive while not easy isn't that difficult. You happen to have an account on the machine so you setup a large file with known contents, and take out your DES cracker. 30 minutes later you have the encryption key, search the hard drive for the password file change the system administrator password to nothing. Login and pass the course.... Actually breaking into the system would take some work but what if the person just wanted to erase the hard drive? Then it is only necessary to write a lots of garbage data onto it. Unless the PC is behind locked doors I wouldn't trust anything important to this system. Now for something completely different... At least this isn't as bad as FAX documents being legally binding, I wonder how long it will take for some one to realize they can undetectably forge legally binding documents? Lets say you have just failed a course and you feel like getting back at the "evil" prof? Fortunitly your father law firm (Leech and son ambulance chasers) happens to have a board for there computer to transmit fax documents. You find all the paper work the FBI would fax to your local police department to have a child molester arrested, cut and paste a bit and fax it down to the police station. Since phone calls don't tell where they are coming from they will not realize that the documents are bogus until they deliver the "child molester" to the FBI. And they will never be able to find out who faxed them the documents. -- Disclaimer: My school does not share my views about FORTRAN. FORTRAN does not share my views about my school. From: ishikawa%ultra.DEC@decwrl.dec.com (Jim Ishikawa, DTN_293_5054) 16-MAR-1989 3:28:11 To: security@pyrite.rutgers.edu Subj: [383] RE: Login Insurance, CDC style It is possible to use encryption to increase the assurance that you can extend the trusted path beyond terminal servers to hosts. This can be done without changing existing network protocols. Along with some node authentication capabilities, data-link layer encryption can provide integrity protection and controlled access analogous to hardwired serial links. Jim Ishikawa DEC From: PJS%naif.JPL.NASA.GOV@Hamlet.Bitnet 16-MAR-1989 3:32:26 To: security%ubvm.bitnet@Hamlet.Bitnet Subj: [653] Re: Zero knowledge passwords? >A displayed number on the card changes every so >many seconds; to authenticate you simply type in the current number and >the system can authenticate you since it is time synced. How many seconds? Does this rely upon a chip in the card keeping time accurate to within a number of seconds over an operating lifetime of possibly years? If so, it better be more accurate than my digital watch - and that's a good one. I wouldn't trust it near the edges of its time spans. I don't see how else it can work unless it talks to the host to check that they're synched, which severely compromises the effectiveness. Peter Scott (pjs@grouch.jpl.nasa.gov) From: ddp@topaz.rutgers.edu (BiG WavE DavE) 16-MAR-1989 4:11:02 To: misc-security@rutgers.edu Subj: [984] On virus source codes and accessibility... Hiya folks, Remember that virus that hit almost every 'puter on the Arpanet last fall?? Well, I'm writing a paper on the debate on whether or not the source code of that virus (or any other virus affecting any other computer/network) should be accessible by the general public. I'll actually be defending one of the sides. Anyway, I need facts from both sides of the issue and I'm asking the general NET to help me out. So if you think you're qualified to... shall we say..."comment" on the issue, please send me e-mail. Remember, I need FACTS. Any pointers to any published articles about the subject would also be greatly appreciated. (Yes, I will be doing my own research as well.) Anyone wishing a copy of the finished paper can send me e-mail. Thanx in advance... -WavE (a.k.a. David Pascua) ddp@topaz.rutgers.edu ...!rutgers!topaz.rutgers.edu!ddp [Moderator add-on: replies ONLY to him, please. There's already been quite enough flaming about this issue... _H*] From: 16-MAR-1989 6:54:29 To: security@pyrite.rutgers.edu Subj: [156] Unix & DES Can someone tell me what the encryption algorithm is for: 1. UNIX crypt (the password encryption) 2. DES Phil Goetz PGOETZ@LOYVAX.bitnet From: rogers@marlin.nosc.mil (Rollo D. Rogers) 16-MAR-1989 6:57:29 To: BORYNEC@bnr.ca Subj: [149] Re: Shrink wrap not safe- yet another virus story Cc: security@rutgers.edu Why not take the same precautions you would for software of unknown pedigree before you let it loose on your fixed disk system? REgards, RollO~~ From: Don Chiasson 16-MAR-1989 7:13:25 To: security@pyrite.rutgers.edu, jimkirk@outlaw.uwyo.edu Subj: [598] DES Breakability Cc: G.CHIASSON@xx.drea.dnd.ca DES only has a 56 bit key - not 64 bit, which a number of people feel does not give sufficient security. It is possible to develop a system similar to DES with more bits, which the original implementation had. If more security is desired, the data could be double encrypted with two DES boxes with different keys in series (somehow my gut feeling does not like this), or with two DES boxes in parallel (e.g. one does the odd bits and the other the even bits). Assuming there are no trapdoors in DES, this would give a 112 bit key encryption without having to develop a new algorithm. Don From: Don Chiasson 16-MAR-1989 7:15:47 To: security@pyrite.rutgers.edu, tihor@acf6.nyu.edu Subj: [1176] Password length Cc: G.CHIASSON@xx.drea.dnd.ca The classic reference on letter probabilities in English is Shannon, "Prediction and Entropy of Printed English", Bell Systems Telephone Journal, Vol 30 no 1, pp.50-64, January 1951. An old book I have, "Information Theory and Coding", Abramson, 1961 gives the following information: - For a 27 letter equiprobable alphabet (A-Z,space) with no inter symbol dependency, the entropy or per symbol information content of the source is 4.75 bits/symbol. - If the probabilities of the symbols are included, ie ETAOIN.... the entropy becomes 4.03 bits/symbol. - If each letter depends only on the previous symbol, we get 3.32 bits/symbol; if on the previous two symbols, approximately 3.1 bits/symbol. - If the dependence is on all the preceding text, it is between 0.6 and 1.3 bits per symbol. One bit per symbol is often assumed. In other words given a long string of text, there is a 50% chance you can correctly guess the next letter. Thus using a long and correctly spelled English word does not give a great deal of password security. Violate one or more of these conditions and the problem of guessing a password is much more difficult. Don From: Root Boy Jim 17-MAR-1989 1:57:10 To: gwyn@smoke.brl.mil Subj: [402] Friction is your friend Cc: misc-security@uunet.uu.net As far as those "Cipher" lox (five bidirectional rocker switches) go, my favorite technique is to take a piece of chalk and rub it over all the ribs on the switches. When you come back a few days later, all the buttons used for the combination have been wiped clean. That leaves you only 24 (4*3*2*1) instead of 5040 (10*9*8*7). Catman Rshd Author of "The Daemonic Versions" From: deh@eng.umd.edu 17-MAR-1989 2:05:05 To: nichols@cbnewsc.att.com Subj: [910] Re: Simplex locks Cc: security@pyrite.rutgers.edu The number of combinations can be cut down quite a bit by spraying or dusting the button tops with an organic dye (or whatever) that will display pretty colors when illuminated with UV light. I always prefered a coupld of strange organic dyes used in dye lasers, but they are expensive, and a lot of comon household things work just as well (the proof is left as an exercise for the reader). For a portable UV light source, you can get fancy, but I like the little EPROM eraser lights. Small, portable, and intense. A battery powerd device would be better of course if 120VAC is not available in the target area. In any case, the buttons without powder left on them are the ones that you want to play with. This works great in elevators that have button code systems in them for after hours use. The MIT Media Lab is a good example of such a facility (I wonder if they still glow over there?). Doug From: (Tom, Tech. Support) 17-MAR-1989 5:08:29 To: security@pyrite.rutgers.edu Subj: [855] Appearances vs. Actualities Must be a real well-liked management team that feels they need bulletproof glass between them and the troops. I hope this was more to protect from unauthorized access rather than to protect from bullets. If so, it sure is better than window glass, but, as you state, overkill given the 3/4 inch plywood walls. On the other hand, those walls are tougher than you might think provided they are well built. I wouldn't want to try kicking it in! * HAVE A GOOD DAY * * * * Tom Mahoney * * Computer Electronics Tech. * * * * FRANKLIN & MARSHALL COLLEGE * * Computer Services * * Technical Support Center * * Lancaster, PA 17604-3003 USA * * (717) 291-4005 * * Bitnet Address: TOM@FANDM * ********************************* From: att!ulysses!smb@research.att.com 17-MAR-1989 5:28:29 To: att!misc-security Subj: [879] Re: Question on block ciphers For the reasons that you name, and others as well, block ciphers are not normally used straight. What you want to look into are the DES modes of operation; they're in FIPS 81, or ANSI X3.106. There are other, non-standard, modes as well. For message-at-a-time operation, many people use ``cipher block chaining''. It involves exclusive or-ing each input block with the output of the previous step before encrypting. That is, if C[i] is the ciphertext from encrypting P[i], each step looks like this: C[i] = E(P[i] ^ C[i-1]) Decryption is the reverse: P[i] = D(C[i]) ^ C[i-1] An initial value IV is used to start things off for block 1 when there is no C[0]. There is still some chance of cut&paste here; refer to any standard work on cryptography for details of the properties of this and other modes. I suggest Davies and Price's ``Security for Computer Networks''. From: deh@eng.umd.edu 17-MAR-1989 17:48:31 To: jimkirk@outlaw.uwyo.edu Subj: [501] RE: Burglar Invitations Cc: security@pyrite.rutgers.edu the way to get the address associated with a number is to call the phone company CNA (Customer Name and Address) bureau. this is used by various telco functions, and if you can get the phone number to it they usually don't require any id, etc. Otherwise, you will have to sweet talk the Business Office, or pretend that you are a long distance supplier and bullshit the group that handles them (different from the business office) into giving you the data. Doesn't sound too hard actually. Doug From: "MARTIN J MOORE" 17-MAR-1989 17:52:33 To: "security" Subj: [611] To mark or not to mark (keys, that is) Regarding the relative merits of marked and unmarked keys: Our local PBS television station sends its members a key ring marked with *their* address and a code number (unique to each ring). They keep a record of the code numbers. The idea is that the finder of a lost key ring will mail it back to the station, who will then forward it to the member. If the key ring is found by a dishonest person, there is no risk because there is no other identifying information on the key ring. (This of course assumes that the personnel at the PBS station are honest. But I'm willing to take my chances on that.) From: paul@csc_lons.arpa (paul@tb) 17-MAR-1989 18:07:19 To: security@pyrite.rutgers.edu Subj: [742] Forwarded: RE: Burglar Invitations Back in the 70's there existed something called a "Lineman's Book" published by the local phone companies. It cross refrenced name to address to telephone number. It also cross refrenced by address and by telephone number. I believe it also included curcuit numbers dealing with the phone line in question. I was supplied to linemen and listed all (even unlisted number) so the phone company people could do their work without calling a controller every 20 minutes. If this type of book still exists, and I think it would, paying an underpayed lineman $20.00 for a 2 minute look in "The Master Book". If I remember the lore properly the lineman had to sign out the book in the morning, and return it when done with his shift. From: gwyn@brl.mil 22-MAR-1989 12:37:26 To: security@pyrite.rutgers.edu Subj: [459] Re: On DES' "breakability" >It has often been said that DES *could* be broken by brute-force using >lots of Cray-2 time and so on, and that the NSA caused the DES' key to >be just short enough that they could break it but nobody else could. If NSA can indeed break DES, it's because they know more about cryptanalysis, not because they have bigger, faster computers for brute-force searching the key space. So, increasing the key size is not necessarily an effective countermeasure. From: Steve Lesh (ISC | howard) 23-MAR-1989 0:32:00 To: unix-wizards@brl.mil, info-unix@brl.mil Subj: [607] security validation programs Cc: security@pyrite.rutgers.edu Thanks to all for the rather amazing quantity of responses to my request for the security validation programs mentioned in the Kochan and Woods book on UNIX System Security. I NOW HAVE THE PROGRAMS. I think I responded to all requests to forward these programs. I would be willing to act as a manual file server providing things don't get out of hand. Anyone knowing anything about the legal implications of posting these programs to uunet archives might want to look into archiving the above. There certainly seemed to be a lot of interest! Thanks again for the all the responses to my request. From: gwyn@brl.mil 23-MAR-1989 1:43:30 To: security@pyrite.rutgers.edu Subj: [1429] Re: "Viri Logicum" >Will virus killing programs kill daemons by mistake? This is a very important point that deserves reemphasis. There is NO practical way to tell the difference between a legitimate utility program and a virus program. If the system privileges permit certain operations and my program performs those operations, it might be for a legitimiate function or it might be that I am maliciously exploiting a loophole in the system protection rules. It may even be in the shadowy area in-between, for example if I remove a huge scratch file that is keeping my application from getting enough disk space to perform its job. Should I be removing the scratch file or not? That's a matter of local system administrative policy. So far as system security is concerned, if the system permits it then it is legitimate. There are two things that can go wrong. A perfectly secure system can be misadministered, so that users are given more capabilities than intended. Or, the system security rules and implementation may have inadvertent loopholes. The combination of both factors was involved in the Internet worm incident. Automatic "virus killers" are completely misguided. If you know enough to identify inadvertent security loopholes or errors in system administration, you should be in a position to get them fixed. If your virus killer acts on any other grounds, then it will interfere with perfectly legitimate applications. From: scarter@caip.rutgers.edu (Stephen M. Carter) 23-MAR-1989 5:36:12 To: misc-security@rutgers.edu Subj: [581] Re: appearances vs. actualities >so they installed bullet-proof >glass in those windows. The trouble is, the windows are set in a wall >made of nothing more than 3/4" plywood and 2x2's. I don't know what they make out on the factory floor, but if it has anything that uses robot arms, milling machines, and the like, *I* would feel a lot better on having that nice thick and hefty glass around me than standard plate glass. A small metal object can be thrown a fair distance coming out of some machines. If that object hits a large plate glass area, watch out. They may not be more secure, but a lot safer. From: GREENY 23-MAR-1989 7:06:46 To: Subj: [579] re: Callback program wanted > I'm looking for a callback program... Hmmm...I have never seen/heard of such a beastie, as there are a variety of modems that will perform the same function, only with a much lower computer CPU usage rating than a program would have (i.e. the modem does most of the work...freeing up more CPU cycles...) Also, since their passwords are in EEPROM inside the modem, they are less vulnerable to attack than are passwords stored on a disk pack attached to a UN*X box.. Bye for now but not for long Greeny BITNET: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU From: Housley.XOSMAR@xerox.com 23-MAR-1989 20:36:26 To: security-request@pyrite.rutgers.edu, jimkirk@outlaw.uwyo.edu Subj: [783] Re: Question on block ciphers Cc: Housley.XOSMAR@xerox.com Jim Kirkpatrick: RSA provides authentication when the blocks are enciphered with the private key of the originator. RSA provides confidentiality when the blocks are enciphered with the public key of the recipient. There is common technique for getting both authentication and confidentiality of messages longer than the "block size" (200 digits in your example). First, encipher the message in a traditional block chaining cipher (like DES CBC). Then, take the key and IV used to encipher the message and encipher them twice with RSA -- once with the private key of the originator and once with the public key of the recipient. This give authentication and confidentiality of the entire message. The DARPA privacy-enhanced electronic mail (RFC 1040) uses this scheme. Russ From: WHMurray@dockmaster.arpa 23-MAR-1989 22:25:22 To: security@rutgers.edu Subj: [1176] DES and Long Messages >Am I missing something in the algorithm, that "binds" blocks in >some way to prevent this, or is there an underlying assumption >that external means will be taken to glue the blocks in some way? >Clearly you could include block numbers inside each block to >ensure block sequence and reception of all blocks, but this does >notsolve the issue of authentication of signed messages Yes, you are missing something, but it is not in the DES Standard. DES is a "block" cipher, i.e., it is designed to encode 64 bit blocks. Of course, the world is not made up of convenient 64 bit blocks, so there is another standard that describes the safe ways to compose it into mechanisms for messages of arbitrary length. Most of these add so much complexity as to be more secure than the DES primitive. William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 From: WHMurray@dockmaster.arpa 24-MAR-1989 0:06:03 To: security@rutgers.edu Subj: [1256] DES Key Length >Having not studied the DES in great detail yet, how easy is it to >increase the key to 64 bits or more? It is easy to achieve any effective key length that you desire. IBM uses a triple encryption technique in its 3848 channel-attached crypto engine to achieve an effective key length of 112 bits. (Three encryption steps are used in such a way that if the key is chosen with 56 bits repeated twice, then steps 1 and 2 cancel each other out. This permits compatability with the standard 56 bit software implementation.) ___________________________________________________________________ William Hugh Murray 216-861-5000 Fellow, 203-966-4769 Information System Security 203-964-7348 (CELLULAR) DOCKMASTER 2000 National City Center MCI-Mail: 315-8580 Cleveland, Ohio 44114 TELEX: 6503158580 FAX: 203-966-8612 21 Locust Avenue, Suite 2D Compu-Serve: 75126,1722 From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin) 24-MAR-1989 1:07:21 To: misc-security@att.att.com Subj: [1620] Re: On DES' "breakability" The first step of DES encryption is to convert the 56-bit key into 16 48-bit subkeys. This step is done by a series of shifts (rotates, really) and permutations. Presumably, other algorithms could be used to expand any reasonably-short key to 768 bits, or one could even specify a 768-bit key directly. I've seen something of the sort proposed in Cryptologia, but I'm not qualified to evaluate the merits of the proposal. Certainly, there are weaknesses to be avoided; for example, if all 16 subkeys are the same, the algorithm is much easier to crack. There are other patterns even in standard DES that can give rise to undesirable subkey structures (i.e., semi-weak keys). The controversial section is the S-box. It's undisputed that (a) NSA changed it; (b) there are regularities in it; (c) NSA has admitted to some of the design principles; and (d) no one has yet (publicly) found any way to use any of these quirks. It may even be true that these changes make DES stronger. Meyer and Matyas (in ``Cryptography: A New Dimension in Computer Data Security'') note that random S-boxes take fewer logic elements to implement than do the standard one, when expressed as the sum of Boolean minterms. They conjecture that this is significant. (Note: Meyer and Matas work for the group at IBM that designed DES in the first place. This may or may not make them credible; it does speak well of their knowledge.) > RSA keeps sounding better and better, if it could only be made reasonably > quick. Given recent progress in factoring, are you sure this is a good idea? I've redirected follow-ups to sci.crypt. From: att!iexist!nichols@research.att.com 27-MAR-1989 22:49:35 To: deh@eng.umd.edu Subj: [736] Re: Simplex locks Cc: security@pyrite.rutgers.edu WRT using fluorescent dye to determine used vs. unused buttons, I suspect that a solution of ordinary laundry detergent would be the most readily available. The brighteners glow brilliant white under UV. For Simplex locks, however, who needs it!? It only takes 1 to 2 minutes of manipulation to identify used and unused buttons, with no apparatus, power source, or even ambient light required. In the (uncommon) event that all the buttons were used, there are 541 combinations to try. If less, the math is definitely on your side. #buttons #comb 5 of 5 541 4 of 4 75 3 of 3 13 Bob Nichols nichols@iexist.att.com From: "Katherine J. Dante" 28-MAR-1989 0:32:14 To: James (J.G.)Borynec Subj: [505] Re: Shrink wrap not safe- yet another virus story Cc: security@rutgers.edu Since computer stores have the ability to re-shrink wrap software and allow customers to try the software out, I am not sure that shrink wrapping does any more than assure you that the price on the wrap is the price the store wants to charge for whatever is in the wrap. You certainly cannot tell whether you are getting all the disks/documentation that the manufacturer intended. And you have no assurance that some smart-aleck didn't plant a virus while "checking out" the program with his own disk. From: WHMurray@dockmaster.arpa 28-MAR-1989 0:38:36 To: security@rutgers.edu Subj: [580] [578] Return-path: Date: Sat, 11 Mar 89 00:19 EST From: WHMurray@dockmaster.arpa To: security@rutgers.edu >I heard once that the research behind parts of the algorithm were >still classified. IBM's discussion of how and why the S-boxes were selected was classified. However, all of the algorithm, including the S-boxes, is public. RSA's MailSafe, recently approved for use by the Internet Activities Board, implements a DES/RSA hybrid with the speed of the DES and all of the properties of the RSA. William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 From: rjg@sialis.mn.org (Robert J. Granvin) 29-MAR-1989 7:05:51 To: misc-security@uunet.uu.net Subj: [460] Security "journals" Quite some time ago, someone posted an address and telephone number of where to locate the "Rainbow Volumes". Would some kind soul email me that information? Thanks. -- Robert J. Granvin "Mueslix: A natural blend of oats, barley, National Information Services octopi, Toyotas, cement and small furry rjg@sialis.mn.org animals too slow to escape our field {amdahl,hpda}!bungia!sialis!rjg agents." --'corsair' From: pj@hrc63.co.uk (Mr P Johnson "Baddow") 29-MAR-1989 9:00:34 To: misc-security@ukc.ac.uk Subj: [1078] Unchanged combos (was Re: Friction is your friend) Yeah: a couple of things come to mind wrt unchanged combinations. My parents once stayed in a London hotel with punched cards for room keys. If you lost your card (or when you left) they just changed the combo and issued a new pair of "keys". At one point they had difficulty, so the maid came and unlocked their room with the master key. You could tell it was the master key because it had ALL its holes punched. In a similar vein, in "Surely your joking Mr Feynmann", Richard Feynmann describes how he cracked safes at Los Alamos. One of the safes was a super-strong secure safe installed by a Brass-Hat. When the safe was removed they had to open it. The local locksmith found that the Brass-Hat had never bothered to change the factory combo. Paul. [Moderator add-on: The punched cards were probably Yaletronics locks. If you want, I can dig up a generalized writeup on these hotel systems I did a while back. Howev