Another Son of Clipper discussion paper

[m5@dev.tivoli.com (Mike McNally)]

This is really interesting to me:

Jim Gillogly forwards:
 > Key Escrow Issues Meeting, September 6-7, 1995
 > Discussion Paper #3
 > 
 >                  Export Criteria Discussion Draft --
 >                 64-bit Software Key Escrow Encryption
 > . . .
 >                           --- Draft Export Criteria ---
 > for Software Key Escrow Encryption
 > 
 > Software key escrow encryption products meeting the following
 > criteria will be granted special export licensing...
 > 
 > 1.    The product will use an unclassified encryption algorithm
 >       (e.g., DES, RC4) with a key length not to exceed 64 bits.

Ok, sounds good... but what I don't understand is further on:

 > 5.    The product shall be resistant to any alteration that would
 >       disable or circumvent the key escrow mechanism, to include
 >       being designed so that the key escrow mechanism cannot be
 >       disabled by a static patch, (i.e., the replacement of a
 >       block of code by a modified block).

[ that I can understand ]

 > 6.    The product shall not decrypt messages or files encrypted by
 >       non-escrowed products, including products whose key escrow
 >       mechanisms have been altered or disabled.

This is where I start scratching my head.  I mean, how exactly will
the software be able to tell that what's being fed into it came from a
Good version versus an Evil version of the cryptosystem?  Isn't that
very issue the reason for Skipjack being (A) secret and (B) kept on a
supposedly auto-desctruct chip?

If the algorithm is public (and to stretch a point, if the executable
makes it onto somebody's hard disk, it's effectively public), I don't
really understand how the above can be made a realistic goal.  I'd
always thought that the idea behind software key escrow was that it'd
be stuck into most "name-brand" tools, so that Joe Lazy AOL User
wouldn't bother (or wouldn't know how) to circumvent it.  (Still seems
kinda ridiculous, but maybe that's just me.)  Anyway, this document
makes it seem like somebody seriously expects this is doable.  If it
is, then I *really* want to know how (because I'd like to exploit that
sort of technology myself...).

 > 7.    The key escrow mechanism allows access to a user's encrypted
 >       information regardless of whether that user is the sender or
 >       the intended recipient of the encrypted information.

Ooh.

 > 8.    The key escrow mechanism shall not require repeated
 >       involvement by the escrow agents for the recovery of
 >       multiple decryption keys during the period of authorized
 >       access.

Hmm...

 > 9.    In the event any such product is or may be available in the
 >       United States, each production copy of the software shall
 >       either have a unique key required for decrypting messages or
 >       files that is escrowed in accordance with #10, 

Well there go the manufacturing costs up through the roof...

 >       or have the
 >       capability for its escrow mechanism to be rekeyed and any
 >       new key to be escrowed in accordance with #10.

I guess that'd work with the somewhat weak mechanisms used with
"unlockable" CD-ROM stuff.

 > 10.   The product shall accept escrow of its key(s) only with
 >       escrow agents certified by the U.S. Government or by foreign
 >       governments with which the U.S. Government has formal
 >       agreements consistent with U.S. law enforcement and national
 >       security requirements.

Again, how can it tell?

Maybe I'm just being dense.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Nobody's going to listen to you if you just | Mike McNally (m5@tivoli.com) |
| stand there and flap your arms like a fish. | Tivoli Systems, Austin TX    |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~