NASA National Aeronautics and Space Administration Washington D.C. 20546 JTD James H. Burrows, Director Computer Systems Laboratory Technology Building, Room B154 National Institute of Standards and Technology Gaithersburg, Maryland 20899 Dear Mr. Burrows: NASA has reviewed the proposed Federal Information Processing Standard (FIPS) for and Escrowed Encryption Standard (EES) and provides comments below. NASA does not support the adoption of the proposed FIPS for and EES. NASA understands the need to keep sensitive, unclassified information from those without a need to know, however the EES is not appropriate for use in the NASA environment. Many NASA organizations are currently utilizing Data Encryption Standard (DES) based devices for the telecommunication of sensitive unclassified data. NASA has identified several EES-related issues that need to be addressed. The significant issues are discussed below. 1. Devices using the EES (CAPSTONE and CLIPPER), which implement the classified SKIPJACK algorithm, must be programmed. The chip programmer is a device provided by the National Security Agency (NSA). There is no assurance, without scrutiny, that all keying material introduced during the chip programming is not already available to the NSA. Thus, not only do the key escrow agents have a decryption capability,the NSA also retains this capability. As long as the programming devices are controlled by the NSA, there is no way to prevent the NSA from routinely monitoring all SKIPJACK encrypted traffic. Moreover, compromise of the NSA keys, such as in the Walker case, could compromise the entire EES system. 2. Users with criminal intent who are smart enough to use encryption will employ their own algorithms, thereby defeating EES devices. Should EES devices be mandated under law, these users will still encrypt the information feeding into the EES devices, thereby defeating EES. 3. Commercial and international use issues must be resolved in order for there to be value to the government. If the EES is not adopted by non-government organizations, Federal agencies will be impacted by a significant cost and inefficiency factors. This is particularly true of government agencies with many non-government customers and suppliers. 4. Implementation of this standard would result in a significant, adverse impact to NASA. The Headquarters Computer Network, other local area networks, and many computers that are not TEMPEST-rated would have to be modified or replaced at considerable cost. NASA would no be able to use the Internet or any other network that did not use the same encryption method and the same encryption key. EES devices offer no significant benefit to NASA over existing DES-base devices and their implementation would adversely impact many NASA organizations. Therefore, NASA does not concur with the adoption of the proposed FIPS for an EES. Benita A. Cooper Associate Administrator for Management Systems and Facilities
UNITED STATES DEPARTMENT OF COMMERCE OFFICE OF THE SECRETARY WASHINGTON, D.C. 20230 MAY 23, 1997 Mr. Charles R. Smith Softwar 7707 Whirlaway Drive Midlothian, Virginia 23112 Dear Mr. Smith: This is an interim response to your Freedom of Information Act (FOIA) request dated April 5, 1997 requesting 1) All data provided to and/or about the following individuals in reference with project Clipper, encryption software, legislation on encryption software, policy and contractual arrangements. Specifically, Clipper algorithm information provided, policy and/or briefing papers in connection with encryption software: Vice President Gore, Mrs. Hillary Clinton, Ginger Lew, Ira Sockowitz, James Bidzos, CEO of RSA Inc, and George Tenet and 2) Information on financial donations, meetings, negotiations, and policy decisions in reference to Government negotiations to purchase or obtain controlling interest in RSA Inc., an encryption software company owned by James Bidzos. We are enclosing responsive documents to your request which are either not subject to exemption from release under the FOIA or for which the Department has made a discretionary disclosure. Seven documents which provide legal advice concerning project Clipper are being withheld under attorney-client privilege incorporated into exemptions (b)(5), two documents are being withheld under the attorney-client privilege and deliberative process privilege incorporated into exemption (b)(5) and one document is being withheld under the deliberative process privilege incorporated into exemptions (b)(5). Three documents are being withheld in part under the attorney-client and attorney work-product privileges incorporated into exemption (b)(5). We have located five documents that originated at agencies other than the Department of Commerce. Pursuant to Department of Commerce regulations (15 CFR 4.6 (1)(4)), we have referred one document to the United States Department of Justice. You may contact Patricia D. Harris, FOIA Officer, Department of Justice, FOIA/PA Section, Room B-208 Justice Management Division, Washington, D.C. 20530 regarding the status of their review of this document. We have also referred four documents to another agency for consultation. We will inform you of our decision with respect to these documents after we receive the results of the agency review. In addition, you should be aware that several documents which are being released to you were created by entities outside of the Government and are copyrighted. We have not completed our review of all the records which are responsive to your request. We will be providing you with a final response once our review of those additional records have been completed. You have a right to appeal this partial denial of your request within 30 days of the date of this letter. Any appeal should be addressed to the Assistant General Counsel for Administration, Room 5898-C, U.S. Department of Commerce, 14th and Constitution Avenue, N.W., Washington, D.C. 20230. Any appeal should include a copy of the original request, this response, and a statement of the reasons why this response is in error. Both the appeal letter and the envelope should be clearly marked "Freedom of Information Act Appeal." Sincerely, Bettie Baca Executive Secretary Enclosures cc: Patricia D. Harris
Transcriber note:
Redacted material consists of FAX cover page (all of page 1), hand written notes placed on the right hand side of page 3, and a "sticky" note with handwritten comments placed on the lower left hand side of the same memo on page 7. Page 8 was the same memo without the note.
AREAS MARKED "XXXX" ARE REDACTED.
10/01/93 10:57 301 948 1784 NIST CSL 002
TRUSTED INFORMATION SYSTEMS, INC.
Computer and Communications Security
STEPHEN T. WALKER
PRESIDENT
GLENWOOD, MD
LOS ANGELES, CA
MINNEAPOLIS, MN
MT. VIEW, CA
LONDON, UK
September 28, 1993
Director, Computer Systems Laboratory
National Institute of Standards and Technology
Technology Building, Room B-154
Gaithersburg, MD 20899
Attn: Proposed FIPS for Escrowed Encryption Standard
Dear Sir:
On behalf of TIS, I hereby submit our very serious objections to
the referenced proposed Federal Information Processing Standard
(FIPS) and our recommendation that this proposal be rejected by
the Department of Commerce for consideration as a FIPS.
Our objections are in three all encompassing areas. First, this
draft is a corruption of the basic FIPS process itself. Second,
it is a technically content-free standard. Third, it lacks any
evidence of an economic analysis of the cost-benefit
relationship of the proposed key escrow process.
1. Corruption of the FIPS Process
This proposed FIPS deviates so significantly from the "normal"
FIPS process that it violates almost thirty years of tradition
of open standards that have been subjected to repeated public
scrutiny and arc as technically sound as any public process can
make them. Independent of the contents of this proposed FIPS,
this shift in the FIPS process itself must be resisted if we are
ever to have technical standards that are acceptable to the
public again.
The traditional FIPS process, as represented by the very recent
FIPS 140-1 proposal, typically involves the generation of a set
of technical ideas which are discussed in public workshops and
seminars, followed by a draft proposed standard which is widely
distributed for public comment, often followed by several
iterations, each attempting to meet the technical concerns of
particular segments of the public and, eventually, resulting in
a FIPS document that represents an acceptable compromise of
technical ideas. This process, amazingly similar to the way
Congress passes legislation, however long and frustrating, is
undoubtedly the best process we will ever devise for producing a
publicly acceptable standard that will be implemented by industry
and yield products that can be purchased by consumers as well as
the Government.
The Escrowed Encryption Standard (EES) proposed FIPS completely
ignores this process and puts forth in the briefest, technically
content-free document possible, a proposal which forces the
public to rely completely on secret information that they will
never be able to examine or understand. Secret specifications
may be a necessary part of developing equipment and
3060 WASHINGTON ROAD (RT. 97)
GLENWOOD, ND 21738
(301) 854-6889
(301) 854-5363 (FAX)
10/01/93 10:57 301 948 1784 NIST CSL 003
Director, Computer Systems Laboratory
September 28, 1993
Page 2
procedures for protecting classified national security related
information. But, they have no place in a free society in
protesting unclassified Government and commercial information.
One must assume that the technicians that have devised the
classified background for this FIPS shell are good at what they
are doing (though the rumored further delay in availability of
Clipper chips to the first quarter of 1994 does not build one's
confidence). But, one must question the need for such secrecy
and the price the Government will pay for being unwilling to
share the technology by which it intends to protect our
unclassified information.
There are alternatives to key escrow encryption that are
technically sound and could follow the traditional FIPS
approach. There are multiple instances of telephone security
devices that are presently commercially available using
proprietary approaches that could last to the Date Encryption
Standard, by which NIST seeks proposals from industry and
negotiates to have complete rights granted to the public to use
the approved commercial approach.
For unspecified reasons, NIST has chosen to abdicate its FIPS
procedures and, without seeking public suggestion, to proceed
directly with this unorthodox classified FIPS approach.
The only apparent reason given for the haste with which this
process is proceeding is that "the President said he wanted it."
Apparently, the staff people who prepared the President's
statement of April 16, 1993 on the Clipper Initiative included
comments to the effect that NIST should proceed quickly to
develop a FIPS covering key escrow procedures.
I do not believe that if President Clinton understood, when he XXXXXX
signed the April 16 announcement, he was asking for such a XXXXXX
corruption of the technical process by which FIPS are developed, XXXXX
he would have signed the announcement. XXXXX
XXXXX
2. Technically Content-Free Standard XXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXX
This proposed standard contains so little specific information XXXXXX
that it is almost totally useless to anyone attempting to XXXXXXX
implement a key escrow telephone system. The single most XXXXXXX
important motive for a FIPS is to establish a means for XXXXXXX
interoperability among multiple vendors' products. If there is XXXXX
so little information available in the FIPS that no one knows XXXXXXX
how to implement it without a classified contract, then I XXXXXXX
believe this document should not be called a FIPS. XXXXXXX
XXXXXXXXXX
It relies upon specifications of the encryption/decryption XXXXXXX
algorithm (SKIPJACK) and the LEAF Creation Method 1 (LCM-1) XXXXXXX
that are classified. XXXXXXX
XXXXXXX
There is precedent in a very brief FIPS (FIPS_107 on Local Area XXXXXX
Networks), but, in this case, the FIPS references a publicly XXXXXX
available, extensively reviewed and unclassified XXXXXXX
XXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXX
10/01/93 10:58 301 948 1784 NIST CSL 004
Director, Computer Systems Laboratory
September 28, 1993
Page 3
American National/IEEE/ISO Standard (802.3) that gives complete
specifications for implementing that standard.
Anything less than this should be unacceptable as a FIPS.
3. Lack of a Cost-Benefit
The entire key escrow process, as it has been reported in public
over the past six months, seem s to be devoid of any analysis of
what it will cost verses what it will accomplish. Perhaps the
Government has performed such an analysis, but I am unaware of
any indications to that effect.
In the same spirit that I offered my comments on the fundamental
flaws in the NIST proposal to license the Digital Signature
Algorithm to the Public Key Partners Corporation, I now offer
the following relatively superficial analysis of the law
enforcement benefits of key escrow. I hope this simple look
will be augmented by better information from the Administration
that will show that I am wrong in my approach and/or
conclusions.
If one estimates the number of telephone security devices that
may be in use in the U.S. in the next ten years, one must
acknowledge that, for the most part, the general public will not
spend the extra money to protect its routine phone calls from an
unforeseen threat. Business will probably purchase these devices
for their executives but not bother for the bulk of their
routine transactions. As a result, I estimate that,
optimistically, as many as ten percent (10%) of the public
phones in the U.S. may be protected with security devices in the
next ten years. Given that the Administration has assured us
that the public will not be prohibited from using alternative
encryption systems, when one considers how many of these devices
will be key escrow devices, one must take into account already
available competing devices such as the AT&T proprietary 3600s
and the Cylink DES devices which do not use key escrow
procedures. I estimate that of the installed devices, no more
than fifty percent (50%) will be key escrowed devices in the
next ten years.
The number of Title III wiretaps that take place in a given year
is approximately 4,000 ( the number of court ordered wiretaps is
approximately 800 times an average of 5 physical taps per court
order). If my estimate of the number of key escrow phone
devices is accurate and those estimates represent the population
of phones that the law enforcement authorities expect to encounter
when placing a wiretap, then we should see approximately 200
actual key escrowed phone taps in any given year or
approximately 16 per month; 1 every 2 days or so. This is
hardly enough to justify all the key escrow administrative
expenses.
Unfortunately, the estimates of five percent (5%) of the U.S.
phones having and using key escrow devices is not likely to be
representative of the population of phones that law enforcement
authorities will encounter. Business executives will use key
escrow phones, but
10/01/93 10:58 301 9481784 NIST CSL
Director, Computer Systems Laboratory
September 28, 1993
Page 4
those that do not want their calls monitored by anyone will
chose devices that are not subject to key escrow. So even the
optimistic numbers cited above are probably overly optimistic.
One cannot avoid commenting that it appears the key escrow
agents will no doubt make the Maytag repair man look like a
beehive of activity.
I recognize that there may be an EES II on the way that will
extend key escrow to computer communications and perhaps
increase the activity of the key escrow agents. On the other
hand, presumably any Title III wiretaps of computer
communications are already included in the estimated 4,00
wiretaps per year, so perhaps no.
And for this, how much will it cost to operate the key escrow
process? Does anyone know?
I offer the above admittedly superficial analysis in the hope
that the Administration will be forth coming with better
document estimates to justify why it is so intent on proceeding
so quickly down the key escrow path. I fear that the proposed
EES is just a symptom of a process that seems out of control.
One can only hope that the President's Interagency review of
cryptography, that is expected to reach its conclusions soon,
will recognize that there really is no need to proceed at such
great speed and that the Administration and the public will be
much better served by using a somewhat accelerated FIPS process,
that makes use of public technical input, in establishing the
U.S. public telephone security policy for the next twenty or
thirty years.
Slow down and look at the alternatives! We cannot afford not
to!
Sincerely,
Stephen T. Walker
cc: John Podesta
10/01/93 10:59 301 948 1784 NIST CSL 0007
THE DEPARTMENT OF COMMERCE
WASHINGTON, DC 20230
November 14, 1988
MEMORANDUM TO THE HEADS OF EXECUTIVE DEPARTMENTS AND AGENCIES
SUBJECT: Procedures for Waivers for the Federal Information Processing
Standards (FIPS)
Under Section 111(d) of the Federal Property and Administrative
Services Act of 1949 (40 U.S.C. 759(d)) as amended by the
Computer Security Act of 1987, I am authorized to approve
standards for Federal computer systems, and to determine the
extent to which such standards, which are issued as Federal
Information Processing Standards (FIPS), should be compulsory
and binding.
It has been necessary from time to time to waive the use of
these compulsory FIPS when compliance would adversely affect the
accomplishment of an agency's mission or cause a major adverse
financial impact on the agency which is not offset by
Governmentwide savings. For some previously issued FIPS, I have
already delegated to the heads of agencies the authority to
waive the standards under certain conditions. However, for
other FIPS I have retained the waiver authority.
The provisions of the Computer Security Act of 1987 clarify the
conditions for the delegation of waiver authority to the heads
of departments and agencies. I think that these officials are
best able to make the decisions about the impact of standards on
agency mission and costs, and the efficiency of Government
operations would be improved if these officials had the
authority to waive standards when necessary.
Therefore, I hereby delegate to you the authority to waive,
under the conditions specified in the attached procedures,
XXXXXXXXXXXXXXXXXXXXXXXXX subsequent FIPS that are compulsory
XXXXXXXXXXXXXXXXXXXXXXXXX the acquisitions and management of
XXXXXXXXXXXXXXXXXXXXXXXXX communications systems. You may
XXX hand written XXXX only to a senior official designated
XXX note withheld XXXX ) of title 44 of the U.S. Code. The
XXX "lawyer-client" XXXX se previously issued mandatory FIPS
XXX privilege by NIST XXXX
XXX Dept. Of Commerce XXX
XXXXXXXXXXXXXXXXXXXXXXXXX regarding this change, please contact
XXXXXXXXXXXXXXXXXXXXXXXXX 4 Technology Building; National
XXXXXXXXXXXXXXXXXXXXXXXXX Technology; Gaithersburg, MD 20899.
C. William Verity
Secretary of Commerce
Attachment
cc: Agency Senior Mgmt Officials and
Technical Contacts for ADP Stds
Senior Officials for Information
Resource Mgmt
10/01/93 10:59 301 948 1784 NIST CSL 0008
THE DEPARTMENT OF COMMERCE
WASHINGTON, DC 20230
November 14, 1988
MEMORANDUM TO THE HEADS OF EXECUTIVE DEPARTMENTS AND AGENCIES
SUBJECT: Procedures for Waivers for the Federal Information Processing
Standards (FIPS)
Under Section 111(d) of the Federal Property and Administrative
Services Act of 1949 (40 U.S.C. 759(d)) as amended by the
Computer Security Act of 1987, I am authorized to approve
standards for Federal computer systems, and to determine the
extent to which such standards, which are issued as Federal
Information Processing Standards (FIPS), should be compulsory
and binding.
It has been necessary from time to time to waive the use of
these compulsory FIPS when compliance would adversely affect the
accomplishment of an agency's mission or cause a major adverse
financial impact on the agency which is not offset by
Governmentwide savings. For some previously issued FIPS, I have
already delegated to the heads of agencies the authority to
waive the standards under certain conditions. However, for
other FIPS I have retained the waiver authority.
The provisions of the Computer Security Act of 1987 clarify the
conditions for the delegation of waiver authority to the heads
of departments and agencies. I think that these officials are
best able to make the decisions about the impact of standards on
agency mission and costs, and the efficiency of Government
operations would be improved if these officials had the
authority to waive standards when necessary.
Therefore, I hereby delegate to you the authority to waive,
under the conditions specified in the attached procedures,
previously issued and all subsequent FIPS that are compulsory
for Federal agency use in the acquisitions and management of
computers and related telecommunications systems. You may
redelegate this authority only to a senior official designated
pursuant to section 3506(b) of title 44 of the U.S. Code. The
procedures for waiving these previously issued mandatory FIPS
are attached.
If you have any questions regarding this change, please contact
James H. Burrows, Room B154 Technology Building; National
Institute of Standards and Technology; Gaithersburg, MD 20899.
C. William Verity
Secretary of Commerce
Attachment
cc: Agency Senior Mgmt Officials and
Technical Contacts for ADP Stds
Senior Officials for Information
Resource Mgmt
The Clinton administration has been constantly asking for proof that encryption products from other countries compete with US products. Foreign companies can compete both abroad and in our own domestic market because of the twisted Clinton policies. US companies are forbidden to export. Thus, it should come as no surprise that the Commerce Department maintained its own list of foreign encryption companies. Simply put, they already knew. Attached is a list of such companies and countries forced from the Department of Commerce's own records by Freedom of Information Act:
Company Name Country ---------------------------------------- Eracom Pty Ltd. Austrialia Cryptech Belgium Okio Data Canada Cryptomathic A/S Denmark Computer Elektronik Infosys Gmbh Germany Uti-Maco Software Gmbh Germany Algorithmic Research Ltd Israel Concord-Eracom Nederland Netherlands Philips Netherlands Askri Russia Sonnor Crypto AB Sweden British Telecom UK Business Simulations UK Compuserve UK Computer Security LTD UK Data Innovation LTD UK Dynatech Communications UK International Data Security UK IT Security International UK John Vale UK JPY Associates UK Microexpert UK Microft UK Micronyx UK PC Security UK Plessey Crypto UK Prosoft Limited UK Racal-Guardata UK Software Security UK Sophos LTD UK Sypro UK Zergo UK The following countries have no restrictions on the import of encryption: Belgium Brazil Germany Italy Malaysia Netherlands Spain Sweden Switzerland Taiwan Thailand United Kingdom
All content COPYRIGHT SOFTWAR (C) 2003. Any reproduction or use of content herein must be approved by SOFTWAR.