In last week's BillWatch (Issue #14) we described the background surrounding the announcement of the government's new "Key Escrow" proposal. Details are still sketchy, probably because they haven't been worked out yet. However detractors are calling the plan "Son of Clipper" while proponents are hoping it will strike a balance between industry, law enforcement, and the public.

NIST has distributed two discussion drafts to guide presentations on the workshops on Sep. 6th and 7th. Because this is not a public-friendly process (few of your elected representatives are likely to be involved in this process) we have re-published these papers here for your perusal.

VTW would like to publicly thank NIST for providing this information.

On August 17, 1995, the Administration announced its proposal to permit the ready 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. Under the proposal, products will be reviewed to verify that they satisfy the criteria and, if so, they will be transferred to the Commodity Control List administered by the Department of Commerce where the products can be exported under a general license (in much the same way that 40-bit RC2/RC4 encryption is licensed today).

We are working toward creating broadly stated criteria that are in the nature of performance specifications. To meet these criteria, encryption products will need to implement key escrow mechanisms that cannot be readily altered or bypassed so as to defeat the purposes of key escrowing.

The criteria, when finalized and published, will state the objectives, but not the exact technical method(s), by which those objectives are satisfied. This is to provide software publishers the flexibility to design methods for meeting our stated objectives in a manner that is compatible with the design of their products. There are, therefore, a number of questions we must work together to answer in order to draft effective criteria. These questions are:

• Avoiding multiple encryption -- How can the product be designed so as to prevent doubling (or tripling, etc.) the key space of the algorithm?

• Disabling the key escrow mechanism -- How can products be made resistant to alteration that would disable or circumvent the key escrow mechanism? How can the "static patch" problem be avoided? How can this be tested?

• Access to escrow information -- What mechanisms must be designed into encryption products to allow authorized access to escrowed keys? This likely includes the identity of the key escrow agent(s) and a serial number for the key escrow agent to use to identify the key(s)/component(s) necessary to decrypt the message. What other information will be necessary to be provided to the escrow agent to identify the necessary key(s)/component(s)? Are there other comparable viable approaches?

• Non-escrowed use -- How can products be made so that they do not function with non-escrowed products (or tampered escrowed products)? How can this be tested?

• Limiting surveillance -- How can products be designed so that information both sent and received by the user can be decrypted without release of keys of other users?

• Practical Key Access -- How can mechanisms be designed so that repeated involvement of escrow agents is not required for decryption for multiple files/messages during the specified access period?

• Assurance that keys are escrowed -- How can it be assured that key escrow products are indeed satisfactorily escrowed? For example, products could be required to be escrowed at time of manufacture or be made inoperable until properly escrowed.

• Ability to re-escrow keys -- How can products be designed so that new keys can be escrowed at the user's discretion with a U.S. Government approved escrow agent?

• Certified escrow agents -- Can products be designed so that only escrow agents certified by the U.S. government (domestic, or under suitable arrangements, foreign) are utilized? What should be the criteria for an acceptable U.S. escrow agent?

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.

8/25/94

In the government's recent announcement of its intent to allow the export of 64-bit software key escrow encryption products, one stipulation was that the keys would be escrowed with an approved key escrow agent.(

      *** Know of someone ANYWHERE with a fax machine but without net ***
      *** access that's interested in VTW's issues?  Tell them to     ***
      *** call and get on our weekly fax distribution list at         ***
      *** (718) 596-2851 (or email us their fax number.               ***

From:
Date: Sat, 26 Aug 1995 16:04:40 -0400
From: farber@central.cis.upenn.edu (David Farber)
Subject: CHANGES IN US CRYPTOGRAPHY POLICY -- see end for credit
Precedence: list
To: interesting-people@eff.org (interesting-people mailing list)