Comments on the proposed FIPS for Key Exchange and Agreement:
(All of the following were received by e-mail. Comments received in
hardcopy format are not included here.)
==================================================
Date: Wed, 28 May 97 18:11:39 EDT
From: "Douglas A. Gwyn (IST)"
To: keyex@nist.gov
Subject: Re: NIST to Consider Revised Digital Signature Standard for Fede
Any system incorporating "key recovery" facilities is insufficiently
secure. The idea that somehow government has a "right" to monitor
other people's conversations is the antithesis of the principles on
which this nation was founded, and supporters of mandatory key
recovery should be ashamed of themselves.
===========
From: Burt Kaliski
To: "'keyex@nist.gov'"
Subject: Comments on key exchange/agreement FIPS
Date: Mon, 16 Jun 1997 07:18:46 -0700
June 16, 1997
Director, Information Technology Laboratory
Key Agreement/Exchange FIPS
A231 Technology Building
NIST
Gaithersburg, Md. 20899-0001
Dear Director:
Responding to the recent announcement by NIST of its intention to
develop a FIPS for key exchange/agreement, the IEEE P1363 working group,
"Standard for Public-Key Cryptography," would like to convey its support
of this effort and offer its assistance.
The IEEE P1363 project, now in its fourth year, is developing a
comprehensive standard for public-key cryptography, including techniques
from the three major families -- discrete logarithms (of which the
existing Digital Signature Standard is an example), elliptic curves, and
integer factorization (including RSA). The standard also covers the
three major categories of public-key techniques: key agreement, digital
signatures, and public-key encryption. Substantial consensus among
industry participants in the U.S. and abroad has already been achieved
through the development process, making the IEEE P1363 working drafts a
helpful reference for the development of the FIPS.
The IEEE P1363 effort is closely coordinated with the ANSI X9F1
standards, which are also helpful references.
Balloting of the IEEE P1363 standard is currently planned for early
1998. Further information is available on the IEEE P1363 Web page,
http://stdsbbs.ieee.org/groups/1363.
IEEE P1363 applauds NIST's efforts to develop a FIPS for key
exchange/agreement, and will be happy to assist in this effort, by
contributing the IEEE P1363 working drafts as input to the development
process, by reviewing the FIPS, or by other means. Please let me know if
you have any questions.
Sincerely,
Burt Kaliski
Chair, IEEE P1363
===========
Return-receipt-to: blake.greenlee@internetmci.com
Date: Fri, 01 Aug 1997 08:18:16 -0400
From: "M. Blake Greenlee"
Subject: Comments on proposed changes to FIPS 186
To: "'KEYEX@NIST.GOV'"
X-MIME-Autoconverted: from quoted-printable to 8bit by email.nist.gov id
IAA05069
Dear Sirs:
I believe that FIPS 186 should be revised to include ANSI standard key
agreement and key transport standards by reference.
I am particularly concerned that elliptic curve cryptographic techniques
be included. This can easily be done be allowing adoption by reference to
ANSI X9.63. Where NIST may desire to particularize what it wishes to have
the Federal Government use, that may be done easily by reference to the
appropriate sections in the Standard.
As a note, the X9 program of work on public key infrastructure standards
in X9F1 is/has developed a family of standards. Four of these will
directly address key management:
1. X9.42, Management of Symmetric Algorithm Keys Using Diffie-Hellman
(in ballot).
2. X9.44, Management of Symmetric Algorithm Keys Using Reversible Public
Key Cryptography (in preparation; includes RSA)
3. X9.63, Key Agreement and Key Management Using Elliptic Curve-based
cryptography (in preparation)
4. X9.43, Key Archiving and Retrieval (not applicable to FIPS 186)
The changes to FIPS 186 should allow a variety of competitive techniques
either in the public domain (like Diffie Hellman) or for a nominal
license fee. No technology should be included where licenses are not
available on a non-discriminatory basis to implement the technology in
embodiments of the licensee's own choosing.
I note that a major factor in the costs of using cryptography is the
"overhead." Quoting from the Foreword to ANSI X9.62,
"The primary advantage of elliptic curve systems is their apparent high
cryptographic strength relative to key size. The attractiveness of
elliptic curve cryptosystems may increase relative to other public-key
cryptosystems as computing power improvements warrant a general increase
in key size. The shorter key sizes may result in significantly shorter
certificates and system parameters. These potential advantages manifest
themselves in many ways, including storage efficiencies, bandwidth savings
and computational efficiencies. The computational efficiencies may lead in
turn to higher speeds, power efficiency, code size reductions or a
combination thereof.
These potential efficiencies are particularly beneficial in applications
such as:
? high volume transaction systems,
? wireless communications,
? hand-held computing (e.g., personal digital assistants),
? broadcast communications
? smart cards
where bandwidth, processing capacity, power availability or storage are
constrained."
Because of costs, efficiencies and security, I believe that it is in the
best interests of the US Government and the citizens that it serves to
include elliptic curve key agreement and key management techniques in
FIPS 186.
M. Blake Greenlee
M. Blake Greenlee Associates
=============
Date: Fri, 01 Aug 1997 08:51:00 -0400
From: Paul Raines
Subject: Comments on FIPS Federal Register Announcements
To: fips186@nist.gov, keyex@nist.gov
I am writing in response to your Federal Register announcement dtd
5/13/97 which requests comments on NIST's proposed upgrades to the
FIPS 186 standard and developing a new FIPS standard for public key
based cryptographic key agreement and exchange.
I believe it is critical that NIST include in its standards support for both
RSA and Elliptic Curve Cryptography. The former cryptographic
algorithm has gained widespread industry acceptance and is close to
becoming a de facto standard. The latter algorithm has very obvious
technical advantages. Namely, the encryption processes are done much
faster and the smaller key size is ideal for limited bandwidth applications
(e.g. smart cards). It is currently being considered as a standard by
IEEE. For these reasons, I believe NIST should include these algorithms
in any future standards and do so in a way that would be royalty-free to
the public.
For key exchange mechanisms, I believe NIST should examine both the
RSA and Diffie-Hellman methods of exchanging the session encryption
key. For the actual session key algorithm, I feel NIST should give strong
consideration to triple DES as a follow-on to single DES.
If you have any questions about anything I have written or need to
contact me, my phone number is 212-720-7657.
Sincerely,
Paul Raines
Vice President
Electronic Security
Federal Reserve Bank of New York
=============
X-Sender: sergio@exchsvr1.entegrity.com
Date: Thu, 07 Aug 1997 17:48:48 +0200
To: KEYEX@nist.gov
From: Sergio Faissol
Subject: RFC for Key Agreement and Exchange
Cc: john@entegrity.com, dave@entegrity.com
To: Director, Information Technology Laboratory, NIST
Entegrity Solutions Corporation is a software company providing a
comprehensive framework of products and services utilizing strong public
key encryption and digital certificate technology to integrate security
into the global enterprise.
We believe that the new FIPS for Key Agreement and Exchange should include
standards for the use of all major techniques mentioned in your RFC,
especially the new Elliptic Curve Cryptosystems. In our view, this
technology has the highest strength-per-bit of any public-key cryptographic
technique available today. We are planning to use this technology in
products targeting several environments, including smart cards,
authentication products, and electronic commerce related applications.
Open competition of several strong cryptographic algorithms is critical to
perpetuating a competitive market in these technologies. ECC appears to be
among the most competitive of these technologies and should be included.
We further advocate that any truly secure data system will require the use
of hardware based cryptography. In order to meet this requirement in a
cost-effective way we need to be able to provide hardware solutions that
are fast, small and inexpensive. It has been demonstrated in prototype
environments that ECC can provide significant advantages in this area.
Regards,
Sergio Faissol Voice: +1 (408) 487-8600 x112
V.P. Worldwide Product Development FAX: +1 (408) 487-8610
Entegrity Solutions Corp. E-mail: sergio@entegrity.com
2077 Gateway Pl, Suite 200 http://www.entegrity.com
San Jose, CA 95110 USA
===========
From: john.purcell@gsa.gov
Date: 11 Aug 97 12:36:00 (-0400)
Subject: Comments on FR Vol. 62, No. 92 (Digital Signature Standard)
To: fips186@nist.gov, judith.spencer@gsa.gov, stanley.choffrey@gsa.gov
Attached herewith are the comments of the Center for Governmentwide
Security on the Federal Register notice (Vol. 62, No. 92), regarding
the Digital Signature Standard. The format is Microsoft Word.
-- John Purcell
for Judith A. Spencer
Director, Center for Governmentwide Security
COMMENTS IN RESPONSE TO NOTICES IN FEDERAL REGISTER VOL. 62, NO. 92,
ANNOUNCING PLANS TO DEVELOP A FEDERAL INFORMATION PROCESSING STANDARD
FOR PUBLIC-KEY BASED CRYPTOGRAPHIC KEY AGREEMENT AND EXCHANGE
-- RIN 0693-ZA10
AND
ANNOUNCING PLANS TO REVISE FEDERAL INFORMATION PROCESSING STANDARD 186,
DIGITAL SIGNATURE STANDARD -- RIN 0693-2A11
The two notices are so closely related in the development of the Federal
Security Infrastructure by this office, that we are combining our comments
on the two notices.
In our development effort, we are using vendor products which comply
with Federal Information Processing Standard 186, (and other FIPS)
with regard to the Digital Signature Standard, the Digital Signature
Algorithm, the Secure Hash Algorithm, and the Data Encryption Standard.
In doing so, we are relying on the minimum standards for security as
published by the National Institute of Standards and Technology,
Department of Commerce, pursuant to the Computer Security Act of 1987.
At this time, we see no reason to change our approach, even if the
FIPS 186 is modifired to incorporate other algorithms.
We do wish to comment on the special needs for security in systems
which are intended to transfer funds. We point out that these systems
may require security algorithms stronger than those systems which only
convey normal message traffic. Of course, information that is
particularly sensitive may require the same security level as is needed
by systems that convey funds.
We are aware that the customer community is already using algorithms
other than those specified in the FIPS. Since interoperability of
the algorithms is essential for the usability of the cryptographic
products, we are especially concerned that an immediate, high-level
effort be mounted to ensure this interoperability.
Thank you for the opportunity to comment.
===========
To: Keyex@nist.gov
Date: Mon, 11 Aug 1997 12:47:25 -0400
Subject: Key Agreement/Exchange FIPS
>From Dr. Scott Vanstone
(See attached file: KeyAgreement.doc)
August 11, 1997
Director, Information Technology Laboratory
Attn: Key Agreement/Exchange FIPS
Certicom supports NIST"s initiative to develop a FIPS which addresses
the key agreement and key exchange issue. Currently the IEEE P1363 and
ANSIX9.63 draft standards have incorporated key exchange techniques (in
fact, X9.63 addresses only this issue). As is well known, key agreement
and key exchange are crucial components in any secure data exchange.
Efficient techniques to perform this task are needed and they must perform
well even on the most constrained platforms. In order to meet the demands
of the wireless, smart card and various other environments Certicom
encourages NIST to adopt elliptic curve technology as the underlying
algebraic structure for the protocols. Furthermore, Certicom encourages
NIST to adopt similar protocols for key agreement as currently being
drafted for ANSI X9.63. In particular, the one and two pass versions of
the MQV provides a fully authenticated Diffie-Hellman key agreement with
a minimum of bandwidth overhead. This protocol when performed in the
elliptic curve setting is ideally suited to many constrained environments
which would have a difficult time supporting any other key agreement protocol.
Certicom has filed for patent protection on the MQV protocol. Certicom's
licensing policy is public knowledge and MQV has been made available to
ANSI X9.63 on a royalty free basis provided it is used for financial
applications. As for the unified model for Diffie-Hellman, this protocol
was proposed and is being supported by IBM. Certicom has no knowledge of
the patent status of this protocol with respect to IBM or any other
organization.
Dr. Scott Vanstone
Certicom Corp.
Chief Cryptographer
===========
Date: Mon, 11 Aug 1997 14:46:12 -0400
From: Thierry Moreau <"Thierry Moreau"@hawksbill.nist.gov>
Reply-To: Thierry.Moreau@connotech.com
Organization: CONNOTECH Experts-conseils Inc./Montreal/Quebec/Canada
To: KEYEX@nist.gov
Subject: Comment on key exchange
ATTN: Director, Information Technology Laboratory,
Subject: Key Agreement/Exchange FIPS
Dear Sirs,
please find enclosed a comment on "Federal Information Processing
Standard for Public-Key Based Cryptographic Key Agreement and Exchange".
The attachement is formatted using the HTML format. If this format
creates difficulties with processing of the comment, please indicate
your choice for alternate format, among 1) WordPerfect 6.x, 2) Word for
Windows, 3) plain ASCII, and I will be glad to re-submit the attachment
accordingly.
[ASCII included for this file - NIST]
Yours Truly,
Thierry Moreau
Probabilistic Encryption Key Exchange
(Comment on Plans to Develop a FIP Standard for Public-Key Based
Cryptographic Key Agreement and Exchange)
August 11th, 1997
by Thierry Moreau,
CONNOTECH Experts-conseils Inc.
------------
Introduction
------------
Probabilistic Encryption Key Exchange (PEKE) [1] was invented as a secret
key establishment method to be plug-in compatible, protocol-wise, with
the Diffie-Hellman key exchange [2]. In fact, PEKE happens to be applicable
in other circumstances as well.
In this document, we first present a taxonomy of secret key exchange
mechanisms, in order to position PEKE in relation with other schemes. Then,
we present the security foundation of PEKE, which is shared with Annex A
of ISO /IEC 9796 when the public exponent is 2 [3] [4].
Last, we mention the patent pending rights that CONNOTECH Experts-conseils
has over the PEKE cryptosystem in Canada.
-------------------------------------------------
A taxonomy of secret key establishment protocols
-------------------------------------------------
Secret key establishment protocols may be classified according to a number
of criteria, derived from application requirements or implementation
issues. In all cases, a fresh secret key is established from pre-existing
conditions.
----------------------------------------------------------
Type of key established by the scheme under consideration
----------------------------------------------------------
The secret key established may be used as a short term session key
between two entities directly linked in a protocol exchange, or as
a longer term key used e.g. in a store and forward system.
Originally, PEKE was disclosed for session key establishment with
direct protocol involvement of both entities. But closer examination
of the PEKE two-message protocol reveals that the first message may
be generated and/or sent on behalf of the "initiating entity" instead
of by the initiating entity, with only a slight decrease in security
(specifically, the essential protection against chosen ciphertext
attack remains when PEKE is used in a store-and-forward scheme). So,
PEKE can be used in store-and-forward applications.
----------------------------------
Number-theoretic public parameters
----------------------------------
In discrete logarithm systems, the number-theoretic public parameters
are generally common to a group of entities and subject to complete
public scrutiny. In this case, the private component of a private/public
key pair is just a secret random number (as in the Lein Harn's
authentication improvement of the Diffie-Hellman scheme, see [5]). In
the case of one-way trapdoor cryptosystems, the number-theoretic public
parameter is specific to one entity. The issues of trust in the
implementation of the number-theoretic parameter selection vary accordingly.
PEKE falls in the latter category, where a number-theoretic private/public
key pair is associated with one of the two entities participating in the
secret key exchange.
---------------------------
Authentication capabilities
---------------------------
In a secret key exchange protocol, one party may or may not get
cryptographic assurance that the remote party is one which knows the
private counterpart of a public key used in the computations. This
authentication capability is independent in each direction of the secret
key establishment protocol. The "certification" of the public key is
an important related issue.
PEKE offers a one-way authentication capability.
---------------------------------
Local secure computing facilities
---------------------------------
We can distinguish the following computing facilities as being critical
for some secret key establishment schemes, but not always trivially procured:
* a secure memory for storing a long-term secret,
* a truly random source for locally generating random secret values,
* sufficient processing power for 1) a small number of multiply-reduce
cycles, 2) a full modular exponentiation (that is a much larger number
of multiply-reduce cycles), 3) the computation of the modular inverse,
and 4) the capability to pre-compute a number of intermediate results
in advance of subsequent instances of the secret key exchange protocol.
For instance, the Diffie-Hellman cryptosystem requires a truly random
source and sufficient processing power for a full modular exponentiation,
and may benefit from the capability to pre-compute intermediate results.
Any entity which is authenticated in a key exchange protocol requires a
secure memory for storing a long term secret. Whenever a secure memory
is available, a truly random source may be provided by a
cryptographic-strength pseudo-random number generator of which the
internal state is kept in the secure memory.
The PEKE cryptosystem has un-balanced requirements. The low-processing
end of the transaction requires a truly random source and sufficient
processing power for a small number of multiply-reduce cycles. The higher
processing end of the transaction requires a secure memory, and sufficient
processing power for a full modular exponentiation. The random source
used by the higher processing end need not be of cryptographic strength.
--------------------------------------
Resistance to failure of random source
--------------------------------------
There are various attack scenarios that can exploit weaknesses in a
random source used in secret key establishment protocol. For instance,
a vulnerability to replay attacks may occur if an adversary is able to
force a constant output from a random source. Another worrisome weakness
is a too small set of possible outcomes of the random source process.
Any secret key establishment protocol that is to ensure uniqueness of
the generated secret key requires at least two messages.
An instance of the PEKE secret key establishment protocol may encompass
one or two message transmissions. When two message transmissions are used,
uniqueness of the generated secret key is ensured. In addition, a failure
of one party's random source is not noticeable by a third party who
oversees the protocol exchange. This last property occurs in a single
direction, that is when the random source failure occurs in the
low-processing end of the transaction (recall that PEKE has unbalanced
processing requirements).
----------------------------------
Accomodation of key escrow schemes
----------------------------------
Ideally, the "granularity" of key escrow mechanisms associated with a
secret key exchange scheme should reflect the balance of conflicting
interests of the parties involved. Actually, the foremost secret key
exchange schemes are at the two opposite ends of the granularity scale
(unless modified for key escrow purposes): the Diffie-Hellman scheme has
the smallest granularity (each generated secret key must be individually
escrowed), and the one-way trapdoor cryptosystems has the coarsest
granularity (the entity's private key being escrowed, all secret-keys
generated with the corresponding public key can be recovered at once).
PEKE is like one-way trapdoor cryptosystems with respect of accomodation
of key escrow schemes.
---------------------------
Security foundation of PEKE
---------------------------
The PEKE security foundation is the "x^2 mod N" one-way trapdoor function
where N is the product of two prime numbers "congruent to 3 modulo 4".
The first author to suggest the use of this particular formulation is
Hugh C. Williams [6]. But this is now usually referred to as the Rabin
public key cryptosystem (used for both encryption and digital signatures)
[7]. Blum Blum and Shub independently published a pioneer article on the
mathematical properties of this "x² mod N" primitive [8], and Blum
and Goldwasser documented an efficient probabilistic encryption scheme
from this work [9].
The security foundation of the "x^2 mod N" one-way trapdoor function
is used by an international standard on digital signatures, [3] [4].
There are two difficulties with the application of the "x^2 mod N"
primitive to practical cryptographic schemes. One is the threat of
chosen ciphertext attack, where the possessor of the private key is
repeatedly probed with ciphertext to decrypt and returns (part of) the
corresponding cleartext. While the RSA primitive so far has resisted
public cryptanalysis attempts with respect to the chosen ciphertext
attack, the "x^2 mod N" primitive is known to be vulnerable to it. The
other difficulty is the fact that the "x^2 mod N" function is a 4:1
mapping that creates ambiguity.
In practical proposals, the chosen ciphertext attack is prevented by
introducing redundancy in the input (cleartext) to the "x^2 mod N"
function, and mandating the possessor of the private key to hide any
cleartext devoid of the redundancy (e.g. [10], page 9, lines 16-28).
PEKE works according to this principle.
Resolving the 4:1 ambiguity in the "x^2 mod N" function is more an
operational concern than a security issue, and diverse solutions has
been proposed (e.g. [11], [12], [13]).
-------------
Patent Issues
-------------
A patent application has been filed in Canada for PEKE [14]. This patent
application has been laid open to the public on September 23, 1995. No
patent application had been filed outside of Canada for PEKE by or on
behalf of the inventor or assignee in the Canadian patent application.
--------------------
For more information
--------------------
On-line Internet documentation http://www.connotech.com/pekemap.htm
Electronic mail: info@connotech.com
CONNOTECH Experts-conseils Inc.
9130 Place de Montgolfier
Montreal, Quebec, Canada, H2M 2A1
Tel.: +1-514-385-5691 Fax: +1-514-385-5900
----------
References
----------
[1] Moreau, Thierry, Probabilistic Encryption Key Exchange, Electronics
Letters, Vol. 31, number 25, 7th December 1995, pp 2166-2168
[2] Diffie, Bailey Whitfield, Hellman, Martin E., New Directions in
Cryptography, IEEE Transactions in Information Theory, vol IT-22, 1976,
pp 644-654
[3] ISO/IEC 9796:1991, Information Technology - Security Techniques -
Digital Signature Scheme Giving Message Recovery
[4] Guillou, Louis Claude, Quisquater, Jean-Jacques, Walker, Mike,
Landrock, Peter, and Shaer, Caroline, Precautions taken against various
potential attacks in ISO/IEC DIS 9796 'Digital signature scheme giving
message recovery', Advances in Cryptology, Eurocrypt'90, Lecture Notes
In Computer Science no. 473, pp 465-473
[5] Harn, Lein, Digital signature for Diffie-Hellman keys without
using a one-way function, Electronics Letters, 16th January 1997,
Vol 33, No 2, pp125-126
[6] Williams, Hugh C., A Modification of RSA Public-Key Encryption,
IEEE Transactions on Information Theory, Vol IT-26, no. 6, November
1980, pp 726-729
[7] Rabin, M.O., Digital Signatures and Public Key Functions as
Intractable as Factorization, MIT Laboratory for computer science,
TR 212, January 1979, pp 1-16
[8] Blum, Leonore, Blum, Manuel, and Shub, M., A Simple Unpredictable
Pseudo-random Number Generator, SIAM Journal of Computing, vol. 15,
no. 2, May 1986, pp 364-383
[9] Blum, Manuel, and Goldwasser, Shafi, An Efficient Probabilistic
Public-key Encryption Scheme which Hides All Partial Information,
In Advances in Cryptology: Proceedings of Crypto'84, Springer-Verlag,
1985, pp 289-299
[10] USA patent document 5,406,628, Beller, Michael J., Yacobi, Yacov,
Public Key Authentication and Key Agreement for Low-cost Terminals,
April 11, 1995 (application number 101,437, August 2, 1993)
[11] Lieberherr, Karl, Uniform Complexity and Digital Signatures,
Theoretical Computer Science, Vol. 16 (1981), pp 99-110
[12] Harn, Lein, and Kiesler, T., Improved Rabin's Scheme with High
Efficiency, Electronics Letters, Vol. 25, no. 11, May 25th, 1989,
pp 726-728 (see also erratum published in Electronics Letters, Vol. 25,
no. 15, page 1016)
[13] Shimada, M., Another Practical Public-Key Cryptosystem,
Electronic Letters, Vol. 28, no. 23, November 5th, 1992, pp 2146
[14] Moreau, Thierry, Apparatus and Method for Cryptographic System Users
to Obtain a Jointly Determined, Secret, Shared, and Unique Bit String,
Canadian patent application number 2,156,780, filed on August 23, 1995,
laid-open to the public on September 23, 1995, CONNOTECH Experts-conseils
Inc., Montréal, Canada
----------
[ CONNOTECH home page: http://www.connotech.com/ | about us | web editorial
policy | e-mail to: info@connotech.com ]
CONNOTECH Experts-conseils Inc.
9130 Place de Montgolfier
Montreal, Quebec, Canada, H2M 2A1
Tel.: +1-514-385-5691 Fax: +1-514-385-5900
=============
Date: Mon, 11 Aug 1997 15:35:44 -0400
From: Mike
X-Mailer: Mozilla 2.01KIT (Win16; U)
MIME-Version: 1.0
To: keyex@nist.gov
CC: John.Michael.Williams@Computer.org
Subject: Include Elliptic Curve Cryptography
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: a5373e36914f373dd8adad5268bbbf3a
As a consultant in information security, I strongly recommend the NIST be
inclusive in its consideration of Key Agreement/Exchange standards, and
in particular, the ANSI X9 ECC standards.
John Michael Williams
6210 Leeke Forest Court
Bethesda MD 20817
===========
X-Sender: lee.k.stanton@postoffice.worldnet.att.net
Date: Mon, 11 Aug 1997 15:45:05 -0400
To: KEYEX@nist.gov
From: Lee Stanton
Subject: Key Agreement/Exchange FIPS
Cc: cgriffis@v-one.com, cbrook@v-one.com, KNewcomer@v-one.com
Director, Information Technology Laboratory
National Institute of Standards, & Technology
Gaithersburg, MD 20899
V-ONE Corporation, a vendor of data security products that provide security
solutions to both private industry and government users, both in the US and
abroad, respectfully offers these comments on the proposed Key
Agreement/Exchange Standard.
V-ONE's products primarily support communications security, particularly
Internet/Intranet TCP/IP protocols. As markets develop for additional
product areas, we expect to offer solutions in the areas of Electronic
Commerce document and messaging security as well. V-ONE is a member of the
National Computer Security Association Cryptographic Products Consortium
with particular interest in the Virtual Private Networks area.
Key Agreement is an area that may not be ready for standardization. Many
techniques for key exchange are still being tested and evaluated. New
methods are being invented and old ways have become suspect.
Diffie-Hellman, for example, has been subject to "man in the middle"
attacks that may or may not jeopardize the reliability of the algorithm.
Since patent protection for the algorithm is just running out, it becomes
freely available, and thus very attractive for implementation.
V-ONE uses a proprietary approach that provides equally reliable results at
very low overhead while simultaneously offering strong user authentication.
Thus, the key agreement technology is only part of the protocol of
establishing a connection. V-ONE would like the option of employing the
best possible solution for the application at hand. Elliptic Curve and RSA
techniques are clearly desirable alternatives, but a standard may not be
helpful in selecting the best solution for a particular application. If a
standard is necessary for PK based key agreement, it should certainly allow
the three alternative systems, but hopefully would also allow alternative
mechanisms as they become available and qualified.
Since key agreement is between two parties on a dynamic basis and does not
need to necessarily be compatible between multiple other parties, it seems
that the need for a standard in this area is unnecessary.
A number of other areas in the security technology area may be more needful
of standards, such as the quality or entropy in random number generation or
the quality of random numbers and primes. Measures of quality are
completely lacking. Perhaps efforts could be redirected into this badly
needed tecnology.
Lee K. Stanton, Consultant
V-ONE Corporation
20250 Century Boulevard, Suite 300
Germantown, MD 20874
(301) 515-5200
(301) 515-5280 (FAX)
===========
From: Burt Kaliski
To: "'keyex@nist.gov'"
Subject: Comments on key exchange/agreement FIPS
Date: Mon, 11 Aug 1997 13:19:45 -0700
August 11, 1997
Director, Information Technology Laboratory
Key Agreement/Exchange FIPS
A231 Technology Building
NIST
Gaithersburg, Md. 20899-0001
Dear Director:
RSA Laboratories is pleased to note NIST's announcement that it is
planning to develop a Federal Information Processing Standard for
Public-Key Based Cryptographic Key Agreement and Exchange. This
announcement is very timely, and we would like to offer some comments in
support of the effort.
(These comments reflect the position of RSA Laboratories and RSA Data
Security, of which RSA Laboratories is a division; they are independent
of those the author submitted earlier this summer as chair of IEEE
P1363.)
NIST's plan to develop a FIPS for key agreement and exchange is an
important step in promoting information security in industry and
government alike. The intention expressed in the announcement to offer
government users a choice between techniques such as RSA,
Diffie-Hellman, and elliptic-curve algorithms provides a degree of
flexibility that will encourage further implementation of security
techniques, making security the central issue, not just the choice of
algorithm.
There are a great number of choices to be made in the process, however,
especially as there many different key agreement and exchange
algorithms, and presumably the FIPS cannot specify every one of them.
Moreover, each key agreement and exchange algorithm has many
implementation options. The challenge to NIST, then, is to determine
which choices to support.
A number of choices remain to be made:
* Which key agreement/exchange primitives (i.e., which underlying
mathematical operations)? There are the RSA primitive, the
Diffie-Hellman primitive, and the elliptic curve analog of
Diffie-Hellman, as well as the new MQV primitives, among others.
* Which choices of arithmetic? RSA and Diffie-Hellman are both based on
modular arithmetic. Elliptic-curve key agreement algorithms can be based
either on modular arithmetic alone, or a combination of modular
arithmetic and arithmetic over a characteristic-2 finite field. Within
the choice of characteristic-2 arithmetic, there is a further issue of
finite field representation (polynomial vs. normal basis).
* Which key sizes? For many reasons a range of key sizes is useful to
have in a standard. Related to this, the size of the subgroup in which
operations are performed (akin to the size of the prime q in DSA) may
need to be defined for the Diffie-Hellman and elliptic curve algorithms.
The question of elliptic-curve key sizes is a particularly interesting
one, given their promise of shorter key sizes and what some consider to
be a relatively small level of experience in the open research community
with elliptic curve cryptanalysis. We would be interested on NIST's
process of developing confidence here, as with the other algorithms.
* Which auxiliary functions? Key agreement algorithms often involve an
additional step of processing an agreed-upon secret numeric value to
derive a key, and likewise key transport algorithms based on public-key
encryption may involve some "encoding" of the key into a numeric value
prior to encryption. Key derivation functions and encoding techniques
are thus also choices that need to be made.
The fact that there are many choices to be made should not be viewed as
an obstacle to standardization, but rather as an opportunity for an
optimal outcome. NIST need not be limited to a few candidate algorithms,
but rather has great flexibility. Each choice has its own benefits, and
NIST can make choices that best reflect the needs of both commerce and
government.
NIST's choices are important, as they lend an endorsement to technology
on a global scale, not just for the U.S. government. We encourage NIST
to consider the options broadly and conservatively.
Some other comments:
1. Regarding the issue of encryption capability mentioned in the request
for comments:
> Any algorithms proposed for digital signature must be able
> to be implemented such that they do not support encryption unless keys
> used for encryption are distinct from those used for signature and are
> recoverable.
Typical approaches for digital signatures have this property when the
digital signature algorithm is implemented with a required hash-function
step. While it is true that some digital signature primitives alone may
provide encryption capability (including DSA variants and their elliptic
curve analogues as well as RSA), any such primitive can be combined with
a hash function to eliminate unintended use as an encryption function.
2. Regarding patents:
> Comments are particularly sought with respect to the RSA, Diffie-
>Hellman, and elliptic curve techniques. In addition, parties believing
>their patents or other intellectual property pertain to any of these
>three techniques are asked to comment and provide specifics of the
>nature of their claims.
RSA Data Security is exclusive licensee of U.S. Patent No. 4,405,829,
which covers digital signatures based on the RSA algorithm. A sample
open patent license is available from RSA Data Security. RSA Data
Security supports the ANSI patent license policy.
RSA Laboratories looks forward to further participation in the
development and review of the proposed FIPS. Thank you for this
opportunity to comment.
Sincerely,
Burton S. Kaliski Jr., Ph.D.
Chief Scientist
RSA Laboratories
20 Crosby Drive
Bedford, MA 01730
(617) 687-7057
(617) 687-7019 (fax)
burt@rsa.com
===========
From: William_Binzel@mastercard.com
X-Authentication-Warning: pur1: Host mcnpur41.mastercard.com claimed
to be mastercard.com
X-Lotus-FromDomain: MASTERCARD
To: keyex@nist.gov
Date: Mon, 11 Aug 1997 18:53:41 -0400
Subject: FIPS - Public Key Agreement and Exchange -- Comments
Subject: Announcing Plans to Develop a Federal Information Processing
Standard for Public-Key Based Cryptographic Key Agreement and Exchange
Solicited Comments:
MasterCard International supports the development of a Federal Information
Processing Standard for public-key key agreement and exchange. A FIPS in
this discipline may assist in the adoption of public-key based systems in a
wider range of existing and new applications and may result in some federal
agencies migrating to advanced public-key based systems.
MasterCard supports the inclusion in the FIPS of protocols that are covered
in the drafts of X9.63 and X9.44 developed within the ANSI ASC X9F1 working
group.
MasterCard appreciates the opportunity to comment on this announcement. If
you have any questions about these comments or MasterCard International's
support of this effort, please feel free to contact me.
Sincerely,
William P. Binzel
Vice President
Government Relations
MasterCard International
===========
X-Sender: dpj@world.std.com
Date: Mon, 11 Aug 1997 22:56:18 -0400
To: KEYEX@nist.gov
From: David Jablon
Subject: Comments on RFC: Key Agreement/Exchange FIPS
Cc: David Jablon , Miles Smid
Director, Information Technology Laboratory
ATTN: Key Agreement/Exchange FIPS
Technology Building, Room A231
National Institute of Standards and Technology
Gaithersburg, MD 20899
Comments on RFC: Key Agreement/Exchange FIPS
--------------------------------------------
Prepared by:
David P. Jablon
Integrity Sciences, Inc.
August 11, 1997
Introduction
------------
For the past 20 years, many public-key techniques have been
developed to provide a diverse set of benefits for secure
computing systems. As NIST develops a FIPS for Public-Key
Based Cryptographic Key Agreement and Exchange, we urge you
to consider the widest range of techniques that leverage
public-key functions for secure key agreement. The many
aspects of human/computer interaction demand a variety of
approaches, and public-key techniques are crucial for solving
many of these problems. This memo focuses on a specific class
of these public key agreement techniques that use standard
public key agreement functions to protect low-entropy shared
secrets in the process of authentication.
This response has been created by Integrity Sciences, a
consulting firm and developer of computer security technology.
Some specific methods in the class of methods described
in this memo have been developed by our company, and we are
working to encourage the widespread application of this entire
class of important techniques within the industry.
The problem
-----------
Several long-standing difficult problems in computer security
are related to addressing limitations of human behavior, and
in particular, the problem of how to safely and reliably
identify and authenticate a live human presence with an
electronic mechanism. One important element in authentication
is "something you know", which is typically represented by a
PIN, password, or passphrase. For simplicity, we refer to this
element as a "password". The password element has a chronic
problem: It is often difficult to guarantee that the chosen
word, phrase, or number has sufficient entropy to resist brute-
force attack, especially when the password is used as a
cryptographic key.
Public-key based solutions
--------------------------
A class of public-key exchange techniques has been developed
over the past seven years to directly address this limitation
of memorized passwords. These methods use public key techniques
to remotely prove knowledge of a potentially small secret
password, without revealing that secret to any party. A
crucial difference between these techniques and classical
techniques for password verification is that with these new
techniques, even small elements are not exposed to brute-force
attacks on the network messages. These methods are preferable
to earlier alternatives since they do not use the password as
an encryption key, at least not where there is any verifiable
plaintext which could permit a dictionary attack. Another
distinction is that these methods do not even require a
deployed public-key infrastructure or certificate hierarchy.
There are at least two basic forms of these password-
authenticated public-key exchange methods. In a basic form,
a common shared secret is used on both sides of the connection.
In an extended form, one party holds a verifier for the secret,
which is constructed as a one-way function of the secret. In
extended methods, this verifier is exactly analogous to a
public-key, with one important exception: Distribution of
this verifier should be restricted to limit the exposure of
the verifier to brute-force attack. This is required if one
wants to fully protect a password of low or uncertain entropy.
Despite this limitation, many of the remaining benefits of the
public-key exchange process remain intact.
Typical methods
---------------
Several methods in this general class have been developed.
The first methods developed included the EKE protocols [BM92],
and the "secret public key" protocols [Gong93, Gong95].
More recent work has analyzed and refined these methods
[STW95, Pat97], and created several alternative methods
including SPEKE [Jab96] and OKE [Luc97]. The class of
extended methods includes at least A-EKE [BM94], B-SPEKE
[Jab97], and SRP-2 [Wu97].
The P1363 effort
----------------
At least one of these methods has been submitted to the IEEE
P1363 committee and is under review for inclusion in this
standard [P1363] for public-key methods. Integrity Sciences has
participated in the P1363 effort to insure that these methods
and the closely related Diffie-Hellman key agreement methods
are standardized in an appropriate manner, and are safe against
a variety of cryptanalytic attacks. In particular, the
subgroup confinement problem of Diffie-Hellman is relevant to
some of these methods, and the safeguards in P1363 are
specifically designed to prevent this problem.
Convergence with classical public-key exchange
----------------------------------------------
With a suitably large and random password, certain extended
password-authenticated key exchange protocols provide the exact
same benefits as a dual Diffie-Hellman key agreement, with some
extra added protection. In the primary D-H exchange, the
password serves as a long-term private key for authentication,
the verifier serves as the corresponding long-term public key,
and the secondary D-H exchange uses ephemeral keys to guarantee
perfect forward secrecy. Special modifications are incorporated
to give additional protection to the long-term private key,
just in case the entropy of this key is smaller than expected.
This optimization makes the method superior in all cases to an
ordinary dual D-H exchange. In particular the B-SPEKE method
is a form of dual Diffie-Hellman exchange, and is one that is
specifically designed to permit elliptic curve implementations.
Patents
-------
As a class, many (but not all) of these methods appear covered
by patents for the DH-EKE and A-EKE methods. It is possible
that other still-pending patents will eventually cover some
of the other alternatives. In any case, there appears to be
no single patent holder with a monopoly position in these
methods, so there is assurance that the competitive situation
will be considerably more open than past experience with the
original public-key patents might lead us to believe.
I encourage NIST to consider the use of patented techniques,
with a reasonable license policy, to be acceptable,
especially in the situations where two unrelated patent
licensors can provide functionally equivalent methods.
Conclusion
----------
These methods are very important since many of the classical
approaches to password authentication have failed to address
the problems of passwords with insufficient or indeterminate
randomness. This particularly human problem remains, despite
many years of attempting to educate and therefore improve
human behavior. It is well-accepted that multi-factor
authentication is important for strong security, and that
these factors should remain as independent as possible for
maximum security. Password-based key agreement methods are
important for providing an independent factor in multi-factor
systems. As passwords remain one of the essential ingredients
in personal authentication, we believe it is essential to
include the important class of password-based public-key
agreement techniques within the FIPS on Public Key Agreement
and Exchange.
References
----------
[BM92] S. M. Bellovin and M. Merritt, "Encrypted Key Exchange:
Password-Based Protocols Secure Against Dictionary Attacks",
Proceedings of the I.E.E.E. Symposium on Research in Security
and Privacy, Oakland, May 1992.
[BM94] S. M. Bellovin and M. Merritt, "Augmented Encrypted Key
Exchange: a Password-Based Protocol Secure Against Dictionary
Attacks and Password File Compromise", AT&T Bell Laboratories
(c. 1994).
[GLNS93] L. Gong, M. Lomas, R. Needham, & J. Saltzer,
"Protecting Poorly Chosen Secrets from Guessing Attacks",
I.E.E.E. Journal on Selected Areas in Communications,
Vol. 11, No. 5, June 1993, pp. 648-656.
[Jab96] D. Jablon, "Strong Password-Only Authenticated Key
Exchange", Computer Communication Review, vol. 26, no. 5,
pp. 5-26, October 1996.
[Jab97] D. Jablon, "Extended Password Methods Immune to Dictionary
Attack", Proceedings of the WETICE '97 Enterprise Security Workshop,
Cambridge, MA, June 18-20, 1997. Also at
[Luc97] S. Lucks, "Open Key Exchange: How to Defeat Dictionary
Attacks Without Encrypting Public Keys", Proceedings of the
Security Protocol Workshop '97, Springer-Verlag, April 7-9,
1997.
[Pat97] S. Patel, "Number Theoretic Attacks on Secure Password
Schemes", Proceedings of the 1997 IEEE Symposium on Security
and Privacy, May 5-7, 1997.
[P1363] IEEE P1363 working group, "IEEE P1363 Working Draft --
Standards for Public-key Cryptography", This document is
currently available at:
[STW95] M. Steiner, G. Tsudik, and M. Waidner, "Refinement and
Extension of Encrypted Key Exchange", Operating Systems Review,
vol. 29, Iss. 3, pp. 22-30 (July 1995).
[Wu97] Tom Wu, "The Secure Remote Password Protocol",
Stanford University, July 21, 1997. Pending publication,
this is available at
===========
From: Scott Schnell
To: "'keyex@nist.gov'"
Subject: Additional RSA comments on Key Agreement / Exchange FIPS
Date: Mon, 11 Aug 1997 20:27:20 -0700
August 11, 1997
Director, Information Technology Laboratory
Key Agreement/Exchange FIPS
A231 Technology Building
NIST
Gaithersburg, Md. 20899-0001
Dear Director:
We at RSA Data Security, a major supplier of cryptographic security
products and toolkits, are pleased by the announcement that NIST is
planning to develop a Federal Information Processing Standard for
Public-Key Based Cryptographic Key Agreement and Exchange. RSA
encourages this effort and believes that the government and commercial
use of cryptography will be enhanced by this initiative.
By authoring a FIPS that includes industry standards such as RSA and
Diffie-Hellman, NIST will both provide flexibility in algorithm choice
and accelerate the use of commercially successful products employing
public key techniques in both the commercial and government sectors.
However, the inclusion of several different key agreement and exchange
schemes will require specific implementation options and algorithm
choices that NIST will need to determine and define. As the industry
leader in cryptographic security technology and software toolkits, we
urge you to factor in the following items in your decision-making
process.
Firstly, we are encouraged that the RSA algorithm is being considered
for inclusion in this new FIPS. Its status as the de facto algorithm
of choice in practically every security standard for commercial use of
cryptography today has given us and others a substantial history and
confidence in RSA and commercially applied key lengths as a basis for
sound policy.
Secondly, the recommendation of RSA is that the current limited
expertise and understanding of elliptic curve cryptosystems (ECC)
represents a significant risk for today's data security applications.
In protecting valuable data with cryptography, we are relying on the
proven strength of a mathematical technique. In industry and
cryptographic academia, the trust in this strength is typically earned
over years of intensive study. Surprises can never wholly be ruled
out, and only by studying a problem closely from many different
perspectives can we hope that unforeseen advances are less likely.
Our input to the FIPS process is that this immaturity in the state of
ECC science warrants substantial caution in including this technology
in a FIPS, as it will likely prompt short term deployment. If
included, it should be on an exploratory basis. Many of the world's
top cryptographers and cryptanalysts share this view, and we present
excerpts of their comments below for your review.
Lastly, considerable work remains to fully understand the appropriate
choices to be made between the variants of ECC technology. We have
observed that the success or failure of a variety of standards over
the years has often revolved around both selecting theoretically and
empirically proven technologies, and also in implementing these in an
"industry standard" way such that each implementation is compliant
with others. It is RSA's view that elliptic curve cryptosystem
variants are not well or broadly understood, that several of these
incorporate vastly different options and implementation choices, and
that incompatibility risks warrant further study prior to choices
being made on a national or worldwide scale.
Sincerely,
Scott T. Schnell
Vice President of Marketing
RSA Data Security Inc.
Comments from noted cryptographers and cryptanalysts:
"It is true that 160-bit elliptic curve cryptosystems may offer some
advantages compared to 1024-bit RSA: smaller keys, less communication,
storage, and faster computation. But if I would have to make a choice
today between the two, purely based on perceived security, I would opt
for 1024-bit RSA. The elliptic curve discrete logarithm problem has
been around for a relatively short amount of time. In my opinion only
relatively few people have looked at it. Therefore, we cannot yet feel
sufficiently confident, where it should be noted that even marginal
progress could have very damaging consequences for the security of
160-bit elliptic curve cryptosystems. Thus, right now I think it would
not be prudent to switch from 1024-bit RSA to 160-bit elliptic curve
cryptosystems."
Dr. Arjen K. Lenstra
VP, Emerging Technologies, Corporate Technology Office
Citibank, N.A.
"Major systems must be based on security technology that meets
performance and functionality needs, while leaving little to chance in
how well the technology is understood and trusted. The RSA public key
cryptosystem meets these needs elegantly, providing superior
performance in the most often used scenarios like signature
verification, and by being supported by a robust body of research and
cryptanalytic results. Elliptic curve technology is interesting,
perhaps a little newer than factoring or discrete logs, but needs more
study and analysis before it is mature."
Dr. Taher ElGamal
Chief Scientist
Netscape Communications Corp.
"The discrete logarithm problem for elliptic curves is something that
is fairly new. Very little research has been done on this problem.
There is one specific result by Menezes and Vanstone, STOC 91. It
gives a subexponential algorithm for discrete logarithms in
supersingular elliptic curves. This suggests that the general problem
is of a similar nature as the discrete log modulo primes p (i.e. in
the multiplicative group mod p) and the problem of factoring integers.
However we do not know subexponential algorithms for all elliptic
curves. In the cases we know subexponential algorithms, they are
somewhat less efficient than those for factoring integers.
"From what we know now, it looks as if the discrete logarithm problem
for elliptic curves is somewhat harder than the discrete logarithm
modulo primes p which itself looks a bit harder than factoring
integers. But it is unreasonable to assume that it has straight
exponential complexity.
"A very particular case are elliptic curves in fields of powers of 2.
They have been proposed since there the arithmetic is quite efficient.
This particular choice seems to be risky. There are only a few fields
that can be used. If the discrete logarithm problem collapses for
these particular fields it nearly collapses for all elliptic curves of
this type."
Dr. Claus P. Schnorr
Professor of Mathematics and Computer Science
University of Frankfurt a.M.
"Elliptic curves show promise as an alternative basis on which to
implement public-key cryptography. They are a plausible "back-up" to
RSA in case should someone discover a fast integer factorization
algorithm. And in some applications their apparent ability to utilize
smaller public keys might be of interest.
"But the security of cryptosystems based on elliptic curves is not
well understood, due in large part to the abstruse nature of elliptic
curves. Few cryptographers understand elliptic curves, so there is
not the same widespread understanding and consensus concerning the
security of elliptic curves that RSA enjoys. Over time, this may
change, but for now trying to get an evaluation of the security of an
elliptic-curve cryptosystem is a bit like trying to get an evaluation
of some recently discovered Chaldean poetry. Until elliptic curves
have been further studied and evaluated, I would advise against
fielding any large-scale applications based on them.
"In the end, time will tell how well they stand up to attack."
Dr. Ronald L. Rivest
Founder
RSA Data Security
"It is correct that I am suspicious of elliptic curve cryptosystems.
I have never heard an argument which persuaded me that there were
reasons in principle for believing that the discrete logarithm problem
on elliptic curves is strictly exponential. I suspect that the lack of
a sub-exponential algorithm is merely a matter of neglect and that
intense scrutiny - which a commercial implementation of an elliptic
curve cryptosystem might engender - could readily change the
situation. I am fortified in this opinion by the fact that the
Jacobians of hyperelliptic curves (elliptic curves are a special case
of hyperelliptic curves) were also suggested for cryptography and
their presumed complexity was based on the same arguments used for
elliptic curves. Nonetheless Ming-Deh Huang, Jonathan DeMarrais and I
[1] were able to show that for `high genus' hyperelliptic curves a
subexponential algorithm does exist. I believe that it would be
imprudent to base the security of a cryptosystem on the assumption
that an exponential time algorithm is required for the elliptic curve
problem."
[1] Leonard M. Adleman, Jonathan DeMarrais and Ming-Deh Huang ``A
subexponential algorithm for discrete logarithms in the rational
subgroup of the Jacobian of a hyperelliptic curve over a finite
field''. Proceedings of the 1994 Algorithmic Number Theory Symposium
Eds. L.M. Adleman and M-D. Huang. Springer-Verlag Lecture Notes In
Computer Science, 877: 28-40. 1994.
Dr. Leonard M. Adleman
Henry Salvatori Professor of Computer Science
University of Southern California
"The public-key cryptosystem of choice for a Public-Key Infrastructure
(PKI) is RSA because of its very fast digital signature verification
and public-key encryption operations. The competitors to RSA are
systems based on the discrete logarithm problem, such as DSA,
Diffie-Hellman, and the elliptic curve variants of DSA and
Diffie-Hellman. These schemes are competitive with RSA on speed of
digital signature generation and private-key decryption, but are up to
two orders of magnitude slower at digital signature verification and
public-key encryption.
"The importance of the speed of signature verification and public-key
encryption can be seen from the way that cryptography is used in a
PKI. Consider the example of secure email. An email is signed just
once, but that signature must be verified by each recipient.
Certificates and revocation lists are signed once by a Certification
Authority (CA), but are typically verified many thousands of times. A
full-scale PKI will have multiple cross-certified CAs requiring end
user software to verify multiple certificates and revocation lists to
complete a single transaction. When encrypting email, the symmetric
key used to encrypt the email contents must be individually encrypted
for each recipient so that many public-key encryptions must be
performed to send a single email. These operations are quite fast
when using RSA, but are much slower when using DSA, Diffie-Hellman, or
their elliptic curve variants.
"The main advantage that elliptic curve cryptography has over other
public-key algorithms is that its digital signatures and encrypted
symmetric keys are shorter. This is not important for most
applications on PCs, but there are other applications where this can
be important. Elliptic curve operations can also be implemented fairly
compactly in custom silicon.
"Public-Key Infrastructures should be flexible enough to handle the
full range of popular public-key algorithms available. Currently, RSA
is the most widely used, and this is likely to continue to be the case
due to its advantages of fast digital signature verification and fast
public-key encryption."
Dr. Michael J. Wiener
Senior Cryptologist
Entrust Technologies
"Recent work carried out at Royal Holloway, University of London
indicates that with current technology, and anticipated technology
advances, RSA at 706 bits may be required by 2006 to resist attack.
"While one can never rule out the possibility of a mathematical
breakthrough, and hence should support the concept of 'algorithm
agility', the analysis referenced above suggests, and I believe, that
1024 bit RSA will continue to be considered secure for many years to
come."
Dr. Henry Beker
Chairman and Chief Executive
Zergo, plc
===========
X-Sender: jim.brandt@postoffice.worldnet.att.net
Date: Tue, 12 Aug 1997 15:58:08 -0400
To: FIPS186@nist.gov, KEYEX@nist.gov
From: James Brandt
Subject: NIST Response
Cc: npiazzola@verisiggn.com, jbrandt@verisign.com
Director, Information Technology Laboratory
ATTN: Planned Revision to FIPS 186
Technology Building, Room A231
National Institute of Standards and Technology
Gaithersburg, MD 20899
VeriSign supports the Government's initiatives to revise the Federal
Information Processing Standard (FIPS) 186 Digital Signature Standard, and
to develop a new FIPS for Public-Key Based Cryptographic Key Agreement and
Exchange. In particular, we support the recommendation to incorporate the
RSA algorithm within the revised/new FIPS in order to faciltate a more
rapid expansion and use of available secure electronic commerce and
communications technology by Federal departments and agencies.
As you are already aware, the RSA technology has been adopted as
the de facto industry standard with over 80 million products shipped
worldwide. These products provide industry, government, and private
citizens the ability to securely and reliably conduct business, government,
and personal transactions on the Internet easily, efficiently, and at
low cost. Although there are many useful applications that have already
been pioneered using the RSA security technology, secure web browsing
(SSL 2/3) and secure mail (S/MIME) are probably the two most important
that could have significant near-term benefit, particularly within government.
VeriSign has worked extensively with Netscape, Microsoft and
other leading electronic commerce vendors to seamlessly integrate their
secure browser and mail applications with VeriSign's public key
infrastructure (PKI) for ubiquitous certificate management and directory
services. These commercial security applications, in conjunction with
VeriSign's PKI, use the RSA digital signature and key exchange algorithms
to provide the security services of authentication, data integrity,
non-repudiation, and privacy. The current FIPS 186 compliant DSS
algorithm has not been adopted on nearly as wide a scale as has the RSA
technology. Failure of wide spread DSS support within commercial security
applications has also inhibited the support of DSS by commercial PKI
service providers. As a result, most government agencies are left with
the unpleasant alternatives to either develop their own custom application
and PKI support infrastructure, skirt the FIPS by declaring their project
as "pilot" or file a formal waiver in order to take advantage of RSA based
commercial security products and PKI services, or delay/postpone
implementation. All of these alternatives result in unnecessary cost,
inefficiencies, and schedule delay to important re-engineering initiatives
that could substantially reduce the cost and improve productivity in the
way government agencies operate internally, interact together and with
their industry partners, and provide service to the public.
VeriSign agrees with the government that the privacy of a User's
signature key should always be maintained and not be divulged to a third
party. We further agree there are legitimate business and public safety
concerns that justify the use of techniques to support the recovery of
encrypted data when access to the User's private encryption key is neither
possible or practical. However, these two requirements do not necessarily
result in the need to mandate two distinct public/private key pairs (and
digital certificates), one for signature and the other for key exchange.
A single public/private key pair (and digital certificate) should be
permitted at all times, even when "key recovery" is a requirement, since
most techniques provide for recovery of the session key without requiring
access to the private key used for both signature and key exchange functions.
We appreciate the opportunity to comment on the government's proposed
strategy to expand the existing FIPS. We fully concur that the RSA
algorithm should be included in a revised FIPS 186 and also be included in
a new FIPS for key agreement and exchange, and believe it should be quickly
adopted. In so doing, we believe many Federal agencies and departments
will be enabled to move forward to implement important re-engineering
initiatives that have the potential to significantly reduce the cost of
government operations while at the same time improve the efficiency and
robustness of its services.
/s/
Nicholas Piazzola
V.P. Federal Markets
VeriSign, Inc