|
|
ARCHIVE: Rutgers 'Security List' (incl. misc.security) - Archives (1989)
DOCUMENT: Rutgers 'Security List' for April 1989 (69 messages, 44444 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1989/04.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- From: stev@vax.ftp.com 3-APR-1989 3:09:40 To: security@pyrite.rutgers.edu
* 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?:)
-----------[000001][next][prev][last][first]---------------------------------------------------- From: greg@uts.amdahl.com (Greg Bullough) 3-APR-1989 3:55:02 To: misc-security@ames.arc.nasa.gov
> Regarding root/etc/passwd: Is there a known algorithm of >reasonable running time that can decrypt passwords from passwd? No. You expect someone running on a UNIX system to say "yes," even assuming (hypothetically) that the answer is "yes?" One wonders how questions like this leak through in a "moderated" group. Greg [Moderator tack-on, as you might expect: There's obviously a lot of disagreement and/or obfuscation surrounding this topic, as shown by the recent lot of messages. Let's try to keep things factual here, okay? Now, ignoring this for the moment, I should point out that sometimes everyone learns something when a "naive" question and several answers float by. Experienced people may occasionally forget the innocent or obvious, which may contain something important. Answering with misinformation is worse than useless, for the original asker and everyone else who's reading. _H*]
-----------[000002][next][prev][last][first]---------------------------------------------------- From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin) 3-APR-1989 3:56:46 To: misc-security@att.att.com
> 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.
-----------[000003][next][prev][last][first]---------------------------------------------------- From: Bruce Crabill <BRUCE@umdd.umd.edu> 6-APR-1989 0:19:38 To: security@pyrite.rutgers.edu
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
-----------[000004][next][prev][last][first]---------------------------------------------------- From: zhu@paul.rutgers.edu (Yi Zhu) 6-APR-1989 0:35:29 To: misc-security@rutgers.edu
Phil Goetz asks for the encryption algorithms for the UNIX crypt and DES, I am not too familiar with the UNIX crypt(I read a paper by Ken Thompson and Robert Morris a while ago, they seemed to talk about it, but not in any details), but you can find all the gory details about DES from Federal Information Processing Standads Publication 46, which is Specifications for the Data Encryption Standard. Yi
-----------[000005][next][prev][last][first]---------------------------------------------------- From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin) 6-APR-1989 1:05:57 To: misc-security@att.att.com
> 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.
-----------[000006][next][prev][last][first]---------------------------------------------------- From: "Craig Finseth" <fin@uf.msc.umn.edu> 6-APR-1989 1:15:55 To: security@pyrite.rutgers.edu
> >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. The cards that I have seen are called the SecurID card (probably TM) and are available from: Security Dynamnics 2067 Massachusetts Avenue Cambridge, MA 02140 (617) 547-7820 >How many seconds? I believe that update intervals are selectable (at ordering time) from 30 seconds, 1 minute, and 2 minutes. > Does this rely upon a chip in the card keeping time accurate to > within a number of seconds over an operating lifetime of years? Yes. Lifetime is also specified at ordering time. I think that 2 years is the limit. As many hosts are set to "watch time," the validation software incorporates the obvious slew tracking features that would be necessary. Thus, the internal clock must be good, but not incredibly so. I am just relaying this information. The usual disclaimers apply: I'm not affiliated with the vendor, nor am I a customer of theirs. Craig A. Finseth fin@msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375
-----------[000007][next][prev][last][first]---------------------------------------------------- From: lg@computer_lab.cambridge.ac.uk 6-APR-1989 1:51:51 To: security@rutgers.edu
> 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 | ----------------------------------------------------------------------------
-----------[000008][next][prev][last][first]---------------------------------------------------- From: "Craig Finseth" <fin@uf.msc.umn.edu> 6-APR-1989 2:02:01 To: security@pyrite.rutgers.edu Cc: lfoard@wpi.wpi.edu
> ...but I have seen programs that will let you crack DES encryption > in about 30 minutes. This is a strong statement. If true, it has enormous ramifications for cryptography as many encryption systems are built around DES. I have some questions: 1) Do you have direct (first hand knowledge through actual use) or indirect (a friend that...) knowledge of this program? 2) Is the program attacking true DES or some PC software companies "proprietary 'uncrackable'" scheme? 3) Does the attack work through chosen plaintext, plaintext, or ciphertext only? 4) What are the hardware/time requirements? (I.e., is the 30 minutes on an IBM P.C. or a bank of 100 CRAY-2s...) 5) When was the program written? By whom? At where? 6) Was the program based on published research? If so, I would like a citation. 7) How does the attack work? (Just a general idea, I'm not asking for code.) Thank you for your time. I'm sure that many other people are interested in this matter. Craig A. Finseth fin@msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375
-----------[000009][next][prev][last][first]---------------------------------------------------- From: <DLV@CUNYVMS1.BITNET> 7-APR-1989 5:45:37 To: security@pyrite.rutgers.edu
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
-----------[000010][next][prev][last][first]---------------------------------------------------- From: heilpern@brl.mil 7-APR-1989 5:56:59 To: security@pyrite.rutgers.edu
> 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
-----------[000011][next][prev][last][first]---------------------------------------------------- From: TomZ@ddn1.arpa 7-APR-1989 5:58:41 To: security-request@rutgers.edu, pjs@nasa.gov
There are several companies that market the SmartCard ID technology. I'm reasonably familiar with SecureID from Security Dynamics, Inc. The change rate is selectable (by the vendor). This technology does *NOT* depend on the card keeping super-accurate time over an extended span. The HOST keeps a range of access keys (nominally the current key (based on the system clock), the last ten keys, and the next ten keys) and resync's itself (via a drift fudge- factor) every time that user ID's him/herself. Drift becomes a problem only when a user vanishes for an extended period. NOTE: While one might be concerned about allowing the key to vary over a "spread", there are checks to notify "responsible persons" if the drift starts wandering too much. /s/: Tom Zmudzinski (TomZ @ ddn1.arpa) Defense Communications Agency (703) 285-5333 (DSN) 356-5333
-----------[000012][next][prev][last][first]---------------------------------------------------- From: jimkirk@outlaw.uwyo.edu (Jim Kirkpatrick) 7-APR-1989 6:28:34 To: SECURITY@pyrite.rutgers.edu
Gwynn@brl.mil says that if NSA can break DES it's because they know more about cryptanalysis. This seems to contradict the fact (found by congressional investigation) that NSA did indeed influence the decision to use 56 bits instead of 64 or more for the key. If increasing the key size is not necessarily an effective countermeasure, why did they do that? And if they can break DES by cryptanalysis, why do they have God-knows-how-many gigaflops of compute power? I do admit they probably know more about cryptanalysis than the average guy, and they probably have other uses for their computers than brute-forcing DES texts. But in view of their involvement with the key size, there is a strong implication that key size is important. They probably use both their expertise as well as compute power to do their job, whatever that is.
-----------[000013][next][prev][last][first]---------------------------------------------------- From: deh@eng.umd.edu 7-APR-1989 6:32:39 To: G.CHIASSON@xx.drea.dnd.ca Cc: security@pyrite.rutgers.edu
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
-----------[000014][next][prev][last][first]---------------------------------------------------- From: herbison%ultra.DEC@decwrl.dec.com (B.J.) 7-APR-1989 6:33:35 To: security@pyrite.rutgers.edu
The serial option is a good idea, but the parallel option you
mention is not very useful: It would only double the time it
would take to break the message because a cracker could crack
the even bits separately from the odd bits. This would be the
same difficulty as breaking a system with a 57 bit key.
Using two DES algorithms in series won't necessarily be the same
as a 112 bit algorithm, but breaking it will be much harder than
breaking a 56 bit algorithm.
Actually, ANSI has already used double length DES keys in some
of their financial security standards. By their definition, a
double length DES key consists of a left half and a right half,
each of which is a DES key, and encryption is defined as:
E[key](data) = E[key.left]( D[key.right]( E[key.left( data)))
In other words, encrypt with the left half, decrypt with the
right half, and encrypt with the left half again. Decryption is
performed by decryption, encryption, decryption.
The reason for the three steps is not increased security.
Notice that if key.left and key.right are the same DES key than
the double length encryption function is identical to a standard
DES encryption function with one of the halves of the key.
This means that hardware designed to implement their double
length-key variant of DES can also perform single length DES
with no modification.
B.J.
-----------[000015][next][prev][last][first]---------------------------------------------------- From: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn@brl.arpa>) 7-APR-1989 18:04:40 To: security@rutgers.edu
> 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*]
-----------[000016][next][prev][last][first]---------------------------------------------------- From: Stephen Crawley <scc@computer_lab.cambridge.ac.uk> 7-APR-1989 18:41:14 To: misc-security@ukc.ac.uk
>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.
-----------[000017][next][prev][last][first]---------------------------------------------------- From: katz@venera.isi.edu (Alan R. Katz) 13-APR-1989 12:11:40 To: security@pyrite.rutgers.edu Cc: nichols@cbnewsc.att.com
> 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 The strange organic dyes used in many dye lasers ARE VERY TOXIC!! I wouldn't recommend sprinkling them around, you could kill someone. Alan
-----------[000018][next][prev][last][first]---------------------------------------------------- From: meister@gaak.lcs.mit.edu (phil servita) 13-APR-1989 13:35:29 To: deh@eng.umd.edu Cc: nichols@cbnewsc.att.com, security@pyrite.rutgers.edu
it gets even better than that. If dealing with a location that is accessed
VERY infrequently, (such as some of the vaults at MITRE), do the following:
coat each button of a, say, 12 button pad with a different organic dye, each
flourescent at a different wavelength spread equally along the visible
spectrum. Now, assume the combo has a large (say 8) digits in it. The person
types in the combo. Some time later, you come back with a wide-range UV source,
and a decent spectroscope. (like the ones that you saw in jr high physics, only
with a GOOD grating.) Look at each button. One of them will give you EIGHT spec
lines. one of them will give you SEVEN. Etc. Inverting gives you the
combination.
If two buttons have the same number of lines, it could only happ by having
one of them be used more than once in the combo. Using the relative strengths
of the spec lines will give you hints as to which one it was. Sometimes it
requires a second application designed to figure out a specific question,
(eg "is '4' before or after '8'). Have fun. The dyes used for dye lasers
are not that expensive, given the minimal amounts you need to use here.
The main problem is that most of them are not transparent to visible light.
Have fun.
-meister
-----------[000019][next][prev][last][first]---------------------------------------------------- From: kus3@tank.uchicago.edu (Bob Kusumoto) 13-APR-1989 15:00:54 To: misc-security@husc6.harvard.edu
CN/A: My personal experience with it here in Chicago is that they will not give
you unlisted numbers (the procedure to get to an unlisted number is set so
that only certain high level DA operators will get to look at it, it sorta goes
like a) there must be an emergency to the family in question you wish to call,
b) the high-level /A operator will take down your name and message, c) the
person will look up the unlisted number and log the listing in some book,
d) call the number herself and relay the message). CN/A works slightly
differently elsewhere, like giving some ID number before you can start rattling
off numbers to look up, whether they will give you unlisted numbers or not,
the number of phone numbers you can get in one call to CN/A, any cost for the
call (I believe they charge it at normal DA rates for CN/A calls), etc.
Basicly, its become a pain nowadays.
lineman's book: I used to have a real worn version of this where it had the
name of the major town with a street map, and a listing of the name the
phone was registered to, the phone number which was referenced by the
street address. The name I heard this book called by Illinois Bell Telephone
when this book came out was the "Blue Book" (for the blue cover) and it only
covered a certain portion of the area code (this one covered all the North and
Northwest suburbs in the 312 calling area, although the first group of towns
from A to Evanston was torn out). Pretty interesting nonetheless.
Bob
--
Bob Kusumoto | Follow me,
Internet: kus3@tank.uchicago.edu | I'll play the game you want,
BITNET: kus3@tank.uchicago.bitnet | until I find a way back home.
UUCP: {gargoyle,oddjob}!tank!kus3 | - Genesis, "One for the Vine"
-----------[000020][next][prev][last][first]---------------------------------------------------- From: Ken De Cruyenaere <KDC@ccm.umanitoba.ca> 204_474_8340 13-APR-1989 21:22:28 To: SECURITY@pyrite.rutgers.edu
Our site has an aging card access system (made by now-defunct CMC). The system controls 16 doors and uses WIEGAND cards. We are in the process of replacing the system. There are some arguments, locally, for switching to MAG STRIPE cards (and readers). I would like to know what experience's there are out there with card access systems using WIEGAND and MAG STRIPE card technologies. Comments, criticism, etc. would be very useful at this point. Please respond to me and I will summarize and post results to the list. Thank you. ---------------------------------------------------------------------- Ken De Cruyenaere 'USER' - The word that Computer Security Coordinator computer professionals use Computer Services when they mean idiot. University of Manitoba Bitnet: KDC@CCM.UManitoba.CA -or- KDC@UOFMCC.BITNET
-----------[000021][next][prev][last][first]---------------------------------------------------- From: iconsys!ron@uunet.uu.net (Ron Holt) 14-APR-1989 1:07:46 To: misc-security@uunet.uu.net
I need to get a copy of the "Orange Book". Could someone send me ordering information? Thanks, -- Ron Holt UUCP: uunet!iconsys!ron Software Development Manager ARPANET: iconsys!ron@uunet.uu.net Icon International, Inc. PHONE: (801) 225-6888 Orem, Utah 84057 FAX: (801) 226-0651
-----------[000022][next][prev][last][first]---------------------------------------------------- From: <TOM@FANDM.BITNET> (Tom, Tech. Support) 14-APR-1989 1:25:12 To: security@pyrite.rutgers.edu
Just to clarify the telephone company cross reference thing:
There are, in our area at least, commercially available cross
reference publications. They cross from phone number to address and from
address to phone number (I believe both crosses include the name, but I
don't remember for sure).
These are routinely used by credit companies and banks for
collection activity, lawyers for several purposes, and as a police officer
I used them for several years.
Strangely, if you ask the telephone company about them, they will
tell you that such a publication could not possibly exist. Those of us who
understand data bases probably know better.
* 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 *
*********************************
-----------[000023][next][prev][last][first]---------------------------------------------------- From: spot!petersed@boulder.colorado.edu (Dan Petersen) 14-APR-1989 2:01:38 To: misc-security@handies.ucar.edu
I am currently working for a small business that is trying to beef up their security. I had heard that Medco keys cannot be copied by your local locksmith. Is this true? If not, are there any high security locks that have keys which are difficult to copy? Thanks Dan [Moderator tack-on: That's "Medeco", btw; I believe that the company will sometimes contract with a locksmith in a given area such that that locksmith is the only user of a certain blank. I.e. they manufacture a bunch of custom blanks for just that locksmith, so he's the only one who can [in theory] duplicate the keys he has made. There are also some "standard" Medeco blanks, available more universally. So the answer to your question is "sometimes". Wadlow, you know any more about this? Naturally, some enterprising metalwork can usually get around this... _H*]
-----------[000024][next][prev][last][first]---------------------------------------------------- From: zeleznik@cs.utah.edu (Mike Zeleznik) 14-APR-1989 2:36:01 To: security@rutgers.edu
>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? ...
When I last looked at the Security Dynamics one (SecurID), the time per
new value was variable. If you want fast changing values, you will need
a new card more often (e.g., when I looked at them, they used 6 digit
(decimal) numbers, so if the value changed every 30 seconds, your card
would use up all values in a year).
The SecurID relied on keeping the times in sync, but allowed for a
window of error (e.g., will accept either the current value, or the N
previous or N next values, where N is small). They seemed to feel it
worked fine, as long as your system keeps reasonable time. Now, if you
are running Apollos, that could be a real problem ;-).
One issue with these is if you are logging in/out of many different
network machines in a short period (say, from one session on one
machine). If you have to wait for the next number each time, it
could be a pain; BUT, if it allows you to use the same number, then,
during a small window, it is vulnerable to replay by others.
Also, you have to get new cards periodically, so you are kind of married
to the company...
Michael Zeleznik Computer Science Dept.
University of Utah
zeleznik@cs.utah.edu Salt Lake City, UT 84112
(801) 581-5617
-----------[000025][next][prev][last][first]---------------------------------------------------- From: mtdca!royc@att.att.com 14-APR-1989 6:13:40 To: security@pyrite.rutgers.edu
> 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? Worse yet: documents do not have to be delivered to YOU, merely to your FAX machine, to bind you to them. A severe weakening of the protection principle. roy a. crabtree att!mtdca!royc 201-957-6033
-----------[000026][next][prev][last][first]---------------------------------------------------- From: Ralph Hyre <ralphw@cs.cmu.edu> 14-APR-1989 6:22:44 To: security@pyrite.rutgers.edu
Perhaps your friendly neighborhood locksmith (who is bonded) could provide this service for you. My only worries about the local PBS station are: They may hold your key until you pay your pledge:-) There is less risk to them if they blow it. (Your locksmith would be very careful about security, since he needs a license from the state.)
-----------[000027][next][prev][last][first]---------------------------------------------------- From: zeleznik@cs.utah.edu (Mike Zeleznik) 15-APR-1989 20:21:46 To: security@rutgers.edu
I am interested in risk analysis/management software (i.e., tools to aid
in the tasks of assessing assets, threats, exposures, risks, and
safeguards). I am aware of several commercial packages, but have no
experience with any. Am sending for product lit now.
Does anyone have experience with this sort of software, or, can anyone
recommend a way of seeing this stuff in action, without having to buy
it (e.g., maybe you know a vendor that offers a demo package)?
Thanks in advance.
Michael Zeleznik Computer Science Dept.
University of Utah
zeleznik@cs.utah.edu Salt Lake City, UT 84112
(801) 581-5617
-----------[000028][next][prev][last][first]---------------------------------------------------- From: m_net!glr@cardiology.ummc.umich.edu (Glen L. Roberts) 15-APR-1989 21:29:23 To: misc-security@uunet.uu.net
Well, it is even easier than that. In most places, you can call the library and have them look up in the info in the "City Directory." What do you think the nice man from RL Polk co wanted all that information for? Also, you can sign up for the Atlas and Trace service with your local credit burau and do look-ups based on phone number, SSN, and address. They index into a compilation of junk mail lists (and probably credit applications). This service is only about $100/yr plus a dollar or so per look up. Since they are not releasing ``credit'' information the Fair Credit Reporting Act doesn't apply, so anyone who pays the fee has access.
-----------[000029][next][prev][last][first]---------------------------------------------------- From: Dean Roy <IDR@WINDSOR1> 15-APR-1989 22:23:25 To: SECURITY@pyrite.rutgers.edu
Hi there!
Here at the University of Windsor we are currently involved in
implementing a new security system on our administrative MVS system. We
have chosen CA-TOP SECRET as our new security system. As our first step
towards implementation we are writing a new security policy.
I would be very interested in hearing from anyone who has any ideas
of what should go into our security policy. As well I would be grateful if
anyone who has a security policy they have developed would send me a copy
of it.
Thanks in advance,
Dean Roy
Systems Programmer
University of Windsor
Windsor, Ontario, Canada
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 14 Apr 89 21:43:33 GMT From: rjg@sialis.mn.org (Robert J. Granvin) To: misc.security Subject: Re: MEDCO locks
Medeco has a range of varying security key blanks. All differing in
their difficulty to copy.
They replaced a key system about two years ago. Those keys can be
duplicated through contracted locksmiths. It is assumed that they
will follow the Medeco guidelines for duplication (which is require ID
against a "Valids" list, make the copies, then have you return to pick
them up).
The keys they replaced this system with are only available through
Medeco directly.
To duplicate the key, you must go to a contracted locksmith who has
your account on file. You must request a key by _number_, and sign a
form. You must be on a list of authorized parties... Once verified
by the locksmith as to your identity, the request is delivered to
Medeco who also does their own verification against an authorization
file, and then make the copies. The copies are shipped to the
locksmith, where you can pick them up, showing proper ID.
This is the plan, at least... :-)
But, keep in mind that a lock is only as good as the door and frame
around it. if your hinges are exposed to the outside, pin the
hinges. Also pay attention to the strike plate area. A steel door
and steel frame can be pried far enough apart with a crowbar to let
you get in. The lock does nothing for you here. Cover the strike
plate zone with a door-strike guard, at least. Next, can the entire
lock mechanism be cut out? I've seen gadgets that attach to the door
handle, and a little battery operated cutting blade will cut the whole
lock mechanism out of the door. Works on wood and steel.
You'll never beat them, but you can discourage them...
--
Robert J. Granvin
National Computer Systems "Looks like the poor devil died in his sleep."
rjg@sialis.mn.org "What a terrible way to die."
{amdahl,hpda}!bungia!sialis!rjg
14-Apr-89 22:37:35-GMT,942;000000000401
Date: 14 Apr 89 21:47:26 GMT
>From: rjg@sialis.mn.org (Robert J. Granvin)
Subject: Re: Need info on Orange Book
To: misc-security@uunet.uu.net
In article <8904140138.AA17801@ucbarpa.Berkeley.EDU> ron@iconsys.UUCP (Ron Holt) writes:
>I need to get a copy of the "Orange Book". Could someone send me ordering
>information?\
Contact the National Computer Security Center. Ask for the
publications office. The number can be obtained by calling your local
number for the Government Information Center (You can tell I don't
have it handy :-). The Orange Book is one book out of several known
as "The Rainbow Set".
They can also be ordered through the Government Printing Office, but
they don't know what "The Orange Book" means.
Robert J. Granvin
National Computer Systems "Looks like the poor devil died in his sleep."
rjg@sialis.mn.org "What a terrible way to die."
{amdahl,hpda}!bungia!sialis!rjg
-----------[000031][next][prev][last][first]---------------------------------------------------- From: hesh@lll_crg.llnl.gov (Chris Steinbroner) 16-APR-1989 19:28:19 To: misc-security@ames.arc.nasa.gov
> The goal is
> to make B1 level security with the product.
> NFS has been enhanced to be more secure
could somebody clarify please: does this mean that
NFS is going to be part of the evaluated configuration?
thanks,
-- hesh (a.k.a. Chris E. Steinbroner)
-- hesh@crg.llnl.gov
-- {ames,hoptoad,pyramid,sun}!lll-crg!hesh
-----------[000032][next][prev][last][first]---------------------------------------------------- From: barrys@apple.com (Barry Semo) 16-APR-1989 20:11:18 To: misc-security@ucbvax.berkeley.edu
> 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. Maybe I'm missing something, but how does this stop some thug from tossing a rock into the vehicle and stealing the radio or whatever else looks good? And how does it prevent a thief from cracking the ignition switch and hotwiring it? This sounds like a high-tech key that is expensive to duplicate and won't stop anyone. Barry
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 89 14:22:43 GMT From: shz@io.att.com (s.h.zirin) To: misc.security Subject: Re: MEDECO locks
>If not, are there any high security locks that have keys which are >difficult to copy? MEDECO Biaxial ABLOY DiskLock ASSA SECURITY 777 All of the above locks use restricted key blanks that are not available to hardware stores or to most locksmiths. The last three also require special machines which are only available to contractually obligated dealers at a cost of 2K to 3K. Seth Zirin, CPL att!packard!shz
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 89 20:05:00 GMT From: YZE6041@VX.ACSS.UMN.EDU (david paul hoyt) To: misc.security Subject: smart card timebases
>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? ... This isn't a problem really. There are phone numbers you can dial to get the correct time (international standards, inference clocks) accurate to some fraction of a millisecond. The macintosh pd program "setclock" uses this mechanism to get the 'correct' time. The card only needs to be able to resync before connecting to the remote system (assuming the remote uses an accurate clock as well). Alternatively, the card can sync with the remote as part of the handshake. After all trading times in clear text can hardly pose any kind of security breach. david | dhoyt@vx.acss.umn.edu | dhoyt@umnacvx.bitnet
-----------[000035][next][prev][last][first]----------------------------------------------------
Date: 17 Apr 89 21:21:06 GMT
From: fin@UF.MSC.UMN.EDU ("Craig Finseth")
To: misc.security
Subject: Password guessing technologyWe have added the following rules to our passwd program: All candidate passwords must pass these tests: - It must be at least 6 characters long. - It must contain at least 1 non-alphanumeric character. - If there is only 1 non-alphanumeric character, it must not be the last character. - It must contain at least 4 distinct characters. Six variations of the candidate password are also checked further. The variations are: - The candidate password, - All but the first character of the candidate password, - All but the last character of the candidate password, and - The reversed versions of the first three. The further checks are: - Against the system dictionary, - Against an auxilliary "hit list" file, which includes the Internet virus list, all examples, and other special cases. - Appearance in /etc/passwd or /etc/group (this check catches the user name, first name, last name, and group name), - Against the form: <user name><user name>, and - Against the form: <user name><any><user name>. All checks are made ignoring upper/lower case. Of the approximately 1.9 billion passwords that consist of 6 characters, 5 of which are lower-case alphabetic and digit characters and 1 of which is a special character, these restrictions eliminate (very roughly) 10 million. In addition, we have a shadow password file and other changes. Craig A. Finseth fin@msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375
-----------[000036][next][prev][last][first]---------------------------------------------------- From: hobbit@rutgers.edu (*Hobbit*) 19-APR-1989 16:49:47 To: hobbit
Here are the remaining in-depth technical messages about DES, which have
a more appropriate home here rather than the SECURITY list. Enjoy...
_H*
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: 22 Mar 89 15:17 EST
From: EVERHART%ARISIA.decnet@ge-crd.arpa
Subject: DES breakability...something concrete
To: Security <@relay.cs.net:Security@pyrite.rutgers.edu>
Here's a message that came in awhile back regarding the
breakability of DES. Perhaps someone really interested might
try to dig up the refs...
------------
Date: Fri, 30 Oct 87 19:32:32 MST
From: evi@boulder.Colorado.EDU (Evi Nemeth)
To: Eric.Cooper@SPICE.CS.CMU.EDU
Subject: Re: DES breakthroughs?
the break is in the diffie hellman key exchange for des based on 127 bits.
it was done quite a while ago, solving the discrete log problem for the
field 2 ** 127 -1. the work was with ron mullin at the university
of waterloo. the actual implementation of the algorithms was done
on the denelcor hep supercomputer (since defunct) in 1984. there
were several technical papers by mullin and by coppersmith at ibm
yorktown on the method of attack. our paper on the implementation
which includes a description of the algorithm but not the gory details,
was in the proceedings of the international conference on parallel
processing in the summer of 1984. i can send you a copy if you
dont have access to the proceedings. the paper actually won the
best paper award at that conference, no $$, but i got a plaque
for my wall and denelcor sold a machine to nsa.
the reason i mentioned it to van was that sun has now done two talks
at meetings about their security on the network that is based on
des using the diffie hellman key exchange in exactly the field
that we broke. both times the talk was given by the programmer
who is implementing it not the mathematician who decided what to
be implemented. i pointed them again to the papers on it; hope
a number theorist there actually reads them.
evi
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Thu, 23 Mar 89 11:21:21 EET
From: Frank Simon <151133@DOLUNI1>
Subject: Re: On DES' "breakability"
To: SECURITY@pyrite.rutgers.edu
'gwyn@BRL.MIL writes:'
>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.
At last SecuriCom in Paris was show a Algorithmen to break DES Text
in few seconds. I heared Shamir (the S of RSA) have programmed this
Algorithmen. Know some1 more aboout this ?
greets Terra
PS. horrible english ... i know ...
-----------------------------------------------------------------
! Name: Frank Simon Bitnet: 151133@DOLUNI1 !
! Nickname: Terra UUCP: Doluni1.bitnet!151133 !
! Position: Oldenburg,Westgermany Voice: 0441/592607 !
! WYGWYH - What you get , is what you hack !
-----------------------------------------------------------------
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Mon, 27 Mar 89 11:18:43 EST
From: hal@gateway.mitre.org (Hal Feinstein)
Subject: DES export
To: security@rutgers.edu
Can someone give me a good two paragraph explaination of how the
US export laws affect export of UNIX with DES? My understanding is
that it's been removed before export, even in binary form. Someone
rumored to me that the laws have recently changed. What kind of
privacy algorithm would be acceptable in its place? (I mean what
level of [un]-sophistication is exportable?) Does it affect the
password cipher and why?
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Thu, 30 Mar 89 09:48 EST
From: WHMurray@dockmaster.ncsc.mil
Subject: DES Disputes
To: security@rutgers.edu
Cc: WHMurray@dockmaster.ncsc.mil
>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.
(a) is most certainly not "undisputed." Indeed, it is quite widlely
disputed. It is disputed by those that were there. Walter Tuchman
disputes it. He disputed it under oath before the Senate
Intelligence Committee. While IBM's discussion of the S-boxes is
classified, IBM takes full responsibility for their selection.
It is less clear that they take full responsibility for the
selection of the key length. However, it is simply not material.
The DES can be, and is widely, implemented in such a way a as to
provide an arbitrary key length. Would God that it was as widely
used.
Given the history of cryptography [KAHN], it should not come as
much of a surprise, but it is nonetheless something of a national
disgrace that the DES is so badly tainted by its association with
the National Security Agency.
It should be noted that the DES has already lasted far beyond its
required design life. Testimony in regard to its recent extension
suggested that it is still good for that life again. It is time
that we stopped carping and began using.
>> 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, for one, am satisfied that it is. First, the reports that I
have seen on the progress in factoring do not suggest that we are
approaching the size numbers used in RSA. Second, the key length
in RSA is arbitrary. There seems to be no reason to believe that
the key length cannot stay ahead of the factorers. Third, the work
factor cost for numbers that we can factor is measured in tens of
thousands of dollars. We do not need crypto that will resist that
kind of attack. What we need is something that is one or two
orders of magnitude stronger than the white envelope.
Finally, one of the reports on "progress in factoring" was not that
at all; it was rather a report on the use of computers to cooperate
on a grand scale. While it may have reduced the elapsed time, it
added (overhead for the cooperation) to the total work factor.
_________________________________________________________________
William Hugh Murray 216-861-5000
Fellow, 203-966-4769
Information System Security 203-964-7348 (CELLULAR)
Ernst & Whinney ARPA: WHMurray @ 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
New Canaan, Connecticut 06840 TELEMAIL: WH.MURRAY/EWINET.USA
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Wed, 05 Apr 89 14:12:18 BST
From: Jim Gillogly <jim%blaise@rand.org>
Subject: Re: DES Breakability
To: Bruce Crabill <BRUCE@umdd.umd.edu>
Cc: security@pyrite.rutgers.edu, jim%blaise@rand.org
> 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.
I'd like to see your logic on this. I assume we're both talking about
encrypting with two different 56-bit keys for the double encryption. If
so, it seems to me that each bit of the output *does* depend on all 112 bits,
and without some known regularity in DES (your "or anything else" implies
that you aren't talking about cryptanalyzing DES) I don't see how this
collapses to 57 effective bits. (I assume your last sentence means that
it's 2 times as much work (since you're adding only one bit), not 2**n.)
Note that for DES in particular, there is no known way (outside NSA, of
course) to find a single key that would create in one encryption the effect
of two concatenated keys.
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Thu, 6 Apr 1989 09:04:10 EST
From: Jon Loux <JLOUX@UCONNVM.BITNET>
Subject: Re: DES Breakability
To: security@pyrite.rutgers.edu
I'm probably horrendously naive (nothing new there), but I was just wondering,
If you double encrypt something, using any encryption algorithm, wouldn't that
effectively double the encryption key? The key word here is effectively, since
you wouldn't have any way of knowing that you had successfully unencrypted the
text once until you successfully unencrypted that text into something
resembling intelligent text.
In other words, if I successfully unencrypt something, I won't know it until I
successfully unencrypt it again. This would provide an effective (if not
strictly speaking from a mathematical point of view) difficulty level of n**n
and not n**2. Comments?
Peel off your favorite disclaimer and attach here.
Jon Loux
The University of Connecticut
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Thu, 6 Apr 89 09:20 EST
From: <BRIAN@UC780.BITNET>
Subject: Bust DES in 30 minutes?
To: security@pyrite.rutgers.edu
>> ...but I have seen programs that will let you crack DES encryption
>> in about 30 minutes.
>This is a strong statement. If true, it has enormous ramifications
>for cryptography as many encryption systems are built around DES.
The following information appeared on the INFO-VAX@KL.SRI-COM SIG around
3 March of this year. Poster is one Tarjei Jensen
<jensen%hsr.uninett@norunix.bitnet>. My apologies if this has already been
around, but I've been out of the SECURITY loop for a while ...
>This is what I found on the spring 87 vax tape. I believe that it also appears
>on the recent Languages and Tools SIG tape.
>======================================================================
>
> Data Encryption Standard
>
> The NSA has announced that the Data Encryption Standard, or
>DES for short, would not be supported when it expired. Various banks
>have pushed for its retention on the grounds that it's secure enough
>for the time being.
> This is to advise all and sundry that in the 1979 to 1980 period
>there appeared an article in the Proceedings of the Soviet Academy of
>Science giving a simple way of pruning decision trees for DES ciphers
>which describes equivalence classes of keys and allows greatly reduced
>processing to break a DES cipher. The reduction in processing is such
>that breaking a DES cipher would amount to on order 1.5 hours on a
>standard IBM PC. There have been rumors that such a program is in
>circulation and that a copy of it at NSA led to its withdrawal of
>support for DES.
> Be advised that DES is EXTREMELY likely to be vulnerable and
>that other crypto methods are probably needed to secure data.
> The Soviet article goes on to give some conditions on the
>factors used for public key encryption which prevent or allow easy
>breaking of those ciphers, so it is probably required reading for anyone
>serious about protecting information.
I can't vouch for this information, but if it is substantiated, it has
RATHER CLEAR implications for DES security. (I've been meaning to track
down the reference for some time, but ...)
Brian McMahon <BRIAN@UC780.BITNET>
Administrative Computing
University of Maryland University College
(Default disclaimer)
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: 6 Apr 89 19:45:59 GMT
From: Maarten Litmaath <maart@cs.vu.nl>
Subject: Re: DES Breakability
To: misc-security@cwi.nl
\Double encryption using DES (or anything else for that matter) gives you
\an effective 57 bit key, not 112.
Aha! And how are you going to decide you finally found the first key?
(Actually it's the second!)
By seeing if the decrypted text makes any sense?
\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.
^^^^
n to the n-th!
n**2 AS MUCH work? No, Bruce, what you meant to say is: "2 times as much work,
not n times."
However, it IS n times.
--
"If it isn't aesthetically pleasing, |Maarten Litmaath @ VU Amsterdam:
it's probably wrong." (jim@bilpin). |maart@cs.vu.nl, mcvax!botter!maart
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: 7 Apr 89 14:33:51 GMT
From: mchamp@wpi.wpi.edu (Marc J. Champagne)
Subject: Re: Unix passwords
To: misc-security@husc6.harvard.edu
>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.
Not exactly......
This is what goes into the algorithm
1) KEY - the 8 char password you give ; of the 6 bits given, only
56 (7per char) are used
2) SALT - a 2 char sequence chosen from a..z, A..Z, 0..9, "." and
"/" to give the algorithm about 4096 permutations from
the unmodified DES algorithm
What is modified
-a 64 bit piece of constant text (never changed) is encrypted by
the modified DES routine using your key (password) and the salt
What comes out (in the /etc/passwd file)
1) the first 2 chars are the salt
2) the next 11 chars are the encrypted constant text ; only 66 bits
of the 88 bits are actually significant
How secure is it?
1) The salt routine is relatively unsophisticated. It gives some
measure of protection against a hypothetical machine hardwired to
decrypt the original DES algorithm. But it does not increase the
complexity of the DES algorithm itself in any way. You're only
getting 4096 permutations of the DES algorithm, and anyone can
see the SALT value that was paired with your password.
2) How secure is the DES algorithm itself. I refuse to answer that
question, since I would have to defend my answer against either a
very angry group of pro-DES people, or a very angry group of
anti-DES people. I've seen it happen too often on misc.security
and sci.crypt.
Note:
-DES can be used in several different "modes", many of which
involve making a given encryption of any 64 bits dependant upon a
previous series of encryptions.
-this is not the case with passwords encrypted with the SALTed DES
program... it is 1 straight run through the modified DES algorithm
Want to try an interesting experiment?
-the algorithm which takes the salt found in your /etc/passwd entry
and the password you type in at the login prompt, encrypts them,
and spits out the encrypted constant text for the login program to
compare against the full entry in the /etc/passwd file is publicly
executable (of course); it is often called "makekey", and its path
is usually /usr/lib/makekey
-input to this algorithm is from standard input, and output is from
standard output
look at your entry in the /etc/passwd file. let's say it is:
//--salt
mchamp:ImhkyZkGBZJQE:1056:1056.......
\\\\\\\\\\\--encrypted constant text
try piping your password and salt into the program by hand and
watch it spit out the entire entry /etc/passwd entry..ex
echo "passwordIm" | /usr/lib/makekey
for some key other than "password", this WILL REALLY spit out my
"encrypted password" (actually, the encrypted constant text)
ImhkyZkGBZJQE
Hints....
-I'm running on an Encore Mutimax, and the constant text has not
been changed
If anyone out there can tell me what my password was (I will change it
after posting this), then we'll exchange private mail using a more
secure crypto-system.
I'm eagerly looking forward to a successful reply.....
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: 9 Apr 89 01:36:32 GMT
From: rjg@sialis.mn.org (Robert J. Granvin)
Subject: Re: Unix passwords
To: misc-security@uunet.uu.net
On a related note (and possibly one of security interest) is a set of
books published by AT&T, called "Unix System: Reading and
Applications". Volume II (of apparently II) has a paper written by
J. A. Reeds and P.J. Weinberger (both of AT&T Bell Labs).
The paper, "File Security and the Unix System Crypt Command",
discusses the processes that crypt uses for encoding data. It then
proceeds to present the algebraic formulae and procedures to determine
the keyword used for encryption, thereby allow decryption. It's noted
that the procedure takes about two hours.
It follows by presenting a simple enhancement to crypt that will make
it much more secure, and then proves to you that even this improvement
in encryption technique (or more generally, any reversible encryption
technique) is never secure. It demonstrates this by presenting the
procedures to break the new encryption.
Since these are commercially available publications that I've seen on
many a B. Dalton shelf, it follows that anyone who wanted the
information to decrypt crypted files, technically has that information
at hand.
--
Robert J. Granvin
National Computer Systems "Looks like the poor devil died in his sleep."
rjg@sialis.mn.org "What a terrible way to die."
{amdahl,hpda}!bungia!sialis!rjg
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Tue, 11 Apr 89 16:35 EST
From: <IMHW400@INDYVAX.BITNET> (Mark H. Wood)
Subject: Re: on DES' "breakability"
To: security@pyrite.rutgers.edu
I will now prove that I don't know anything about cryptanalysis: has anybody
considered that DES with a 64-bit key might be *weaker* than DES with a
56-bit key? 64 has a property that 56 does not share: it is an integer
power of an integer. This additional property might introduce additional
properties into the ciphertext, which could be exploited by the cryptanalyst.
Maybe NSA did us a favor, instead of what is usually assumed....
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: 12 Apr 89 14:13:25 GMT
From: mark@jhereg.jhereg.mn.org (Mark H. Colburn)
Subject: Re: On DES' "breakability"
To: misc-security@uunet.uu.net
Cryptoanalysis is not a particularly exact science. Some would still call
it an art.
The amount of computing power required to mechanically dissect an unknown
code can be staggering. I am not sure if DES knows how to break DES or
not. I do know that DES requires that any codes that are shipped out of
the country are breakable, and that the "recipie" for decryption be given
to the NSA.
>I do admit they probably know more about cryptanalysis than the average guy,
>and they probably have other uses for their computers than brute-forcing DES
>texts. But in view of their involvement with the key size, there is a strong
>implication that key size is important. They probably use both their
> expertise as well as compute power to do their job, whatever that is.
Considering what they do, a reasonable assumption. They do more than JUST
break codes. They intercept messages from an amazaing array of sources,
both computer and radio, and probably other that we don't know about.
It is possible that DES is reversable through some arcane mathematical
manipulation, or that there is some way to break it down to something
easier to handle. I am sure that those parts of the VULCAN report would
have been classified if they did, indeed, exist. This is merely
speculation on my part.
--
Mark H. Colburn "Look into a child's eye;
Minnetech Consulting, Inc. there's no hate and there's no lie;
mark@jhereg.mn.org there's no black and there's no white."
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Wed, 12 Apr 89 20:14:17 EDT
From: gwyn@brl.arpa (Doug Gwyn)
Subject: Re: On DES' "breakability"
To: security@rutgers.edu
>And if they
>can break DES by cryptanalysis, why do they have God-knows-how-many gigaflops
>of compute power?
No congressional investigation was necessary to find that out; the design
of Lucifer was published publicly in an IBM research journal, NSA
participated in the design of DES (they suggested changes in the S-boxes
as well, for example), and the resulting DES design is also public knowledge.
Anybody could tell what changes were made from Lucifer to DES. Most of the
reasons for the changes have not been disclosed, but there is no particular
reason to think they were intended to weaken DES to the point that NSA
would be able to crack it. I would be quite surprised to find out that
NSA would have been incapable of routinely cracking even a 64-bit keyed DES.
It is quite possible that NSA was able to determine that a 56-bit key was
practically as secure (or as insecure) as a 64-bit one, given foreseeable
improvements in technology through the useful life of DES.
NSA has lots of computing power because it helps them accomplish their
mission. I suspect that very little of it is applied to cracking DES.
Note that NSA was the world's largest computer user well before DES or
even Lucifer had been invented.
Just because an agency is "spooky" doesn't mean you have to be paranoid
about them.
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: 13 Apr 89 19:10:26 GMT
From: Andrew Klossner <andrew@frip.wv.tek.com>
Subject: Re: On DES' "breakability"
To: misc-security@tektronix.tek.com
"Gwynn@brl.mil says that if NSA can break DES it's because they
know more about cryptanalysis. This seems to contradict the
fact (found by congressional investigation) that NSA did indeed
influence the decision to use 56 bits instead of 64 or more for
the key. If increasing the key size is not necessarily an
effective countermeasure, why did they do that?"
Perhaps to lead you to believe that they need brute force number
crunching in order to crack DES. The first thing you learn when
dealing with spooks is that their motives are never transparent.
Even if they needed brute force then, it doesn't follow that they need
brute force now, half a decade later.
-=- Andrew Klossner (uunet!tektronix!orca!frip!andrew) [UUCP]
(andrew%frip.wv.tek.com@relay.cs.net) [ARPA]
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Thu, 13 Apr 89 13:21:23 PDT
From: merkle.pa@xerox.com
Subject: The security of multiple encryption
To: hobbit@pyrite.rutgers.edu
The paper "On the Security of Multiple Encryption" by Merkle and Hellman
was published in the July, 1981 CACM (Vol. 24, No. 7) (pages 465-467).
The conclusion, in essence, was that triple encryption with two keys is
still vulnerable to attacks that are similar in flavor to the attacks on
double encryption with two keys. Double encryption with two keys does not
improve security as much as one might hope -- it seems to force the use of
more memory during cryptanalysis, but can still be broken in about 2**57
"operations".
To significantly increase the security of DES would seem to require triple
encryption with three separate keys. Of course, there is no guarantee that
triple encryption provides substantially more security -- but triple
encryption with two keys has known weaknesses.
Ralph C. Merkle
Xerox PARC
merkle@xerox.com
-----------[000037][next][prev][last][first]---------------------------------------------------- From: Steve Goldstein <goldstei@nsipo.nasa.gov> 19-APR-1989 21:00:23 To: TomZ@ddn1.dca.mil Cc: security-request@rutgers.edu, pjs@nasa.gov
I have a SedureID to use the MITRE LAN via the MICOM switch. You know
how many times I used it with telnet-ing or rlogin to the host from
elsewhere in the Internet as an option? Wanna guess? {A: close to zero,
once the curiosity wore off wrt the new toy in my briefcase.}
So, then they secure all outside net access and I have to use the SecureID
via telnet, rlogin, ftp, etc. Wanna know hos many times I use the MITRE
host now? (I do still maintain a .forward mail deflector on it, though).
Could you imagine a person with a bujch of accounts in different institutions
running around with a pocketful of SecureID cards, trying to remember which
is which and what his/her Personal ID Number is (one needs to key in PIN
before keying in the seed that shows up on the card)?
I work on security for the NASA Science Internet. Security is a BIG concern
of mine. I do not take it lightly. I am more motivated than the average
Joe to do the right thing. BUT, things like the SecureID are a fantastic
pain in the gluteus maximus, and I use a host so guarded only as a last
resort. I see the need, but I shudder to think what a pain it would be
if all my host machines were so guarded.
Steve Goldstein
Program Coordinator
NASA Science Internet
-----------[000038][next][prev][last][first]---------------------------------------------------- From: jwright@atanasoff.cs.iastate.edu (Jim Wright) 19-APR-1989 22:06:35 To: misc-security@ames.arc.nasa.gov
Today, Monday 10 Apr 1989, marks the mid-point in the voting for the new newsgroup comp.virus. This is a reminder, and will hopefully clarify a few points. To vote, send mail to me marked either "YES" for creation or "NO" against creation. If you want to check if your vote reached me, wait until the voting has finished, at which time I will post a list of all votes received. The group will be moderated. The moderator will be Ken van Wyk, who is currently the moderator of the virus-l mailing list. Also, Dave Ferbrache will be the European coordinator of the group. This will not be a "private" group. You may subscribe and read it as easily as you do any other group. You can submit material as easily as you can for any other moderated group (e.g. comp.risks, comp.unix, misc.security, etc.). If your site has up-to-date news software, submitting material to moderated groups should appear identical to submitting material to non-moderated groups. This will not be a micro-only group. There currently is a discussion in virus-l of "exec"-type viruses in IBM mainframe computers. This is only an example; other systems are equally welcome. In conjunction with comp.virus, we have been trying to establish a number of anti-viral archive sites. These sites will maintain any combination of archives of the virus-l/comp.virus group, papers dealing with computer security, anti-viral software for specific computers, etc. We currently have sites in the US and Europe. -- Jim Wright jwright@atanasoff.cs.iastate.edu
-----------[000039][next][prev][last][first]---------------------------------------------------- From: TomZ@ddn1.dca.mil 19-APR-1989 23:34:49 To: goldstei@nsipo.nasa.gov Cc: TomZ@ddn1.dca.mil, security-request@rutgers.edu, pjs@nasa.gov
Comment: I probably should have put in the standard disclaimers -- (1) I agree that carrying multiple SmartCards would be a =<MAJOR>= pain, but for small numbers of centrally managed accounts (a SecureID card can keep up to four (4) different ID's with the same PIN right now), a SmartCard is much more user friendly than most of the authentication devices I've seen. =<Note that I said DEVICES, not techniques!>= (2) You have a badge for most of those sites, I'll bet. What's wrong with the badge-replacement style of SmartCard? The ones I've been shown are not noticeably heavier than my MITRE badge -- lighter than the [insert expletive here] badge I have to use at DCA-HQS. And yes, they can be magstriped. (3) Now for my knock against ALL the SmartCard vendors: There needs to be one central authority to handle the problem of merging multiple cards into one. It is silly to have to carry more than one of these critters! Standard Disclaimer: I am not a shill for Security Dynamics. I do not own stock, get any commission, or otherwise receive remuneration from them or any of their ilk. On a personal level, it wouldn't matter to me if they fell into a hole tomorrow. * H * O * W * E * V * E * R * I =<DO>= think an unforgeable identity token is the only way to secure a dial-in. A SmartCard may not be truely unforgeable -- there is nothing man or woman can fabricate that another cannot duplicate -- but it does qualify as an inexpensive alternative. /s/: Tom Zmudzinski Defense Communications Agency (703) 285-5333
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 19 Apr 89 14:23:59 GMT From: abrams%smiley@GATEWAY.MITRE.ORG (Marshall D. Abrams) To: misc.security Subject: Access control research
We have also been working on access control models and are interested in sharing information with you. Our work is a "white paper" on access control concepts for the National Computer Security Center. What is the purpose, focus, and audience for your work? Here is the to-date bibliography for our access control paper. The numbers are out of order (we've just been adding as we go along and will redo at the end.) This is a derect extract from our source file, including troff marco commands. [Moderator insertion: Said bibliography approaches 10K and is probably of interest to only a few readers. Please contact Marshall directly if you want a copy... _H*] Sincerely, - - Marshall D. Abrams, phone: (703) 883-6938 The MITRE Corporation, 7525 Colshire Drive Mail Stop Z506, Mc Lean, VA 22102
-----------[000041][next][prev][last][first]---------------------------------------------------- From: Robert Nelson Gasch <rg2c+@andrew.cmu.edu> 21-APR-1989 6:35:33 To: security@pyrite.rutgers.edu
>Now the method of attack has shifted to modern high-performance password >guessing programs. Could anybody please describe the differences between those two approaches in some detail. I'm not sure what sort of an algorithm either has. Thanx alot ---> Rob [To him, please. It's been gone over before on the list... _H*]
-----------[000042][next][prev][last][first]---------------------------------------------------- From: William James <JAMES@DUVM.bitnet> 21-APR-1989 7:19:55 To: SECURITY@UBVM
Hi! I am cross posting this note in order to reach a wider audience to obtain information on the possibility of installing the ancient application GPSS (General Purpose Simulation System) on a VM/HPO 4.2 - 3090 150E system. If anyone has knowledge of this package (GPSS) running under VM please get in touch with me William James at DUVM (james@duvm) or give me a call at (215)895-1433. Thank You.
-----------[000043][next][prev][last][first]---------------------------------------------------- From: *Hobbit* <hobbit@pyrite.rutgers.edu> 21-APR-1989 7:56:52 To: security
Those of you who sent your votes to security, or misc.security, aren't getting anywhere. Try re-reading the "call for votes" message. _H*
-----------[000044][next][prev][last][first]---------------------------------------------------- From: "W. K. (Bill) Gorman" <34AEJ7D@CMUVM.BITNET> 21-APR-1989 8:40:20 To: Security Digest <security@pyrite.rutgers.edu>
>The strange organic dyes used in many dye lasers ARE VERY TOXIC!! I >wouldn't recommend sprinkling them around, you could kill someone. Very dramatic! However, the same effect can be obtained by using the UV fluorescent liquids/powders available through suppliers of stuff used for kiddies science fair projects.
-----------[000045][next][prev][last][first]---------------------------------------------------- From: deh@eng.umd.edu 21-APR-1989 9:00:43 To: jimkirk@outlaw.uwyo.edu Cc: security@pyrite.rutgers.edu
The only problem with this line of reasoning is that anyone at NSA could have predicted that this line of thinking would be followed, and that the natural conclusion is that "since they shortened the keys, and use all that compute power, they must not know a back-door" Paranoia! In any case, they do things at NSA that use more compute than anyone knows...... Crays and such are, from what I am told, th least of the power these days. My employer has sold a lot of systems to them, or should I say to "Maryland Procurement", but not for the crunch factor. 'nuff said. By the way, on a different wavelength, the Secret Service here in DC has gone to scrambled communications. This has screwed up a bunch of my friends in the media, since this was one of the ways that they tended to keep track of what was happening. Not that anyone would try to actually use the information, but can anyone discuss the state- of-the-art on this stuff? Thanks, Doug [yow! this DOES seem like a pretty underground message for an above ground guy like myself. Don't take this wrong! Inquiring Minds want to KNOW ]
-----------[000046][next][prev][last][first]---------------------------------------------------- From: hal@gateway.mitre.org (Hal Feinstein) 21-APR-1989 21:17:38 To: -v@gateway.mitre.org, security@pyrite.rutgers.edu
I'm trying to find out what's going on with US DES export laws:
(1) Folks at MIT are trying to get DES exported for their a
authentication server (project Athena).
(2) Products built on flavors of UNIX (Xenix, Sys V, BSD...)
You get UNIX and the product as a binary. Is this exportable?
(3) Rumor is UNIX had to have DES software (two different modules
one waz password crypt.) removed before it could be exported.
Did they get a ruling or were the corporate lawyers working
overtime that night?
(4) I understand the law applies to *all* cryptography and not
any specific algorithm,device, rotor machine or what have you.
How un-sophisticated must the algorithm, device, rotor machine
or what have you be before you've got a better than 50% chance
of getting approval?
(5) Suppose you take DES binary out and some smart European puts it
back in, over there?
(6) About two years back I saw a algorithm built of DES like boxes
from an author at a Polish university. Think its secure..eh?
(It was published in a British journal)
Any information would be greatly appreciated.
-----------[000047][next][prev][last][first]---------------------------------------------------- From: Robert Cole <rhc@hplb.hpl.hp.com> 21-APR-1989 22:25:30 To: tcp-ip@sri-nic.arpa, security@pyrite.rutgers.edu
A new draft ECMA standard for Security in Open and Distributed systems is available for FTP. This draft standard addresses the problems of security standardisation in applications intended for OSI or ODP environments. Comments are requested on this draft for inclusion in the final version. Please forward this message to any other groups or individuals who may be interested in this work. The text may be obtained by anonymous FTP from rcole.hpl.hp.com (15.255.61.89) which is in the UK, or from allspice.lcs.mit.edu in the directory ~/pub/ecma-desd, as a tar file containing print files for the individual chapters. Two print file formats are offered: desdps - contains the PostScript version desdlj - contains print files for the HP-Laserjet+ (or better). Compressed versions are also available to ease the transfer problem. So the file choices (and sizes) are: 5253120 Apr 5 13:50 desdlj.tar 1816056 Apr 5 15:34 desdlj.tar.Z 1505280 Apr 5 11:00 desdps.tar 569425 Apr 5 11:12 desdps.tar.Z Note that the document contains pictures as well as text so it is not possible to send the text directly by e-mail. Please note that the document was designed for, and will evenatually be published on, A4 paper. If you must print it on AQ size then you may lose the page numbers. Robert
-----------[000048][next][prev][last][first]---------------------------------------------------- From: ok@quintus.com (Richard A. O'Keefe) 21-APR-1989 23:12:04 To: ???
A University has loaned me a PC for a couple of months. After some initial confusion about what I would do for them in return, this is what they decided they wanted most. There is a central site with a bunch of machines: VAX/VMS, IBM 4341/VM/CMS, all LANned together and exchanging mail using CMDF (a C version of PMDF). There is a marine research station miles and miles away with several PCs, none of them particularly big, not (if I've understood correctly) LANned together, and not currently using E-mail. They do have a line to the main site. What they want is a scheme (which must use the phonenet protocol) whereby the marine biologists at the remote site can receive and send mail through the main site. The irony of this is that I know only as much about mailers as I couldn't avoid knowing. It did strike me that these people, who never have to "log in" to use their PCs, probably aren't going to like having to give passwords and the like just to use E-mail, which they've not had before so aren't missing. It also struck me that in the absence of shared file-servers, the mail will only be as secure as the floppy discs it is physically stored on. The scheme I came up with for authentication is this: each person at the remote site who is authorised to use the E-mail system would be given a floppy disc containing a version of the mail transfer program customised for him. This would contain all the necessary information to identify that user to the mail system. The user would be able to make copies of the disc. Retaining control over who can read your mail and who can send mail as you would then reduce to retaining physical control over the copies of the disc. The degree of security required here isn't very great. What's worrying me is the thought that I might be missing some obvious Risk. (Either the phonenet protocol is flawed, or I have misunderstood it: there doesn't seem to be any way of preventing someone using this method to find out which other people at his site have mail waiting at the main site and who that mail is from, but that's true no matter what the authentication method is.) If this isn't the right newsgroup, I apologise for wasting your time. comp.risks didn't seem quite right.
-----------[000049][next][prev][last][first]---------------------------------------------------- From: <PERAINO@GMUVAX.BITNET> 22-APR-1989 5:05:09 To: security@pyrite.rutgers.edu
We are also a fairly new MVS site running RACF. I would also appreciate
any security policy documents anyone may have for MVS. Thank you.
Bob Peraino, George Mason University
peraino@gmuvax.gmu.edu
peraino@gmuvax
-----------[000050][next][prev][last][first]---------------------------------------------------- From: Christopher Chung <CHRIS@BROWNVM.BITNET> 22-APR-1989 6:05:10 To: SECURITY@pyrite.rutgers.edu Cc: Christopher Chung <CHRIS@brownvm.bitnet>
How do you deal with passwords in terms of how to make sure that 1) everyone who needs to know them is informed when one changes. 2) if everyone happens to be away and a server or account needs to be accessed, how does a non-administrator get the password in an emergency? Are the passwords written down someplace that can be accessed by someone who has the need to in an emergency. If so how do you prevent someone from stealing a look at this "book" ie the janitors who have keys to everything? I am dealing with these issues and was wondering what people would recommend. Thanks, Chris CHRIS%BROWNVM.BITNET@MITVMA.MIT.EDU
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 21 Apr 89 21:05:15 GMT From: deh@eng.umd.edu To: misc.security Subject: Re: Dusting Simplex locks
I agree that you should use whatever you can get your hands on for illumination of code buttons; I mentioned laser dyes because I happened to have a lot of them around at the time that I first tried this, and it worked very well. Most of the dyes that I have used are pretty common, pretty cheap, and to the best of my knowledge none of the ones that I have used have been toxic.... One consideration in choosing the dye to use (for buttons, not for lasers) is what it looks like in regular light, since you don't want people seeing it on the buttons. ANother consideration is the method of application. One reason the laser dyes worked so well was the fact that they were disolved in solvents, usualy alcohol but also ether some times. In a spritzer bottle, these can be sprayed on the target area where they will dry quickly, leaving a very fine and uniform distribution of the dye material which is very likely to escape detection. DO make sure that the solvent doesn't melt the materials that the buttons, etc. are made of though..... Doug
-----------[000052][next][prev][last][first]---------------------------------------------------- From: deh@eng.umd.edu 23-APR-1989 16:05:13 To: KDC@ccm.umanitoba.ca Cc: security@pyrite.rutgers.edu
WIEGAND is by far the best card technology that is available today (I exclude smart cards, since they are a new technology and have their own special problems). Mag cards will get erased by things, and will wear physically, and will go bad, and will be an administrative nightmare about a year (maybe a lot less) after they are installed. WIEGAND cards work by having a thin bi-metal wire embedded in the card. The wire is subjected to heating, magnetic fields, and mechanical twisting at the factory in order to encode the proper data into it. It is NOT a magnetic system, and is not subject to being screwed up by magnetic fields that you are likely to encounter in reality (I ruined a WIEGAND card on a Cyclotron Analyser magnet once, but that was an exceptional case, since it was bending a 200 Mev beam at the time, and thus was generating a BIT of a field). The wire is swept through a magnetic field set up by the reader, and the field itself is monitored. As the various parts of the wire pass through the field, they will cause fluctuations in it which are read and used as data. Very slick. These readers are epoxy encapsulated, so they never fail because of stuff getting into them and need no maintenance, something that can not be said for mag cards. Wiegand readers work underwater for example, which may sound useless, but there is a US Navy location that has them installed on under water weapons storage (mines or something I would guess....) vaults in Maryland. It means that if your card gets soaked in the rain, the card and the reader don't care. It really is a great technology. I have seen cards for Kastle Systems (here in the DC area, they do access control for more than 350 buildings) that people have been sitting on (in their back pockets I assume) for years and have shattered them, barely held together by scotch tape, and they still work fine. Try that with any other technology. The RF based cards, refered to as Sludge Cards since the company that makes them is Sladge (spelling?) are not really all that winning, though they do have their good points. They can be read through your clothes, so you can leave your wallet in your pocket and just get your rump up against the reader (if they are nice enough to put it that low!) and zap! you are in, unless you have something else metal in your wallet that can screw up the RF reading of the card. The cards are somewhat sensitive to physical damage, not that they are delicate per se, but if they DO get hurt they stop working at once since it changes the RF emmission characteristics of the card. The other drawback is security; there exists in the DC area somewhere (I don't know who ended up with it) and 'Boom Box' (radio, cassette, etc) that only plays cassettes, since its innards have been replaced with a modified version of the Sludge Card reader. You sit down next to the reader (as close as you can get the box to it, in any case) and when the person with the card get near, it will read the card while it is still in their purse, wallet, etc. Walking through a downtown (K street) McDonalds with this device several years ago (when we built it) yielded a slew of card data. If you are near their entrance and watch them walk in, and get their card data as they pass by, I assume that it would not be too hard to build cards to match the data that you recorded, and then waltz (or bop, or shuffle) right on in..... I consider this a security risk. Doug
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 23 Apr 89 00:22:45 GMT From: ns@maccs.mcmaster.ca (Nicholas Solntseff) To: misc.security Subject: Re: DES export laws
I have been told by someone in Export Controls in the Pentagon that letting a non-Canadian student (e.g., from the PRC or Poland) use a DES program is legally the same as exporting! Thus, a copy of Dbase III labelled "Not for export" cannot be used in an open lab here. Nick .....
-----------[000054][next][prev][last][first]---------------------------------------------------- From: Stephen.Wadlow@cad.cs.cmu.edu 25-APR-1989 19:19:48 To: security@rutgers.edu
The way I have understood medeco to work, is that they will license a locksmith for the use of one specific and unique blank. Medeco will only sell this unique blank to that locksmith, thereby, the only people who will be able to "officially" copy a medeco key would be the locksmith, and medeco. This is all in keeping with the "high security" aspect of medeco locks. Since they restrict the blanks on a per locksmith basis, only the locksmith who installed your cylinder will be able to duplicate the key, and thereby, he should know who has keys, and can only make keys for only people with legitimate needs. To the best of my knowledge, there are two universal medeco blanks. They are available to any schmuck who can figure out how to get them. I'm not certain, but I believe one of the two is for a 5 pin cylinder and the other is an identical blank only made for 6 pin. There is a third party vender that is making clones of these keys (It may be Ilco, but I'm not positive) which seem to work well, and are cheaper than buying them from medeco. > Naturally, some enterprising metalwork can usually get around this... The beauty of medecos is that they have a very large keyway, and it usually isn't terribly difficult to do some creative milling on other blanks to get one that will fit. I know of people that have made duplicates of medeco keys using brickstrap, but the resultant keys aren't always reliable as the surface area of the key on which the beveled cut is made to rotate the pin isn't very large, and the pins may not always rotate properly. In terms of other locks which are difficult to get copied, I'd probably recommend abloy. Not only are they difficult to pick, but you have an example of security through obscurity. There aren't many people who have the facilities to copy abloy keys. I don't know if they have a similar licensing procedure in terms of blanks. From what I have seen, I tend to believe that they don't. I have never seen any third party abloy clone keys, thereby making abloy your only source for key blanks. Has anyone ever had any experience in picking abloys? I've heard of it being done, but not by using standard methods. steve ====================================================================== Stephen G. Wadlow Internet: sgw@cad.cs.cmu.edu Dept of Architecture, CMU stephen.wadlow@andrew.cmu.edu "Hey Man, A ship in harbor is safe, but that ain't what ships are for"
-----------[000055][next][prev][last][first]----------------------------------------------------
Date: 24 Apr 89 14:14:19 GMT
From: mchinni@PICA.ARMY.MIL ("Michael J. Chinni, SMCAR-CCS-E")
To: misc.security
Subject: Re: password security
What we do:
Our site is a government installation (DoD - Army). (1) dealt with verbally
(i.e. those that need to know are told verbally). (2) the non-administrator
doesn't get the password. The passwords are NEVER to be written down, under
any circumstances.
Recommendations:
What we might do if we did write down the password in a "book" would be to
keep this "book" in a combination-type safe. Only those people who were
authorized, in advance, as primary or alternate admins. (or bosses) would have
the combo. to that safe (that includes lock&key control as not have-ers).
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Michael J. Chinni
Chief Scientist, Simulation Techniques and Workplace Automation Team
US Army Armament Research, Development, and Engineering Center
User to skeleton sitting at cobweb () Picatinny Arsenal, New Jersey
and dust covered terminal and desk () ARPA: mchinni@pica.army.mil
"System been down long?" () UUCP: ...!uunet!pica.army.mil!mchinni
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
-----------[000056][next][prev][last][first]---------------------------------------------------- From: shz@io.att.com (s.h.zirin) 26-APR-1989 2:18:44 To: misc-security@att.att.com
>If not, are there any high security locks that have keys which are >difficult to copy? MEDECO Biaxial ABLOY DiskLock ASSA SECURITY 777 All of the above locks use restricted key blanks that are not available to hardware stores or to most locksmiths. The last three also require special machines which are only available to contractually obligated dealers at a cost of 2K to 3K. Seth Zirin, CPL att!packard!shz
-----------[000057][next][prev][last][first]---------------------------------------------------- From: GREENY <MISS026@ECNCDC.BITNET> 26-APR-1989 2:54:26 To: <security@pyrite.rutgers.edu>
I had heard that Medco keys cannot be copied by your local locksmith... Yeah, this is usually true, depending upon who your local locksmith is. Most smaller locksmiths just dont have the money to purchase the special machine which cuts Medeco keys. Each key cut is cut at a specific angle and the machine is *VERY* accurate. Consequently, many locksmiths will send your request for a key either to the factory, or to a larger outfit which does have a Medeco key cutting machine. Each Medeco key/cylinder comes with a "credit card" that has a specific factory-assigned number on it. When you ask for a duplicate key, the locksmith takes the card, runs it thru a credit card like machine onto a special form from Medeco, and sends the form, and whatever he/she/it charges ya for the key (the place I work for charges $5.00/key + certified mailing costs). Also the locks are pretty hard to pick, but not impossible. One thing to consider tho, is that the security provided by the lock is only as great as the surrounding door frame/door. I.e.: If the door/door frame are pretty cheesy, then having an $80 lock isnt worth it... Bye for now but not for long Greeny BITNET: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU
-----------[000058][next][prev][last][first]---------------------------------------------------- From: rjg@sialis.mn.org (Robert J. Granvin) 26-APR-1989 3:08:09 To: misc-security@uunet.uu.net
Medeco has a range of varying security key blanks. All differing in
their difficulty to copy.
They replaced a key system about two years ago. Those keys can be
duplicated through contracted locksmiths. It is assumed that they
will follow the Medeco guidelines for duplication (which is require ID
against a "Valids" list, make the copies, then have you return to pick
them up).
The keys they replaced this system with are only available through
Medeco directly.
To duplicate the key, you must go to a contracted locksmith who has
your account on file. You must request a key by _number_, and sign a
form. You must be on a list of authorized parties... Once verified
by the locksmith as to your identity, the request is delivered to
Medeco who also does their own verification against an authorization
file, and then make the copies. The copies are shipped to the
locksmith, where you can pick them up, showing proper ID.
This is the plan, at least... :-)
But, keep in mind that a lock is only as good as the door and frame
around it. if your hinges are exposed to the outside, pin the
hinges. Also pay attention to the strike plate area. A steel door
and steel frame can be pried far enough apart with a crowbar to let
you get in. The lock does nothing for you here. Cover the strike
plate zone with a door-strike guard, at least. Next, can the entire
lock mechanism be cut out? I've seen gadgets that attach to the door
handle, and a little battery operated cutting blade will cut the whole
lock mechanism out of the door. Works on wood and steel.
You'll never beat them, but you can discourage them...
--
Robert J. Granvin
National Computer Systems "Looks like the poor devil died in his sleep."
rjg@sialis.mn.org "What a terrible way to die."
{amdahl,hpda}!bungia!sialis!rjg
14-Apr-89 22:37:35-GMT,942;000000000401
Date: 14 Apr 89 21:47:26 GMT
From: rjg@sialis.mn.org (Robert J. Granvin)
Subject: Re: Need info on Orange Book
To: misc-security@uunet.uu.net
In article <8904140138.AA17801@ucbarpa.Berkeley.EDU> ron@iconsys.UUCP (Ron Holt) writes:
>I need to get a copy of the "Orange Book". Could someone send me ordering
>information?\
Contact the National Computer Security Center. Ask for the
publications office. The number can be obtained by calling your local
number for the Government Information Center (You can tell I don't
have it handy :-). The Orange Book is one book out of several known
as "The Rainbow Set".
They can also be ordered through the Government Printing Office, but
they don't know what "The Orange Book" means.
Robert J. Granvin
National Computer Systems "Looks like the poor devil died in his sleep."
rjg@sialis.mn.org "What a terrible way to die."
{amdahl,hpda}!bungia!sialis!rjg
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: 24 Apr 89 19:29:28 GMT From: JDKINNE@MIAMIU.BITNET (John Kinne) To: misc.security Subject: Re: password security
To be effective, the number of people who know a pw must be kept to a minimum. The small department that I am associated with insures that each member of that small group is told the new pw, verbally, in a low voice. > how does a non-administrator get the password in an emergency? That service is unavailable until a staff member can fix it. We strive not to have all members of the support staff absent on the same day. When it is necessary that the complete support staff be absent, then we leave forwarding numbers. If that doesn't work, then the service is unavailable.
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 25 Apr 89 11:01:09 GMT From: jwright@ATANASOFF.CS.IASTATE.EDU (Jim Wright) To: misc.security Subject: END OF VOTE - comp.virus succeeds
The voting period for the new newsgroup comp.virus has just ended. The final vote count was 403 YES, 30 NO. I think it's fair to say that significant interest has been shown in this group. The list of voters will be posted in news.groups so you may verify that your vote was recorded. I'll gladly accept any corrections, although it would take a rather colossal error to affect the outcome of the vote. As per the "official guidelines", the group should be formed in approximately five days. (Today being 24-Apr-89.) Look for it soon at a computer near you. There has been some interest in the mailng list virus-l. Comp.virus and virus-l will contain the same information, the only difference being the method of distribution. The following information should assist you in subscribing to the list. Note that it is NOT necessary to subscribe to virus-l if you receive Usenet. Also, if you receive Usenet and subscribe to virus-l, you should unsubscribe once the group comp.virus is formed. There are currently about 1175 direct subscribers to virus-l, so I'm sure Ken would appreciate the reduced load. > ... So, to get onto the VIRUS-L mailing > list, send a mail message to <LISTSERV@LEHIIBM1.BITNET>. In the body > of the message, say nothing more than SUB VIRUS-L your name. LISTSERV > is a program which automates mailing lists such as VIRUS-L. > ... > If, in the unlikely event, you should happen to want to be removed > from the VIRUS-L discussion list, just send mail to > <LISTSERV@LEHIIBM1.BITNET> saying SIGNOFF VIRUS-L. Finally, we have been hard at work trying to organize a system of anti-viral software archive sites. Through the generous assistance of the individuals at each site, this promises to be a great success. We are still tying up some loose ends. Look for a full announcement of the archive system once comp.virus is in action. -- Jim Wright jwright@atanasoff.cs.iastate.edu
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 26 Apr 89 12:46:39 GMT From: simsong@idr.cambridge.ma.us (Simson L. Garfinkel) To: misc.security Subject: Re: Medeco Keys
This has gone far enough. When I was in New York, I was living with a cocaine dealer who had a Medeco lock on her front door. I wanted a spare key for my girlfriend, but the landlady wouldn't give one to me. I took the key to a tiny, Israeli locksmith near 98th street and Broadway. He measuered the hights of each using a tool with a triangular hole in it (with calibrations along the side), and wrote down the orientation of each notch. He then took a blank (that did not say "Medeco" on it) put it in a machine and started cutting the key. On each notch, he would change the orientation of the blank in the machine, in accordance with the original. The process took about 4 minutes and cost $5.00. The key worked the first time. -simson
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 27 Apr 89 15:56:40 GMT From: rsalz@BBN.COM (Rich Salz) To: misc.security Subject: Re: DES Export
Hi. A similar question came up in the Usenet newsgroup comp.unix; this is what I wrote. My interest goes back three years when I posted a DES package to world-wide distribution and got scared. /r$ PS: Any other DES-legal discussion in misc-security I can FTP? --------------------------------- Newsgroups: comp.unix Subject: Re: DES software >I need to find a copy (or, preferably, a summary written in English instead >of legalese) of the American regulations that restrict the export of DES and >other cryptographic software. Does anybody know where I can find this? Let me start with a disclaimer: I'm speaking only for myself here, most definitely not for my employer or anyone else I refer to below, and only as an interested layman. You will not be able to find a non-legalese summary. (Hubris makes me want to add "other than this one." :-) You will only be able to find legalese rules and such. Your best bet is to hunt through a law library and a one that has the US Federal Register. There are two popular researched analyses on DES that were distributed on Usenet. One is by John Gilmore, the other is by DEC's Corporate Law Office. Lots of other opinion and "facts" have been offered, but almost without exception they have been based on ignorance; unless you've done research, or have the two primary sources, it's probably safe to ignore everything you've read other than this. (There's that hubris again.) DES export is a complicated issue, and like all legal issues when you get an opinion you should keep in mind the viewpoing of the person who gives it. John wants to spread open information as widely as possible, DEC doesn't want to get hauled into court. I agree with John. >From his readings of the rules and regulations, John determined that DES is technical information, and software. This means that it is under the control of the Department of Commerce. As such, once it is in the open literature, it can be passed around the world. In terms of Usenet and distributing source, this might mean someone would first have to publish their code in a journal somewhere. The only exception to this is if you're on a small list of banned countries, and even that might not hold. DEC claims that John is wrong, that DES is specifically called out as munitions, and therefore is under the control of the Department of Defense, specifically the Munitions Control Act. The upshot is that you can't give it outside of the USA. I'm not a lawyer, but the took John's analysis apart sentence by sentence, ending with "It is imperative that no Digital employee act in reliance on Gilmore's analysis or his conclusions." They even used SCREAMING all-caps. Since neither Department is an expert, the NSA acts as the technical advisory expert. Based on a couple of phone calls, chats with some former employees, and a DES-related meeting, the NSA's position is that DES should not leave the country. Because of this, many Unix vendors have two versions of their software, and it depends on whether they ship the DES cryptographic stuff or not. I remember reading a note from one of the Unix originators, that the only reason there were two versions of Version 7 was more administrative than legal. Perhaps if someone back then was able to fight the red tape we'd be spared all this mess today, perhaps not. I've heard Amdahl got the right permissions to export DES, but I don't know for sure; it was only "planned" at the time I read that note, they may have backed down. DES export has been discussed, at times, in sci.crypt, and in the Kerberos and Internet Engineering Task Force mailing lists. Switching from reporter to interpreter, let me say that I think the situation is changing, and that the stupid US rules may -- applicable or not -- may be lifted soon. Note that soon is measured on a beaurocratic time scale, which is similar to geologic time. The technical community, in particular the Internet, has a good channel into the Department of Defense, and the right word seems to be reaching the right people. There is a need for DES to be used globally, and there has been world-wide publication (in comp.sources.unix/unix-sources) of a package written in Finland, posted from Australia. I no longer have John's analysis at all (it was mostly private email, that he later posted), and I do have the DEC analysis. I don't like to distribute it since it has the look of a DEC internal thing (even though it was forwarded, second-hand, to sci.crypt), and especially since I don't have John's work. It is, however, interesting reading, and if someone is going to take up the fight (as opposed to just idle curiousity), let me know. If you want to play lawyer, here are some places to start: Department of State You want sections 120-126, at least, of the International Traffic in Arms Regulation 22C.F.R Subch. M (I don't know what that last part means.) Office of Munitions Control, Department of State They're responsible for saying if something is "munitions." The National Security Agency I've heard their DES tech expert left, and they're in the lurch. It's funny the way the answer their phones. Department of Defense You want Section 38 of the Arms Export Control Act. Department of Commerce You want the Commodity Control List, and Export Administration Regulations, Section 370.10 and 379.3 (General License GTDA). I like to know what's going on, and I seem to be in touch with the several areas where this is discussed, so if you start digging around, I'd like to know. Yes, that means I'm offering to be a "point man" on this. /rich $alz PS: if ANYONE has a copy of John's research, please let me know; I'll pay you for a copy.
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 28 Apr 89 17:15:11 GMT From: steve@nuchat.uu.net (Steve Nuchia) To: misc.security Subject: connecting Suns to the internet: pitfalls?
A client has a small network of Suns that they would like to connect to the internet. They would accomplish this by bridging to the ethernet operated by the umbrella organization of which they are loosely a part. They have limited experience with this style of networking, having transitioned from VMS/THEnet only recently. They are very concerned about security. Not spooky, just the normal desire to have the system continue to work most of the time. The system is a 3/280 + 4 diskless Sun3 clients; some 386i stuff will be attached soon. All running SunOS4.0.1. The environment is quasi-academic, with lots of students hanging around. The attack scenarios we are most concerned with are the typical things you see at schools rather than sophisticated industrial espionage attacks. I haven't been through this before. I know a bit about security in general and securing a regular timesharing sort of system, but all the networks (and especially NFS systems) I've been responsible for have been isolated. I would appreciate any advice you might have to offer. Something like a checklist of things to button up or turn off seems a good goal, but priciples, platitutes, and references are also welcome. Ultimately I would like to have enough information to be able to tell my client that his system is safe to connect. Please send me mail -- my system is expiring news more often than I can get home to read it. I will condense the suggestions I receive and post a summary. Thank you. -- Steve Nuchia South Coast Computing Services uunet!nuchat!steve POB 890952 Houston, Texas 77289 (713) 964 2462 Consultation & Systems, Support for PD Software.
-----------[000064][next][prev][last][first]---------------------------------------------------- From: gwyn@brl.mil 30-APR-1989 14:47:29 To: security@rutgers.edu
As the moderator said, that's probably Medeco. Machines for duplicating Medeco keys are available to locksmiths. The blanks are probably harder to obtain, but anyone with access to a good milling machine could in principle manufacture his own. The main protection is that your corner drugstore is probably incapable of correctly duplicating Medeco keys, and most locksmiths realize that they are "high-security" items and should verify that you're entitled to make copies before doing so. Sargent's KESO series, since emulated with slight variations by other manufacturers, uses dimples drilled into the sides of the blank rather than notches cut out of the edge. Not many key duplicators are set up to duplicate/manufacture KESO keys. I think forced entry is more likely for most businesses than unauthorized key duplication; you can always rekey when an employee leaves (and it's pretty easy to do so if you use interchangeable-core cylinders).
-----------[000065][next][prev][last][first]---------------------------------------------------- From: "Craig Finseth" <fin@uf.msc.umn.edu> 30-APR-1989 15:23:24 To: haynes@ucscc.ucsc.edu Cc: security@pyrite.rutgers.edu
We have added the following rules to our passwd program: All candidate passwords must pass these tests: - It must be at least 6 characters long. - It must contain at least 1 non-alphanumeric character. - If there is only 1 non-alphanumeric character, it must not be the last character. - It must contain at least 4 distinct characters. Six variations of the candidate password are also checked further. The variations are: - The candidate password, - All but the first character of the candidate password, - All but the last character of the candidate password, and - The reversed versions of the first three. The further checks are: - Against the system dictionary, - Against an auxilliary "hit list" file, which includes the Internet virus list, all examples, and other special cases. - Appearance in /etc/passwd or /etc/group (this check catches the user name, first name, last name, and group name), - Against the form: <user name><user name>, and - Against the form: <user name><any><user name>. All checks are made ignoring upper/lower case. Of the approximately 1.9 billion passwords that consist of 6 characters, 5 of which are lower-case alphabetic and digit characters and 1 of which is a special character, these restrictions eliminate (very roughly) 10 million. In addition, we have a shadow password file and other changes. Craig A. Finseth fin@msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375
-----------[000066][next][prev][last][first]---------------------------------------------------- From: simsong@idr.cambridge.ma.us (Simson L. Garfinkel) 30-APR-1989 22:18:48 To: security@pyrite.rutgers.edu
Well, folks, I'm really doing it this time --- an article for the Whole Earth Review about everything you can do with somebody's number. If you have any info on: 1. destroying people (or their credit rating) 2. finding out personal information. 3. Using SSN's as gateways, or impersonation. 4. Other stuff Please call me at 617-876-6111 or send email to simsong@athena.mit.edu. Thanks. -simson
-----------[000067][next][prev][last][first]---------------------------------------------------- From: (Marshall D. Abrams) <abrams%smiley@gateway.mitre.org> 30-APR-1989 23:02:17 To: security@pyrite.rutgers.edu
We have also been working on access control models and are interested in sharing information with you. Our work is a "white paper" on access control concepts for the National Computer Security Center. What is the purpose, focus, and audience for your work? Here is the to-date bibliography for our access control paper. The numbers are out of order (we've just been adding as we go along and will redo at the end.) This is a derect extract from our source file, including troff marco commands. [Moderator insertion: Said bibliography approaches 10K and is probably of interest to only a few readers. Please contact Marshall directly if you want a copy... _H*] Sincerely, - - Marshall D. Abrams, phone: (703) 883-6938 The MITRE Corporation, 7525 Colshire Drive Mail Stop Z506, Mc Lean, VA 22102
-----------[000068][next][prev][last][first]---------------------------------------------------- From: