From: Toto <toto@sk.sympatico.ca>
Date: Thu, 9 Jan 1997 20:51:12 -0800 (PST)
To: Ken Kirksey <kkirksey@appstate.campus.mci.net>
Subject: Re: Key Escrow Good, GAK Bad
In-Reply-To: <199701092131.QAA00797@aus-c.mp.campus.mci.net>
Message-ID: <32D5DEDA.26D5@sk.sympatico.ca>
MIME-Version: 1.0
Content-Type: text/plain


Ken Kirksey wrote:

> And he is a typical computer user.  If your average joe forgets his
> passphrase and loses two days worth of work, he's not likely to encrypt
> his work again.  (Or he's likely to write down his passphrase in the
> future).  If we were using a Key Escrow system, this situation could have
> been avoided.  Yes, using a key escrow system is less secure that using a
> non-key escrow system, but I'd argue that using a strong key escrow
> system is better than using no encryption at all in situations like this.

  Key escrow is an easy-fix for securing company communications, and I
am sure that it has its place in a situation such as yours, where you
have to baby-sit people who want the full benefits of a technology
that is beyond them.
  The problem, of course, is that, as TV has shown us for years, the
'lowest common denominator' becomes the rule. People will use key 
escrow for things that should actually have uncomprimisable security,
and they will scream bloody murder when it is compromised.

  It wasn't that long ago when I was talking to the CEO of a company
on a plane to Nantucket, and he was boasting about how he encrypted
his files with Pkzip to thwart would-be intruders.
  I decrypted one of his files for him on the trip between the mainland
and Nantucket (you go up, you go down, you're there). He was astounded.
He had told me that his kid was a hacker, so I told him to ask his kid
if he could access his 'protected' files.
  I forgot about the incident, but a few weeks later the guy tracked
me down in Tucson (I had told him the name of my company), and told
me that it took his kid less than a week of scouting around the local
BBS's to find a program to crack Poppa's 'high-security' files.

  Key Escrow, I suppose, is like most other things--a trade-off.
  BTW, I occasionally 'write down' a reference to my passwords, as 
a 'reminder'.
  e.g. - Password / Zappa Concert--1980
         (this reminds me of the password I used, which was
           38-24-37RedHead)
      (sorry, no pictures)

Toto


> 
> >  To me, Key Recovery cryptography is like using a condom with a
> >hole in it. No thanks.
> 
> I agree in principle, and I doubt I would ever use a key recovery system
> if I had a choice.  But, speaking as a network manager, I know that
> private key recovery (not GAK) can be an enhancement to security.
> 
> I'll give an example.  About a year ago, my boss wanted to protect his
> file of annual financial projections for the company from prying eyes on
> our Macintosh network.  I installed CurveEncrypt on his machine, showed
> him how to use it, and gave him the standard lecture on choosing a good
> passphrase.  I stressed that he needed to chose a passphrase easy to
> remember, because if he forgot it, there was no way to get his file back.
> 
> Well, he forgot his passphrase.  He spent an hour trying every
> combination he could think of, interjecting a curse here and there for
> color.  He is now totally off using encryption to protect sensitive
> information.  He refuses to use it, and he discourages anyone in the
> office from using it.  I know that his position is unfair, but he _is_
> the boss, so he makes the rules.
> 
> And he is a typical computer user.  If your average joe forgets his
> passphrase and loses two days worth of work, he's not likely to encrypt
> his work again.  (Or he's likely to write down his passphrase in the
> future).  If we were using a Key Escrow system, this situation could have
> been avoided.  Yes, using a key escrow system is less secure that using a
> non-key escrow system, but I'd argue that using a strong key escrow
> system is better than using no encryption at all in situations like this.
>  Our network is less secure that it could be because of one user's bad
> experience.
> 
> Ken