by Eugene Volokh, VESOFT
           Published by HP PROFESSIONAL Magazine, May 1988.

   At  first glance, encryption programs (several are available on the
Contributed  Library) seem to be powerful security tools.   Encryption
is    the  only  fairly  foolproof  way  of  protecting  data  against
unauthorized  reading, both  by  outsiders  and  insiders.   Even  the
system  manager, to whom MPE gives unlimited access rights to any file
in   the  system, can't read a personal document that you've encrypted
with your own secret key.

   In  fact, whenever any of our customers called and asked  us  about
read-protecting    files,   we  recommended  one  of  the  contributed
encryption  programs.  Actually, we  first  advised  them  to  protect
their  files with MPE's file security, which worked quite admirably as
a   defense  against  anybody  except  a  console  operator  or system
manager;  however, if they didn't want even their system manager to be
able  to read the files (or were afraid that some operator might  pick
them up off a backup tape), encryption seemed to be the way to go.

   Then,  in   spring  of  1987,  we got a call from one of our users.
They  had just fired one of their programmers and two days later found
that  their system was aborting!  Sure enough, there was a  time  bomb
in  their software (I had to find it in the object code since they had
lost  the source code!) and I had to defuse it by patching the program
file.    In  fact,  I  had to come back six months later to defuse yet
another  time bomb in the same program, and at that time found a third
bomb that was set to "explode" a month later.

   Shortly  after I got rid of the first time  bomb,  they  called  us
again.    Apparently, some months before being fired, the saboteur had
encrypted  the source code of  another  of  their  systems!   Tens  of
thousands    of   dollars   worth   of  software  was  now  completely
inaccessible, the key known only to the departed programmer.

   This,  of course, is the "mixed blessing" that I allude to  in  the
title   of  the paper.  This company actually had NO NEED for any kind
of  source code encryption.  Although some sites may have  a  use  for
encryption  (mostly of their data and, say, management memos, letters,
etc.),  this site did not; certainly, it derived no benefit from being
able to encrypt its source code, since it wasn't in any way secret.

   In  any event, somebody must have pulled the encryption program off
a   contributed  library  tape,  and our hero decided to "protect" the
company's  source code.  He may have done this maliciously, or perhaps
he  may have been the kind of person who impulsively  protects  things
even  though they really require no protection.  (Naturally, being the
vendors   of  a  security  package,  we  encourage  people  to  "think
security"  -- however, encrypting source files is usually going a  bit
too  far; much better to be concerned with things like logon security,
embedded   passwords,  periodic password changes, etc.).  What matters
is  that he was gone and the  source  code  was  unreadable  --  which
meant,   as  I mentioned, a loss of tens of thousands of dollars worth
of software investment.

   When  our customer first mentioned this to us, our first suggestion
