The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

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 technology

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

-----------[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:      /* Purple Haze */ <NCASTELLANO@eagle.wesleyan.edu>  1-MAY-1989 18:21:55
To:        security@pyrite.rutgers.edu
There's been a lot of talk about these high-security car locks.  I'm curious to
know why they are being called 'car locks' at all.  Couldn't they be used (with
a small power source of course) as a regular door lock?

Wouldn't it be a bummer if you had to get into a car locked with one of these
and your battery was dead?

END OF DOCUMENT