----MESSAGE-BEGIN---- <1989030101095200> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030101182300> 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! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030113175100> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030211450300> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030212050000> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030216330300> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030216494400> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030320303700> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030321140000> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030321572300> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030401570800> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030402053900> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030404521200> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030405024400> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030503264800> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030503464800> 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 -------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030610443600> 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* ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030623353400> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030706203100> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030706330300> 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! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030706411900> 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*] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030706530400> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030706551600> 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*] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030713123100> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030713171500> 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? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030713585700> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030715034100> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030715125300> 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). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030803282600> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030803395600> 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989030803492900> 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." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8903230135.AA01545@ucbarpa.Berkeley.EDU] <1989030918572000> From: lesh@BRL.MIL (Steve Lesh, ISC | howard) Newsgroups: misc.security Subject: security validation programs Message-ID: <8903230135.AA01545@ucbarpa.Berkeley.EDU> Date: 9 Mar 89 18:57:20 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Approved: security@rutgers.edu Posted: Thu Mar 9 19:57:20 1989 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8903230654.AA04916@ucbarpa.Berkeley.EDU] <1989031006223700> From: scarter@CAIP.RUTGERS.EDU (Stephen M. Carter) Newsgroups: misc.security Subject: Re: appearances vs. actualities Message-ID: <8903230654.AA04916@ucbarpa.Berkeley.EDU> Date: 10 Mar 89 06:22:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Approved: security@rutgers.edu Posted: Fri Mar 10 07:22:37 1989 >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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8903280148.AA19434@ucbarpa.Berkeley.EDU] <1989031121033100> From: nichols@iexist.UUCP Newsgroups: misc.security Subject: Re: Simplex locks Message-ID: <8903280148.AA19434@ucbarpa.Berkeley.EDU> Date: 11 Mar 89 21:03:31 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 Approved: security@rutgers.edu Posted: Sat Mar 11 22:03:31 1989 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8903290124.AA10733@ucbarpa.Berkeley.EDU] <1989031217024800> From: kdante@NOTE.NSF.GOV ("Katherine J. Dante") Newsgroups: misc.security Subject: Re: Shrink wrap not safe- yet another virus story Message-ID: <8903290124.AA10733@ucbarpa.Berkeley.EDU> Date: 12 Mar 89 17:02:48 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 Approved: security@rutgers.edu Posted: Sun Mar 12 18:02:48 1989 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8903290749.AA15797@ucbarpa.Berkeley.EDU] <1989031218144200> From: rjg@sialis.mn.org (Robert J. Granvin) Newsgroups: misc.security Subject: Security "journals" Message-ID: <8903290749.AA15797@ucbarpa.Berkeley.EDU> Date: 12 Mar 89 18:14:42 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Approved: security@rutgers.edu Posted: Sun Mar 12 19:14:42 1989 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' ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031304141300> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031304341300> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031306541300> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031307052200> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031307141400> 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." ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031307154600> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031311541400> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031312141400> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031312341500> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8903270740.AA03357@ucbarpa.Berkeley.EDU] <1989031315093900> From: Housley.XOSMAR@XEROX.COM Newsgroups: misc.security Subject: Re: Question on block ciphers Message-ID: <8903270740.AA03357@ucbarpa.Berkeley.EDU> Date: 13 Mar 89 15:09:39 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 Approved: security@rutgers.edu Posted: Mon Mar 13 16:09:39 1989 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031319461300> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031319521900> 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." ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031319541800> 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 ______________________________________________________________________________ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031323580500> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031400032000> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031416365400> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031419481100> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031419522600> 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031420310200> 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*] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031423142900> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031423172900> 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~~ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031423332500> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031423354700> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8903302323.AA16037@ucbarpa.Berkeley.EDU] <1989031513013100> From: greenber@utoday.UUCP Newsgroups: misc.security Subject: Who really is CVIA? Message-ID: <8903302323.AA16037@ucbarpa.Berkeley.EDU> Date: 15 Mar 89 13:01:31 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 21 Approved: security@rutgers.edu Posted: Wed Mar 15 14:01:31 1989 The CVIA has a rather interesting background. I'm *not* a member of the CVIA, althouhg I am an anti-virus vendor. The head honcho of the CVIA is a fellow named John McAfee. Mr. McAfee is an anti-virus vendor as well. His estimates of the virus infiltration and the damage caused by virus infiltration is a bit higher than I'm comfortable with. When speaking with the press, he oftentimes gets quoted using some rather extraodrinary numbers and facts, based upon his theories of "non-reporting" sites. My belief if that you can't say something like: "Only 15% of the sites with damage are talking about it" and then extrapolate out for the so-called missing sites. I hold his numbers in disbelief. Ross M. Greenberg Author, FLU_SHOT+ Ross M. Greenberg UNIX TODAY! 594 Third Avenue New York New York 10016 Review Editor Voice:(212)-889-6431 BBS:(212)-889-6438 uunet!utoday!greenber BIX: greenber MCI: greenber PCMagNet: 72241,36 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8904030450.AA04931@ucbarpa.Berkeley.EDU] <1989031516173400> From: stev@VAX.FTP.COM Newsgroups: misc.security Subject: Unix passwords Message-ID: <8904030450.AA04931@ucbarpa.Berkeley.EDU> Date: 15 Mar 89 16:17:34 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Approved: security@rutgers.edu Posted: Wed Mar 15 17:17:34 1989 * Regarding root/etc/passwd: Is there a known algorithm of *reasonable running time that can decrypt passwords from passwd? (Not yes. (actually, it *may* not generate the original password, but it *will* generate one that will encrypt into the same thing.) scary, isnt it?:) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8903310006.AA17099@ucbarpa.Berkeley.EDU] <1989031516272700> From: Hoffman.ElSegundo@XEROX.COM Newsgroups: misc.security Subject: Theft-proof car lock? Message-ID: <8903310006.AA17099@ucbarpa.Berkeley.EDU> Date: 15 Mar 89 16:27:27 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 Approved: security@rutgers.edu Posted: Wed Mar 15 17:27:27 1989 >From: Rodney Hoffman This piece ran in 'Business Week' magazine, March 13, 1989, p. 77: TV TECHNOLOGY MAY KEEP CARS SAFER FROM THIEVES Looking for a better car security system? Take another look at your TV. Using the same technology that sharpens TV images, GTE Corp. scientists have up with a new theft-proof locking system. The device uses the properties of SAW -- surface acoustic waves -- to activate a tiny coil embedded in a car key. As the key turns to open the door or start the engine, the coil sends out a coded digital signal needed to unlock or start the car. GTE makes similar SAW filters to lock in color TV tuners on each channel. GTE's auto-lock system, called SAFE for surface acoustic filter encoding, has the advantage of being completely passive: There are no codes to memorize or alarms to disarm. And unlike other antitheft locks, SAFE needs no electrical contact -- or even teeth on the key. Eventually, keys for individual drivers could be encoded to automatically adjust the seats and mirrors. So far, GTE has gotten "a strong response" in Detroit, says Scott L. Atkinson, marketing specialist with GTE's Elec- tronic Components & Materials Div., who thinks auto makers may offer SAFE within two years. Also eyeing the system, says Atkinson, are foreign carmakers and major U.S. car insurers, who are battling $6 billion a year in U.S. car-theft losses. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031518171000> 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" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031518250500> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031521282900> 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 * ********************************* ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031521482900> 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''. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8904030645.AA06033@ucbarpa.Berkeley.EDU] <1989031604000200> From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin) Newsgroups: misc.security Subject: Re: Unix passwords Message-ID: <8904030645.AA06033@ucbarpa.Berkeley.EDU> Date: 16 Mar 89 04:00:02 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 30 Approved: security@rutgers.edu Posted: Thu Mar 16 05:00:02 1989 > Regarding root/etc/passwd: Is there a known algorithm of > reasonable running time that can decrypt passwords from passwd? No, there's no known algorithm. Oh, you want more? Neglecting the salt for the moment, password-hashing is done by repeatedly encrypting a constant string with the user's password as the key. The encryption algorithm used is DES. Deducing the password is therefore the same as the following: given a known plaintext (the constant), and a known ciphertext, find the key. This is equivalent to cracking DES, which has not been demonstrated to be possible, at least to those of us who don't work for the NSA, the KGB, or equivalent. And, given that the encryption is repeated many times (just to slow things down), the problem is harder yet. Finally, even if NSA can crack DES -- and that seems not improbable -- it's quite likely that they require much more plaintext than 8 bytes. (Unless, of course, the S-box is really a trapdoor function, to which they have the matching key.) Two caveats. First, the set of ASCII password doesn't come close to exhausting the DES key space. It isn't clear to me how much of a difference that makes, since all bits in the key are settable. Second, the password hash salt function permutes the E-box; there has been evidence presented that this weakens the encryption somewhat. I have no idea if that would help cryptanalysis in a practical sense, especially given the limited plaintext available. For details on how the password algorithm got to be the way it is, read ``UNIX Password Security'', R. Morris and K. Thompson, CACM, Vol. 31, No. 5 (May 1988), p. 484. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031610083100> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031610123300> 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.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989031610271900> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8904060227.AA12826@ucbarpa.Berkeley.EDU] <1989031614125800> From: lg@computer-lab.cambridge.ac.uk Newsgroups: misc.security Subject: Re: Fred Cohen Message-ID: <8904060227.AA12826@ucbarpa.Berkeley.EDU> Date: 16 Mar 89 14:12:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 22 Approved: security@rutgers.edu Posted: Thu Mar 16 15:12:58 1989 > 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 could have replied via private email, but I think this might be interesting to the general public. I made an enquiry to U. of Southern California where Dr. Cohen did his Ph.D. USC Library replied that there was an indefinite hold on his thesis and could not be released without further notice. After I got this reply, I read in the newsgroup comp.risks that Do. Cohen claimed he could supply the copy with a minimum fee. I emailed his enquirying whether the hold on his thesis has been lifted. Didn't get any response. A paper on the same topic can be found in the Proceedings of the 7th DoD/NBS Computer Security Conf. 1984. ____________________________________________________________________________ | Li GONG (+44223-334650) University of Cambridge, Computer Laboratory | | Pembroke Street, Cambridge CB2 3QG, England | | 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 | ---------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8904060135.AA12039@ucbarpa.Berkeley.EDU] <1989031619522200> From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin) Newsgroups: misc.security Subject: Re: Unix & DES Message-ID: <8904060135.AA12039@ucbarpa.Berkeley.EDU> Date: 16 Mar 89 19:52:22 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Approved: security@rutgers.edu Posted: Thu Mar 16 20:52:22 1989 > 1. UNIX crypt (the password encryption) See the Morris and Thompson paper in the November 1979 issue of CACM. > 2. DES Lots of places describe it; I recommend Davies and Price's book ``Security for Computer Networks'', or Beker and Piper's ``Cipher Systems''. The latter includes the full text of the federal publication announcing it. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8904060056.AA11350@ucbarpa.Berkeley.EDU] <1989031620223400> From: BRUCE@UMDD.UMD.EDU (Bruce Crabill) Newsgroups: misc.security Subject: DES Breakability Message-ID: <8904060056.AA11350@ucbarpa.Berkeley.EDU> Date: 16 Mar 89 20:22:34 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 Approved: security@rutgers.edu Posted: Thu Mar 16 21:22:34 1989 Double encryption using DES (or anything else for that matter) gives you an effective 57 bit key, not 112. By doubly encrypting something, you are just making it twice as hard to break, or one extra power of two. It is n**2 as much work, not n**n. Bruce ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8904071952.AA13762@ucbarpa.Berkeley.EDU] <1989031622595400> From: scc@computer-lab.cambridge.ac.uk (Stephen Crawley) Newsgroups: misc.security Subject: password grabbers Message-ID: <8904071952.AA13762@ucbarpa.Berkeley.EDU> Date: 16 Mar 89 22:59:54 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 41 Approved: security@rutgers.edu Posted: Thu Mar 16 23:59:54 1989 >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. Granted. However, zero knowledge authentication implemented in the right way (e.g. with some sort of smart card) WOULD give security against account stealing/password grabbing. It wouldn't give you secure communications ... but that is a different issue. I'm not sure if I made it clear in my original posting, but a password grabber could well reside in the comm's network. Saying, "don't use micro's as terminals ... " is not a solution. >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 But unfortunately that is not our experience. I'm talking about how the problem can be solved. Making it harder to steal passwords is not going to deter the determined hacker ... and our experience is that some hackers are VERY determined. >Now the method of attack has shifted to modern high-performance password >guessing programs. Actually, my feeling is that this is an easier problem to solve: 1) Make the encrypted passwords inaccessible to normal users. & 2) Log failed login attempts. & 3) Stop users from setting their passwords to something that is guessable. Use rules like: at least N characters, no words in a dictionary, at least 1 non-alphabetic character, etc. Point 1) means that the hacker grab a file of encrypted passwords and feed them through a password guesser. Instead the hacker has to try each password guess with the login program, which will show up in your logs (hence point 2). Point 3) means that the hacker is going to have to try a LOT of password guesses. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8904072106.AA15388@ucbarpa.Berkeley.EDU] <1989031700445600> From: gwyn@BRL.ARPA (Doug Gwyn (VLD/VMB) ) Newsgroups: misc.security Subject: Re: Unix passwords Message-ID: <8904072106.AA15388@ucbarpa.Berkeley.EDU> Date: 17 Mar 89 00:44:56 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 31 Approved: security@rutgers.edu Posted: Fri Mar 17 01:44:56 1989 > Regarding root/etc/passwd: Is there a known algorithm of >reasonable running time that can decrypt passwords from passwd? None have been published. (Actually, without looking into it in detail, it might be possible that more than one password would produce the same encrypted result, so such an "inverse DES" would compute A password, not THE password.) > 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 LUCIFER differed from DES in other ways, too. The often-heard suggestion that DES needs a longer key is always based on the notion of making brute-force search of the entire key space impractical. However, that is by no means the only method of attacking such a system; you should therefore not trust increased key length as providing substantially more security. If the 56-bit key space could indeed be affordably searched in a modest amount of time with available computer resources, then indeed it would be too short; a sufficiently long key to render brute-force key searching impractical is NECESSARY but not SUFFICIENT for secure encryption. sci.crypt is probably a better newsgroup for cryptographic discussions. [Moderator tack-on: Agreed. If we move the DES stuff there, traffic will be more balanced between the respective lists. Unfortunately it's harder than I'm willing to deal with to forward the stuff from here to there on a message-by-message basis, so look for a big lump of "the rest of this" in sci.crypt soon. _H*] ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8904070714.AA04976@ucbarpa.Berkeley.EDU] <1989031704512400> From: deh@eng.umd.edu Newsgroups: misc.security Subject: Re: DES Breakability Message-ID: <8904070714.AA04976@ucbarpa.Berkeley.EDU> Date: 17 Mar 89 04:51:24 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 28 Approved: security@rutgers.edu Posted: Fri Mar 17 05:51:24 1989 As mentioned, you can make two (or more) passes through the DES for additional security. Dons 'gut feeling' about this maybe not being a good idea pertains I am sure to the possibility of patterns forming from the multiple runs through the data; this is possible with a lot of crypto systems, and I would not be suprised if it was the case with DES. Note that knowing how many passes were made, and with what key length (another GREAT variable you can use) is very important. It is not easy to break things when you have no idea how many passes were made, and what the key lengths were. Still, the best thing is the 300 meg disk pack, delivered to all of the sites on the network by the boys in green armed to the teeth, containing the oh_so_secure one time pad. The military actualy does this in some special cases, and it really is a very good idea; it reduces a comm and computer security risk (which they may not have a lot of experience in) to a straight forward physical security risk (which they have a lot more experience in and are more prepared to handle). Of course, for a network of more than 20 or so sites, it DOES get to be a bit of a bother. Also, if there is a lot of data moving, then you just want to use the one time pad data as keys (but maybe VERY long ones!) and run some normal encryption system. Anyone want to figure out how many packs (oppsss... Its 1989 now, lets use CD-ROMs) it would take to secure the internet? Doug ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8904070619.AA04534@ucbarpa.Berkeley.EDU] <1989031716320000> From: DLV@CUNYVMS1.BITNET Newsgroups: misc.security Subject: Re: DES Breakability Message-ID: <8904070619.AA04534@ucbarpa.Berkeley.EDU> Date: 17 Mar 89 16:32:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Approved: security@rutgers.edu Posted: Fri Mar 17 17:32:00 1989 Don Chiasson suggests applying DES twice. I just wish to remind that it has not been shown that this differs from applying DES once with some third key (in the appropriate jargon, we don't know whether it's a group). Although it is generally believed to be the case, one should probably make appropriate disclaimers when making such suggestions, etc, etc, ad naus... Dimitri Vulis Math Department CUNY GC ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8904070638.AA04703@ucbarpa.Berkeley.EDU] <1989032015255200> From: heilpern@BRL.MIL Newsgroups: misc.security Subject: Re: Unix passwords Message-ID: <8904070638.AA04703@ucbarpa.Berkeley.EDU> Date: 20 Mar 89 15:25:52 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Approved: security@rutgers.edu Posted: Mon Mar 20 16:25:52 1989 > 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. To the best of my understanding, as stated in a few books I've read (the titles escape me) the algorithm unix uses to encrypt passwords is irreversable, letters being changed according to previous letters before change. Also, the fact that ALL encryptions yield 13 characters (actually, 11 characters and a two character key) seem to suggest this. Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989032104572600> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989032116520000> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989032118033000> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989032121561200> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989032123264600> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989032212562600> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989032214452200> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989032216260300> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989032217272100> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989032615093500> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989032616521400> 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989032616583600> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989032723255100> 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' ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989032801203400> 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. However, the master key would be something other than all-holes-punched. Unless this was something a good deal more stupid than a Yaletronics... _H*] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989032914372200> From: utoday!greenber@uunet.uu.net 30-MAR-1989 22:17:22 To: security@pyrite.rutgers.edu Subj: [971] Who really is CVIA? The CVIA has a rather interesting background. I'm *not* a member of the CVIA, althouhg I am an anti-virus vendor. The head honcho of the CVIA is a fellow named John McAfee. Mr. McAfee is an anti-virus vendor as well. His estimates of the virus infiltration and the damage caused by virus infiltration is a bit higher than I'm comfortable with. When speaking with the press, he oftentimes gets quoted using some rather extraodrinary numbers and facts, based upon his theories of "non-reporting" sites. My belief if that you can't say something like: "Only 15% of the sites with damage are talking about it" and then extrapolate out for the so-called missing sites. I hold his numbers in disbelief. Ross M. Greenberg Author, FLU_SHOT+ Ross M. Greenberg UNIX TODAY! 594 Third Avenue New York New York 10016 Review Editor Voice:(212)-889-6431 BBS:(212)-889-6438 uunet!utoday!greenber BIX: greenber MCI: greenber PCMagNet: 72241,36 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989032915211100> From: rja 30-MAR-1989 23:01:11 To: misc-security@edison.cho.ge.com Subj: [1152] Secure Sun Workstations (summary) I got several good reponses to my request for information on secure Sun workstations. In particular, Daniel Faigin wrote and said that he checked on dockmaster.NCSC.MIL and found that the Sun products are not yet on the NCSC's Evaluated Products List and do not have an official rating yet. Jeff Edelheit wrote and offered good information and then was able to get me a copy of Sun's Product Announcement which I summarise from below. He also reports that a "compartmented mode" workstation is under development with a target of B1 security rating, but is farther out in development than the ordinary B1-rated SunOS. Thanks to everyone for quick and helpful responses. (The below is summarised from Sun's Announcement.) Sun is developing a version of SunOS called "SunOS MLS" (Multi-level Security) for the Sun-3, Sun-4, and TEMPEST Suns. The goal is to make B1 level security with the product. They plan for first customer shipments in June 1989. Cost will be $3000 for a 2-user license. NFS has been enhanced to be more secure and fibre-optic network cabling is also supported. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989032915214900> From: Hoffman.ElSegundo@xerox.com 30-MAR-1989 23:01:49 To: SECURITY@pyrite.rutgers.edu Subj: [1503] Theft-proof car lock? Cc: Hoffman.ElSegundo@xerox.com From: Rodney Hoffman This piece ran in 'Business Week' magazine, March 13, 1989, p. 77: TV TECHNOLOGY MAY KEEP CARS SAFER FROM THIEVES Looking for a better car security system? Take another look at your TV. Using the same technology that sharpens TV images, GTE Corp. scientists have up with a new theft-proof locking system. The device uses the properties of SAW -- surface acoustic waves -- to activate a tiny coil embedded in a car key. As the key turns to open the door or start the engine, the coil sends out a coded digital signal needed to unlock or start the car. GTE makes similar SAW filters to lock in color TV tuners on each channel. GTE's auto-lock system, called SAFE for surface acoustic filter encoding, has the advantage of being completely passive: There are no codes to memorize or alarms to disarm. And unlike other antitheft locks, SAFE needs no electrical contact -- or even teeth on the key. Eventually, keys for individual drivers could be encoded to automatically adjust the seats and mirrors. So far, GTE has gotten "a strong response" in Detroit, says Scott L. Atkinson, marketing specialist with GTE's Elec- tronic Components & Materials Div., who thinks auto makers may offer SAFE within two years. Also eyeing the system, says Atkinson, are foreign carmakers and major U.S. car insurers, who are battling $6 billion a year in U.S. car-theft losses. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1989032915345900> From: KARYN@nssdca.GSFC.NASA.GOV 30-MAR-1989 23:14:59 To: security@rutgers.edu, eugene@eos.arc.nasa.gov Subj: [2280] Re: Info on CVIA I was curious about the Computer Virus Industry Association, too, and eventually got an address and phone number and got the following info. They charged me 3 or 5 bucks for this info, and they also told me to send a stamped, self addressed envelope with $1.70 in stamps on it. Basically its an 'association' in the loosest sense of the word, they are a bunch of consultants who will tell you what you always wanted to know about viruses. To join the association, your company sends them a yearly check for $200 and you will be informed about viruses. Seems to me you pay $200 for their consulting services about viruses, and since they call you a 'member' they encourage you to tell them all you know about viruses, so they can then sell that information to the next person. This association is probably good for people in companies where there is no other way of getting the info, but for anyone with access to this or any other security list the association is probably a waste of money. (author's note: I just read over what I wrote, and it sounds like I am putting this association down, I don't mean it to come out like that) Included in the packet are: 1. Cover letter describing company history, etc 2. list of "Companies Providing Anti-Viral Products and Services" 3. what looks like a copy of a presentation titled, "Computer Viruses: Background, Detection and Recovery" 4. Another presentation titled, "Anti-Viral Product Classifications" 5. A short document titled "Anti-Virus Measures" containing common sense information on how to keep your computer secure (e.g. never boot from a floppy drive) 6. Another presentation titled, "The Six Most Common Computer Viruses". Contains info on Pakistani brain, scores, israeli, nvir, alameda, and lehigh. 7. CVIA membership application For more info about what you get for your five bucks, contact KARYN@nssdca.gsfc.nasa.gov And here's the address of the CVIA: John D. McAfee, Chairman CVIA 4423 Cheeney Street Santa Clara, CA 95054 tele (408) 988-3832 note: If you call the above number they will answer the phone with 'Interpath Corporation'..the address and phone for the CVIA is the same as one in the list of companies providing anti-viral products and services. ----MESSAGE-END----