was,  of course, to ask the culprit.  Bribe  him,  threaten  him  with
lawsuit,  threaten him with criminal prosecution (the time bomb itself
was   almost  certainly  a  crime,  perhaps  a  felony) -- even if you
couldn't  get a conviction, you should be able to  frighten  him  into
giving   you  the key, which, after all, would be the easiest thing in
the world for him.

   Unfortunately  (I say  "unfortunately"  because  I  think  the  guy
should  have had the book thrown at him -- he's a menace), the company
wanted  nothing whatsoever to do with the man again.  They are a large
enterprise,    with   a   large  enterprise's  distaste  for  negative
publicity;  management would rather lose thousands than  get  involved
in   a  "Goliath vs. David" sort of case where they (although they are
in  reality the innocent party) might be portrayed  as  big  bad  guys
trying to "get" a poor helpless ex-employee.

   Instead,  they  asked me whether there was anything I could do.  At
first  glance, I thought that this was impossible --  after  all,  any
good  encryption system that uses an encryption key is (theoretically)
almost   unbreakable;  you  can try to decrypt the encrypted file, but
unless  you stumble across the right key, all you'll get  is  garbage.
I'm  sure that some National Security Agency cryptographers armed with
Crays   could  do it in a jiffy, but I have neither their hardware nor
their  sophisticated algorithms (in fact, much  advanced  cryptography
is classified as government secret).

   Fortunately, I got an idea.  If

   SOURCE FILE + KEY yields ENCRYPTED FILE (encryption)


   ENCRYPTED FILE + KEY yields SOURCE FILE (decryption)

then it stands to reason that


In  other   words,  if  they  had  an  unencrypted  copy of one of the
encrypted  files, then with luck I might be able  to  deduce  the  key
with   which  the file was encrypted, and then decrypt the rest of the
files with that key (if they were all encrypted with the same key).

   I  asked the author of the encryption program for its  source  code
and   got  to  work.  A couple of days later (and a couple of thousand
dollars  later for our client), I worked out a solution.  Essentially,
I  reduced the problem to a system of 64 equations with  64  unknowns,
where    the   operators   were   Circular  Shift  and  Exclusive  OR.
Unfortunately,  I knew of no way to solve it algorithmically; instead,
I  wrote a PASCAL program.  This program made assumptions  about  each
unknown   (each  unknown's  value  could  be  0 or 1, and it made each
assumption  in  turn)  until  it  got  enough  data  to  start  making
deductions.   Then it would deduce as many values as possible until it
either   figured every value out (a solution), got a contradiction (in
which  case it would forget the last assumption it made and assume the
opposite),  or found that it could make no more deductions  (and  thus
had to make some more assumptions).

   Finally,  after   about an hour's computer time, I got 256 possible
solutions.   It turns out that because of the nature of the algorithm,
any  of them would work to decrypt the files, but  only  one  actually
represented   a  sequence of printable ASCII characters -- this turned
out to be the key that the culprit actually used.

   Curiously  enough, the key was the name of the group in  which  the
files   were  stored.  If the customer (or, for that matter, I myself)
tried it in the first place, we'd have saved a lot of time.

   Thus,  this case turned out better than expected -- the company got
their  source code back (although they had to pay some consulting fees
to do this).

   At  first, we thought that this was an isolated incident.  Then,  a
few   months later, I was scanning through a bulletin board when I ran
into  a message from somebody else complaining  of  exactly  the  same
thing!    A  programmer  had encrypted some files and then left on bad
terms.   In this case, the company wasn't so  lucky  (I  believe  they
didn't   have  any  unencrypted source code to work out the key from).
Three  months later, we got a call from another person -- exactly  the
same  thing had happened again (again, we couldn't do anything to save
their   files).   Fortunately,  this  last  person  was  going  to  do
something  about it  --  threaten  some  sort  of  civil  or  criminal
prosecution of the wrongdoer.

   Thus,  it  appears that misuse of encryption software is not such a
rare   circumstance  at  all.   In  fact,  I  suspect  that  ABUSE  of
encryption   is  more  frequent  than  PROPER  USE  (especially if you
include  the accidental  cases,  where  some  over-zealous  programmer
encrypts   his  sources  and forgets his key!).  By and large, there's
very  little data -- especially data stored in non-database  files  --
that   really  needs  encrypting;  an adequate file security system is
usually  quite sufficient.  Certainly nobody except software suppliers
really needs to encrypt source code.

   Thus, our recommendation to HP users is:


     In  other   words, don't encrypt just for "general principles" --
     think  whether you really need to (especially  in  light  of  the
     fact   that  most  valuable  data  is  usually  stored  in  IMAGE
     databases, which most encryption programs don't handle).

   As  sometimes happens, what at first glance seems  to  be  a  great
idea   can  actually  do  more  harm  than  good.   Security is a very
important  issue, and you should think about it seriously; however, as
you  see, you could face serious problems  if  you  choose  the  wrong
security solution.

   What  if  you've already fallen guilty to a cryptographic saboteur?
Trying  to decrypt  your  programs  with  a  method  like  the  one  I
mentioned   should  be  your  last  try,  not your first -- it's quite
expensive,  time-consuming, and uncertain (since if you don't have the
EXACT original source code, you're in trouble).

   As  in all cases of computer crime (or of crime  in  general),  the
best   solution  is  to  bring in the law.  Though I'm certainly not a
lawyer,  as I see it, you have two possible approaches: the civil  and
the  criminal.  You can sue (or, more to the point, threaten to sue if
he   doesn't  give  you  the  key)  for  damages,  alleging  that  his
intentional  act (or even his negligence) has deprived you of the  use
of   your  software,  in  which you've invested a great deal of money.
Or,  you may try to  prosecute  on  some  sort  of  criminal  sabotage
charge,  again alleging that the person intentionally acted to deprive
you of what was rightfully yours.

   I've  heard different opinions on the criminal matter -- one person
(a   policeman  experienced in computer crime investigation) mentioned
that  it may be impossible to prosecute unless you can prove that  the
initial   encryption  was  malicious;  if  the  person  claims that he
encrypted  the software legitimately, out of a desire to "secure"  his
employer's  system, it may be very hard to prove otherwise, even if he
refuses  to decrypt the software after he's fired.  On the other hand,
a   computer  lawyer I talked to said that prosecution may not be that
difficult;  you probably  want  to  get  in  touch  with  your  police
department  to find out (many big police departments by now have a lot
of experience in computer crime investigation).

   In  any case, the mere threat of criminal or even civil prosecution
can   make the culprit come around -- after all, all he needs to do is
tell  you the key (unless he's forgotten it!), and then he's  off  the
hook.    Even if he thinks he'd win in a legal case in the long run, I
strongly doubt that he'd be willing to chance it.

   What's  more, by taking stern action against this sort of  computer
crime   (and in all three cases I mentioned, and in several other ones
that  I  know  of,  crime  is  EXACTLY  what's  involved),  you'll  be
preventing   such  things  in  the  future,  both  on  the part of the
particular  wrongdoer involved and by any  of  your  other  employees.
Just   like  drunk  driving  and shoplifting a decade or two ago, many
people  see computer crime (especially  sabotage)  as  nothing  really
serious,   just  a  "harmless  prank" or a test of programmer skill --
it's time that this attitude was changed, and changed radically.

Go to Adager's index of technical papers