Another Son of Clipper discussion paper

I sent along two discussion papers for tomorrow's NIST session on the
revised plans for GAK last week.  Here's the third.

	Jim Gillogly
	Hevensday, 14 Halimath S.R. 1995, 20:49
-----------------------------------------------------------------------------

Key Escrow Issues Meeting, September 6-7, 1995
Discussion Paper #3

                 Export Criteria Discussion Draft --
                64-bit Software Key Escrow Encryption

As discussed at the SPA/AEA meeting on August 17, 1995, the
Administration is willing to allow the export of software
encryption provided that the products use algorithms with key
space that does not exceed 64 bits and the key(s) required to
decrypt messages/files are escrowed with approved escrow agents.
On the same date, the September 6-7 key escrow issues meeting at
NIST was also announced.  The two principal topics at the meeting
will be:  discussion of issues of exportability of 64-bit
software key escrow encryption and 2) desirable characteristics
for key escrow agents.

In order to help make most productive use of the limited time
available at the upcoming meeting and to better focus
deliberation, the following criteria are being distributed for
discussion purposes.  Since it is important that final criteria
be clear, straightforward, consistent, and implementable, please
review these draft criteria and be prepared to discuss
how they may be refined and made more specific.

                          --- Draft Export Criteria ---
for Software Key Escrow Encryption

Software key escrow encryption products meeting the following
criteria will be granted special export licensing treatment
similar to that afforded other mass-market software products with
encryption.

1.    The product will use an unclassified encryption algorithm
      (e.g., DES, RC4) with a key length not to exceed 64 bits.

2.    The product shall be designed to prevent multiple encryption
      (e.g., triple-DES).

3.    The key required to decrypt each message or file shall be
      accessible through a key escrow mechanism in the product,
      and such keys will be escrowed during manufacture in
      accordance with #10.  If such keys are not escrowed during
      manufacture, the product shall be inoperable until the key
      is escrowed in accordance with #10.

4.    The key escrow mechanism shall be designed to include with
      each encrypted message or file, in a format accessible by
      authorized entities, the identity of the key escrow
      agent(s), and information sufficient for the escrow agent(s)
      to identify the key or key components required to decrypt
      that message.

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).

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.

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.

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.

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, or have the
      capability for its escrow mechanism to be rekeyed and any
      new key to be escrowed in accordance with #10.

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.

Note: Software products incorporating additional encryption
methods other than key escrow encryption methods will be
evaluated for export on the basis of each encryption method
included, as is already the case with existing products.
Accordingly, these criteria apply only to the key escrow
encryption method incorporated by a software product, and not to
other non-escrowed encryption methods it may incorporate.  For
instance, non-escrowed encryption using a key length of 40 bits
or less will continue to be exportable under existing export
regulations.
                                - - -
Please also review discussion paper #1 (distributed earlier),
which raises a number of issues involving exportability criteria
and how exportable products could be designed.  Discussion paper
#2 (also previously distributed) presents questions involving key
escrow agents.

Note:  These issues will be discussed at the Key Escrow Issues
Meeting to be held September 6-7, 1995 (9:00 a.m. - 5:00 p.m.) at
the National Institute of Standards and Technology (Gaithersburg,
Maryland).  The meeting will be open to the public, although
seating is limited.  Advance registration is requested, please
contact Arlene Carlton on 301/975-3240, fax: 301/948-1784 or e-
mail: carlton@micf.nist.gov.

9/1/95
-----------------------------------------------------------------------------

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    |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> 
> Key Escrow Issues Meeting, September 6-7, 1995
> Discussion Paper #3
> 
>                  Export Criteria Discussion Draft --
>                 64-bit Software Key Escrow Encryption

Pardon my obvious question, but if there's some sort of GAK/LEAF, then
why limit it to 64-bit? It seems possible that the assumption is 'just
in case the GAK is tampered with' there's still a chance of cracking it,
should the need arise.

[..]

I'm wondering just how securely a hack-proof escrow system can be written.
It seems that someone can always go in with a sophisticated debugger and
do some tampering of the software.

And one need not mention the what-if-foreign-competitors-do-not-implement-
this-scheme? question...

J.G. on "proposed escrow techniques":
>In order to help make most productive use of the limited time
>available at the upcoming meeting and to better focus
>deliberation, the following criteria are being distributed for
>discussion purposes.  Since it is important that final criteria
>be clear, straightforward, consistent, and implementable, please
>review these draft criteria and be prepared to discuss
>how they may be refined and made more specific.

could someone explain to me why the passive voice is being used
in this proposal? who is proposing this criteria?

there is a saying "he who appeases an alligator does so in hopes
of being eaten last".

J.G., where did this list of proposal items come from? from you?
are you a private researcher? if so, how do you justify this list?
I mean, I can imagine someone from the NSA coming up with something
this specific and restrictive, but frankly I find it in rather
poor taste for private, unaffiliated researchers trying to
bargain with the NSA. there is a clear-cut right to encryption in
a free society, and anything less is a compromise with totalitarianism
IMHO.

IMHO no genuine self-respecting cypherpunk would be involved in any kind
of discussions involving government key escrow, unless to go as
an agent provocateur. the whole issue lends an "aura of legitimacy"
to an issue that has absolutely none. its like the Perl shirt--
as I have said many times, as long as people argue about the 
precise legality of the code, they are *losing* the battle with the
NSA and playing into their hand and exactly the kind of paranoia
over cryptography use they are trying to cultivate.

--Vlad Nuri