4202016 NIST SP 800-12, Chapter 19httpfas.orgirpdod.docx

4/20/2016 NIST SP 800-12, Chapter 19
http://fas.org/irp/doddir/other/nist-800-12/chapter19.htm 1/9
Chapter 19
CRYPTOGRAPHY
Cryptography is a branch of mathematics based on the
transformation of data. It provides an important tool for
protecting information and is used in many aspects of computer
security. For example, cryptography can help
provide data confidentiality, integrity, electronic signatures,
and advanced user authentication. Although modern
cryptography relies upon advanced mathematics, users can reap
its benefits without understanding its mathematical
underpinnings.
This chapter describes cryptography as a tool for satisfying a
wide spectrum of computer security needs and
requirements. It describes fundamental aspects of the basic
cryptographic technologies and some specific ways
cryptography can be applied to improve security. The chapter
also explores some of the important issues that
should be considered when incorporating cryptography into
computer systems.
19.1 Basic Cryptographic Technologies

Cryptography relies upon two basic components: an algorithm
(or cryptographic methodology) and a key. In
modern cryptographic systems, algorithms are complex
mathematical formulae and keys are strings of bits. For two
parties to communicate, they must use the same algorithm (or
algorithms that are designed to work together). In
some cases, they must also use the same key. Many
cryptographic keys must be kept secret; sometimes algorithms
are also kept secret.
There are two basic types of cryptography: secret key systems
(also called symmetric systems) and public key
systems (also called asymmetric systems). Table 19.1 compares
some of the distinct features of secret and public
key systems. Both types of systems offer advantages and
disadvantages. Often, the two are combined to form a
hybrid system to exploit the strengths of each type. To
determine which type of cryptography best meets its needs,
an organization first has to identify its security requirements
and operating environment.
19.1.1 Secret Key Cryptography
In secret key cryptography, two (or more) parties share the same
key, and that key is used to encrypt and decrypt
data. As the name implies, secret key cryptography relies on
keeping the key secret. If the key is compromised, the
security offered by cryptography is severely reduced or
eliminated. Secret key cryptography assumes that the
parties who share a key rely upon each other not to disclose the
key and protect it against modification.
The best known secret key system is the Data Encryption
Standard (DES), published by NIST as Federal
Information Processing Standard (FIPS) 46-2. Although the

adequacy of DES has at times been questioned, these
claims remain unsubstantiated, and DES remains strong. It is
the most widely accepted, publicly available
cryptographic system today. The American National Standards
Institute (ANSI) has adopted DES as the basis for
encryption, integrity, access control, and key management
standards.
The Escrowed Encryption Standard, published as FIPS 185, also
makes use of a secret key system. (See the
http://fas.org/irp/doddir/other/nist-800-12/index.html
4/20/2016 NIST SP 800-12, Chapter 19
discussion of Key Escrow Encryption in this chapter.)
19.1.2 Public Key Cryptography
Whereas secret key cryptography uses a single key shared by
two (or more) parties, public key cryptography uses a
pair of keys for each party. One of the keys of the pair is
"public" and the other is "private." The public key can be
made known to other parties; the private key must be kept
confidential and must be known only to its owner. Both
keys, however, need to be protected against modification.
Public key cryptography is particularly useful when the parties
wishing to communicate cannot rely upon each
other or do not share a common key. There are several public
key cryptographic systems. One of the first public key
systems is RSA, which can provide many different security
services. The Digital Signature Standard (DSS),

described later in the chapter, is another example of a public
key system.
19.1.3 Hybrid Cryptographic Systems
Public and secret key cryptography have relative advantages and
disadvantages. Although public key cryptography
does not require users to share a common key, secret key
cryptography is much faster: equivalent implementations
of secret key cryptography can run 1,000 to 10,000 times faster
than public key cryptography.
To maximize the advantages and minimize the disadvantages of
both secret and public key cryptography, a
computer system can use both types in a complementary
manner, with each performing different functions.
Typically, the speed advantage of secret key cryptography
means that it is used for encrypting data. Public key
cryptography is used for applications that are less demanding to
a computer system's resources, such as encrypting
the keys used by secret key cryptography (for distribution) or to
sign messages.
19.1.4 Key Escrow
Because cryptography can provide extremely strong encryption,
it can thwart the government's efforts to lawfully
perform electronic surveillance. For example, if strong
cryptography is used to encrypt a phone conversation, a
court-authorized wiretap will not be effective. To meet the
needs of the government and to provide privacy, the
federal government has adopted voluntary key escrow
cryptography. This technology allows the use of strong
encryption, but also allows the government when legally
authorized to obtain decryption keys held by escrow
agents. NIST has published the Escrowed Encryption Standard

as FIPS 185. Under the Federal Government's
voluntary key escrow initiative, the decryption keys are split
into parts and given to separate escrow authorities.
Access to one part of the key does not help decrypt the data;
both keys must be obtained.
19.2 Uses of Cryptography
Cryptography is used to protect data both inside and outside the
boundaries of a computer system. Outside the
computer system, cryptography is sometimes the only way to
protect data. While in a computer system, data is
normally protected with logical and physical access controls
(perhaps supplemented by cryptography). However,
when in transit across communications lines or resident on
someone else's computer, data cannot be protected by
the originator's logical or physical access controls.
Cryptography provides a solution by protecting data even when
the data is no longer in the control of the originator.
19.2.1 Data Encryption
One of the best ways to obtain cost-effective data
confidentiality is through the use of encryption. Encryption
transforms intelligible data, called plaintext, into an
unintelligible form, called ciphertext. This process is reversed
through the process of decryption. Once data is encrypted, the
ciphertext does not have to be protected against
disclosure. However, if ciphertext is modified, it will not
decrypt correctly.
Both secret key and public key cryptography can be used for
data encryption although not all public key algorithms
provide for data encryption.

4/20/2016 NIST SP 800-12, Chapter 19
To use a secret key algorithm, data is encrypted using a key.
The same key must be used to decrypt the data.
When public key cryptography is used for encryption, any party
may use any other party's public key to encrypt a
message; however, only the party with the corresponding
private key can decrypt, and thus read, the message.
Since secret key encryption is typically much faster, it is
normally used for encrypting larger amounts of data.
19.2.2 Integrity
In computer systems, it is not always possible for humans to
scan information to determine if data has been erased,
added, or modified. Even if scanning were possible, the
individual may have no way of knowing what the correct
data should be. For example, "do" may be changed to "do not,"
or $1,000 may be changed to $10,000. It is
therefore desirable to have an automated means of detecting
both intentional and unintentional modifications of
data.
While error detecting codes have long been used in
communications protocols (e.g., parity bits), these are more
effective in detecting (and correcting) unintentional
modifications. They can be defeated by adversaries.
Cryptography can effectively detect both intentional and
unintentional modification; however, cryptography does
not protect files from being modified. Both secret key and
public key cryptography can be used to ensure integrity.

Although newer public key methods may offer more flexibility
than the older secret key method, secret key
integrity verification systems have been successfully integrated
into many applications.
When secret key cryptography is used, a message authentication
code (MAC) is calculated from and appended to
the data. To verify that the data has not been modified at a later
time, any party with access to the correct secret key
can recalculate the MAC. The new MAC is compared with the
original MAC, and if they are identical, the verifier
has confidence that the data has not been modified by an
unauthorized party. FIPS 113, Computer Data
Authentication, specifies a standard technique for calculating a
MAC for integrity verification.
Public key cryptography verifies integrity by using of public
key signatures and secure hashes. A secure hash
algorithm is used to create a message digest. The message
digest, called a hash, is a short form of the message that
changes if the message is modified. The hash is then signed
with a private key. Anyone can recalculate the hash and
use the corresponding public key to verify the integrity of the
message.
19.2.3 Electronic Signatures
Today's computer systems store and process increasing numbers
of paper-based documents in electronic form.
Having documents in electronic form permits rapid processing
and transmission and improves overall efficiency.
However, approval of a paper document has traditionally been
indicated by a written signature. What is needed,
therefore, is the electronic equivalent of a written signature that
can be recognized as having the same legal status
as a written signature. In addition to the integrity protections,

discussed above, cryptography can provide a means
of linking a document with a particular person, as is done with a
written signature. Electronic signatures can use
either secret key or public key cryptography; however, public
key methods are generally easier to use.
Cryptographic signatures provide extremely strong proof that a
message has not been altered and was signed by a
specific key. However, there are other mechanisms besides
cryptographic-based electronic signatures that perform a
similar function. These mechanisms provide some assurance of
the origin of a message, some verification of the
message's integrity, or both.
• Examination of the transmission path of a message. When
messages are sent across a network, such as the
Internet, the message source and the physical path of the
message are recorded as a part of the message. These can
be examined electronically or manually to help ascertain the
origin of a message.
• Use of a value-added network provider. If two or more parties
are communicating via a third party network, the
network provider may be able to provide assurance that
messages originate from a given source and have not been
modified.
• Acknowledgment statements. The recipient of an electronic
message may confirm the message's origin and
4/20/2016 NIST SP 800-12, Chapter 19

contents by sending back an acknowledgement statement.
• Use of audit trails. Audit trails can track the sending of
messages and their contents for later reference.
Simply taking a digital picture of a written signature does not
provide adequate security. Such a digitized written
signature could easily be copied from one electronic document
to another with no way to determine whether it is
legitimate. Electronic signatures, on the other hand, are unique
to the message being signed and will not verify if
they are copied to another document.
19.2.3.1 Secret Key Electronic Signatures
An electronic signature can be implemented using secret key
message authentication codes (MACs). For example,
if two parties share a secret key, and one party receives data
with a MAC that is correctly verified using the shared
key, that party may assume that the other party signed the data.
This assumes, however, that the two parties trust
each other. Thus, through the use of a MAC, in addition to data
integrity, a form of electronic signature is obtained.
Using additional controls, such as key notarization and key
attributes, it is possible to provide an electronic
signature even if the two parties do not trust each other.
19.2.3.2 Public Key Electronic Signatures
Another type of electronic signature called a digital signature is
implemented using public key cryptography. Data
is electronically signed by applying the originator's private key
to the data. (The exact mathematical process for
doing this is not important for this discussion.) To increase the
speed of the process, the private key is applied to a
shorter form of the data, called a "hash" or "message digest,"

rather than to the entire set of data. The resulting
digital signature can be stored or transmitted along with the
data. The signature can be verified by any party using
the public key of the signer. This feature is very useful, for
example, when distributing signed copies of virus-free
software. Any recipient can verify that the program remains
virus-free. If the signature verifies properly, then the
verifier has confidence that the data was not modified after
being signed and that the owner of the public key was
the signer.
NIST has published standards for a digital signature and a
secure hash for use by the federal government in FIPS
186, Digital Signature Standard and FIPS 180, Secure Hash
Standard.
19.2.4 User Authentication
Cryptography can increase security in user authentication
techniques. As discussed in Chapter 16, cryptography is
the basis for several advanced authentication methods. Instead
of communicating passwords over an open network,
authentication can be performed by demonstrating knowledge of
a cryptographic key. Using these methods, a one-
time password, which is not susceptible to eavesdropping, can
be used. User authentication can use either secret or
public key cryptography.
19.3 Implementation Issues
This section explores several important issues that should be
considered when using (e.g., designing, implementing,
integrating) cryptography in a computer system.
19.3.1 Selecting Design and Implementation Standards

NIST and other organizations have developed numerous
standards for designing, implementing, and using
cryptography and for integrating it into automated systems. By
using these standards, organizations can reduce
costs and protect their investments in technology. Standards
provide solutions that have been accepted by a wide
community and that have been reviewed by experts in relevant
areas. Standards help ensure interoperability among
different vendors' equipment, thus allowing an organization to
select from among various products in order to find
cost-effective equipment.
Managers and users of computer systems will have to select
among various standards when deciding to use
4/20/2016 NIST SP 800-12, Chapter 19
cryptography. Their selection should be based on cost-
effectiveness analysis, trends in the standard's acceptance,
and interoperability requirements. In addition, each standard
should be carefully analyzed to determine if it is
applicable to the organization and the desired application. For
example, the Data Encryption Standard and the
Escrowed Encryption Standard are both applicable to certain
applications involving communications of data over
commercial modems. Some federal standards are mandatory for
federal computer systems, including DES (FIPS
46-2) and the DSS (FIPS 181).
19.3.2 Deciding on Hardware vs. Software Implementations
The trade-offs among security, cost, simplicity, efficiency, and

ease of implementation need to be studied by
managers acquiring various security products meeting a
standard. Cryptography can be implemented in either
hardware or software. Each has its related costs and benefits.
In general, software is less expensive and slower than hardware,
although for large applications, hardware may be
less expensive. In addition, software may be less secure, since it
is more easily modified or bypassed than
equivalent hardware products. Tamper resistance is usually
considered better in hardware.
In many cases, cryptography is implemented in a hardware
device (e.g., electronic chip, ROM-protected processor)
but is controlled by software. This software requires integrity
protection to ensure that the hardware device is
provided with correct information (i.e., controls, data) and is
not bypassed. Thus, a hybrid solution is generally
provided, even when the basic cryptography is implemented in
hardware. Effective security requires the correct
management of the entire hybrid solution.
19.3.3 Managing Keys
The proper management of cryptographic keys is essential to the
effective use of cryptography for security.
Ultimately, the security of information protected by
cryptography directly depends upon the protection afforded to
keys.
All keys need to be protected against modification, and secret
keys and private keys need protection against
unauthorized disclosure. Key management involves the
procedures and protocols, both manual and automated, used
throughout the entire life cycle of the keys. This includes the
generation, distribution, storage, entry, use,

destruction, and archiving of cryptographic keys.
With secret key cryptography, the secret key(s) should be
securely distributed (i.e., safeguarded against
unauthorized replacement, modification, and disclosure) to the
parties wishing to communicate. Depending upon
the number and location of users, this task may not be trivial.
Automated techniques for generating and distributing
cryptographic keys can ease overhead costs of key management,
but some resources have to be devoted to this task.
FIPS 171, Key Management Using ANSI X9.17, provides key
management solutions for a variety of operational
environments.
Public key cryptography users also have to satisfy certain key
management requirements. For example, since a
private-public key pair is associated with (i.e., generated or
held by) a specific user, it is necessary to bind the
public part of the key pair to the user.
In a small community of users, public keys and their "owners"
can be strongly bound by simply exchanging public
keys (e.g., putting them on a CD-ROM or other media).
However, conducting electronic business on a larger scale,
potentially involving geographically and organizationally
distributed users, necessitates a means for obtaining
public keys electronically with a high degree of confidence in
their integrity and binding to individuals. The
support for the binding between a key and its owner is generally
referred to as a public key infrastructure.
Users also need to be able enter the community of key holders,
generate keys (or have them generated on their
behalf), disseminate public keys, revoke keys (in case, for
example, of compromise of the private key), and change
keys. In addition, it may be necessary to build in time/date

stamping and to archive keys for verification of old
signatures.
19.3.4 Security of Cryptographic Modules
4/20/2016 NIST SP 800-12, Chapter 19
Cryptography is typically implemented in a module of software,
firmware, hardware, or some combination thereof.
This module contains the cryptographic algorithm(s), certain
control parameters, and temporary storage facilities
for the key(s) being used by the algorithm(s). The proper
functioning of the cryptography requires the secure
design, implementation, and use of the cryptographic module.
This includes protecting the module against
tampering.
19.3.5 Applying Cryptography to Networks
The use of cryptography within networking applications often
requires special considerations. In these applications,
the suitability of a cryptographic module may depend on its
capability for handling special requirements imposed
by locally attached communications equipment or by the
network protocols and software.
Encrypted information, MACs, or digital signatures may require
transparent communications protocols or
equipment to avoid being misinterpreted by the communications
equipment or software as control information. It
may be necessary to format the encrypted information, MAC, or
digital signature to ensure that it does not confuse

the communications equipment or software. It is essential that
cryptography satisfy the requirements imposed by
the communications equipment and does not interfere with the
proper and efficient operation of the network.
Data is encrypted on a network using either link or end-to-end
encryption. In general, link encryption is performed
by service providers, such as a data communications provider.
Link encryption encrypts all of the data along a
communications path (e.g., a satellite link, telephone circuit, or
T1 line). Since link encryption also encrypts
routing data, communications nodes need to decrypt the data to
continue routing. End-to-end encryption is
generally performed by the end-user organization. Although
data remains encrypted when being passed through a
network, routing information remains visible. It is possible to
combine both types of encryption.
19.3.6 Complying with Export Rules
The U.S. Government controls the export of cryptographic
implementations. The rules governing export can be
quite complex, since they consider multiple factors. In addition,
cryptography is a rapidly changing field, and rules
may change from time to time. Questions concerning the export
of a particular implementation should be addressed
to appropriate legal counsel.
19.4 Interdependencies
There are many interdependencies among cryptography and
other security controls highlighted in this handbook.
Cryptography both depends on other security safeguards and
assists in providing them.
Physical Security. Physical protection of a cryptographic

module is required to prevent � or at least detect �
physical replacement or modification of the cryptographic
system and the keys within it. In many environments
(e.g., open offices, portable computers), the cryptographic
module itself has to provide the desired levels of
physical security. In other environments (e.g., closed
communications facilities, steel-encased Cash-Issuing
Terminals), a cryptographic module may be safely employed
within a secured facility.
User Authentication. Cryptography can be used both to protect
passwords that are stored in computer systems and
to protect passwords that are communicated between computers.
Furthermore, cryptographic-based authentication
techniques may be used in conjunction with, or in place of,
password-based techniques to provide stronger
authentication of users.
Logical Access Control. In many cases, cryptographic software
may be embedded within a host system, and it may
not be feasible to provide extensive physical protection to the
host system. In these cases, logical access control
may provide a means of isolating the cryptographic software
from other parts of the host system and for protecting
the cryptographic software from tampering and the keys from
replacement or disclosure. The use of such controls
should provide the equivalent of physical protection.
Audit Trails. Cryptography may play a useful role in audit
trails. For example, audit records may need to be signed.
4/20/2016 NIST SP 800-12, Chapter 19

Cryptography may also be needed to protect audit records stored
on computer systems from disclosure or
modification. Audit trails are also used to help support
electronic signatures.
Assurance. Assurance that a cryptographic module is properly
and securely implemented is essential to the
effective use of cryptography. NIST maintains validation
programs for several of its standards for cryptography.
Vendors can have their products validated for conformance to
the standard through a rigorous set of tests. Such
testing provides increased assurance that a module meets stated
standards, and system designers, integrators, and
users can have greater confidence that validated products
conform to accepted standards.
A cryptographic system should be monitored and periodically
audited to ensure that it is satisfying its security
objectives. All parameters associated with correct operation of
the cryptographic system should be reviewed, and
operation of the system itself should be periodically tested and
the results audited. Certain information, such as
secret keys or private keys in public key systems, should not be
subject to audit. However, nonsecret or nonprivate
keys could be used in a simulated audit procedure.
19.5 Cost Considerations
Using cryptography to protect information has both direct and
indirect costs. Cost is determined in part by product
availability; a wide variety of products exist for implementing
cryptography in integrated circuits, add-on boards or
adapters, and stand-alone units.
19.5.1 Direct Costs

The direct costs of cryptography include:
• Acquiring or implementing the cryptographic module and
integrating it into the computer system. The medium
(i.e., hardware, software, firmware, or combination) and various
other issues such as level of security, logical and
physical configuration, and special processing requirements will
have an impact on cost.
• Managing the cryptography and, in particular, managing the
cryptographic keys, which includes key generation,
distribution, archiving, and disposition, as well as security
measures to protect the keys, as appropriate.
19.5.2 Indirect Costs
The indirect costs of cryptography include:
• A decrease in system or network performance, resulting from
the additional overhead of applying cryptographic
protection to stored or communicated data.
• Changes in the way users interact with the system, resulting
from more stringent security enforcement. However,
cryptography can be made nearly transparent to the users so that
the impact is minimal.
References
Alexander, M., ed. "Protecting Data With Secret Codes,"
Infosecurity News. 4(6), 1993. pp. 72-78.
American Bankers Association. American National Standard for
Financial Institution Key Management
(Wholesale). ANSI X9.17-1985. Washington, DC., 1985.

Denning, P., and D. Denning, "The Clipper and Capstone
Encryption Systems." American Scientist. 81(4), 1993.
pp. 319-323.
Diffie, W., and M. Hellman. "New Directions in Cryptography."
IEEE Transactions on Information Theory. Vol. IT-
22, No. 6, November 1976. pp. 644-654.
Duncan, R. "Encryption ABCs." Infosecurity News. 5(2), 1994.
pp. 36-41.
4/20/2016 NIST SP 800-12, Chapter 19
International Organization for Standardization. Information
Processing Systems - Open Systems Interconnection
Reference Model - Part 2: Security Architecture. ISO 7498/2.
1988.
Meyer, C.H., and S. M. Matyas. Cryptography: A New
Dimension in Computer Data Security. New York, NY: John
Wiley & Sons, 1982.
Nechvatal, James. Public-Key Cryptography. Special
Publication 800-2. Gaithersburg, MD: National Institute of
Standards and Technology, April 1991.
National Bureau of Standards. Computer Data Authentication.
Federal Information Processing Standard
Publication 113. May 30, 1985.
National Institute of Standards and Technology. "Advanced

Authentication Technology." Computer Systems
Laboratory Bulletin. November 1991.
National Institute of Standards and Technology. Data
Encryption Standard. Federal Information Processing
Standard Publication 46-2. December 30, 1993.
National Institute of Standards and Technology. "Digital
Signature Standard." Computer Systems Laboratory
Bulletin. January 1993.
National Institute of Standards and Technology. Digital
Signature Standard. Federal Information Processing
Standard Publication 186. May 1994.
National Institute of Standards and Technology. Escrowed
Encryption Standard. Federal Information Processing
Standard Publication 185. 1994.
National Institute of Standards and Technology. Key
Management Using ANSI X9.17. Federal Information
Processing Standard Publication 171. April 27, 1992.
National Institute of Standards and Technology. Secure Hash
Standard. Federal Information Processing Standard
Publication 180. May 11, 1993.
National Institute of Standards and Technology. Security
Requirements for Cryptographic Modules. Federal
Information Processing Standard Publication 140-1. January 11,
1994.
Rivest, R., A. Shamir, and L. Adleman. "A Method for
Obtaining Digital Signatures and Public-Key
Cryptosystems." Communications of the ACM., Vol. 21, No. 2,
1978. pp. 120-126.

Saltman, Roy G., ed. Good Security Practices for Electronic
Commerce, Including Electronic Data interchange.
Special Publication 800-9. Gaithersburg, MD: National Institute
of Standards and Technology. December 1993.
Schneier, B. "A Taxonomy of Encryption Algorithms."
Computer Security Journal. 9(1), 1193. pp. 39-60.
Schneier, B. "Four Crypto Standards." Infosecurity News. 4(2),
1993. pp. 38-39.
Schneier, B. Applied Cryptography: Protocols, Algorithms, and
Source Code in C. New York, NY: John Wiley &
Sons, Inc., 1994.
U.S. Congress, Office of Technology Assessment. "Security
Safeguards and Practices." Defending Secrets, Sharing
Data: New Locks and Keys for Electronic Information.
Washington, DC: 1987, pp. 54-72.
4/20/2016 NIST SP 800-12, Chapter 19
NIST Special Publication 800-133

Recommendation for Cryptographic
Key Generation
Elaine Barker
Allen Roginsky
http://dx.doi.org/10.6028/NIST.SP.800-133
C O M P U T E R S E C U R I T Y
NIST Special Publication 800-133
Recommendation for Cryptographic
Key Generation
Elaine Barker
Allen Roginsky
Computer Security Division
Information Technology Laboratory

December 2012
U.S. Department of Commerce
Rebecca Blank, Acting Secretary
National Institute of Standards and Technology
Patrick D. Gallagher, Under Secretary of Commerce for
Standards and Technology and Director
iii

National Institute of Standards and Technology Special
Publication 800-133
Natl. Inst. Stand. Technol. Spec. Publ. 800-133, 26 pages
(December 2012)
CODEN: NSPUE2
Comments on this publication may be submitted to:
National Institute of Standards and Technology
Attn: Computer Security Division, Information Technology
Laboratory
100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-
8930
Email: [email protected]
Certain commercial entities, equipment, or materials may be
identified in this document in order to
describe an experimental procedure or concept adequately. Such
identification is not intended to imply
recommendation or endorsement by NIST, nor is it intended to

imply that the entities, materials, or
equipment are necessarily the best available for the purpose.
There may be references in this publication to other
publications currently under development by NIST
in accordance with its assigned statutory responsibilities. The
information in this publication, including
concepts and methodologies, may be used by Federal agencies
even before the completion of such
companion publications. Thus, until each publication is
completed, current requirements, guidelines,
and procedures, where they exist, remain operative. For
planning and transition purposes, Federal
agencies may wish to closely follow the development of these
new publications by NIST.
Organizations are encouraged to review all draft publications
during public comment periods and
provide feedback to NIST. All NIST Computer Security
Division publications, other than the ones
noted above, are available at http://csrc.nist.gov/publications.
iv
Reports on Computer Systems Technology
The Information Technology Laboratory (ITL) at the National
Institute of Standards and
Technology (NIST) promotes the U.S. economy and public

welfare by providing technical
leadership for the Nation’s measurement and standards
infrastructure. ITL develops tests, test
methods, reference data, proof of concept implementations, and
technical analyses to advance the
development and productive use of information technology.
ITL’s responsibilities include the
development of management, administrative, technical, and
physical standards and guidelines for
the cost-effective security and privacy of other than national
security-related information in
Federal information systems. The Special Publication 800-series
reports on ITL’s research,
guidelines, and outreach efforts in information system security,
and its collaborative activities
with industry, government, and academic organizations.
Abstract
Cryptography is often used in an information technology
security environment to protect data that
is sensitive, has a high value, or is vulnerable to unauthorized
disclosure or undetected
modification during transmission or while in storage.
Cryptography relies upon two basic
components: an algorithm (or cryptographic methodology) and a
cryptographic key. This
Recommendation discusses the generation of the keys to be
managed and used by the approved
cryptographic algorithms.
Keywords
asymmetric key; key agreement; key derivation; key generation;
key wrapping; key replacement;

key transport; key update; private key; public key; symmetric
key
Acknowledgements
The National Institute of Standards and Technology (NIST)
gratefully acknowledges and
appreciates contributions by Rich Davis of the National
Security Agency and the public and
private sectors whose thoughtful and constructive comments
improved the quality and usefulness
of this publication.
v
Table of Contents
1 Introduction
...............................................................................................
1
2 Authority
...............................................................................................
..... 1
3 Definitions, Acronyms and Symbols
........................................................ 2
3.1
Definitions..............................................................................
.............................. 2
3.2 Acronyms
...............................................................................................
.............. 9

3.3
Symbols..................................................................................
.............................. 9
4 General Discussion
.................................................................................. 10
4.1 Keys to Be Generated
........................................................................................ 10
4.2 Where Keys are Generated
................................................................................ 10
4.3 Supporting a Security Strength
.......................................................................... 10
5 Using the Output of a Random Bit Generator
......................................... 11
6 Generation of Key Pairs for Asymmetric-Key Algorithms
.................... 13
6.1 Key Pairs for Digital Signature Schemes
........................................................... 13
6.2 Key Pairs for Key Establishment
....................................................................... 13
6.3 Distributing the Key Pairs
.................................................................................. 14
7 Generation of Keys for Symmetric-Key Algorithms
.............................. 15
7.1 The “Direct Generation” of Symmetric Keys
.................................................... 15
7.2 Distributing the Generated Symmetric Key
.............................................. 15
7.3 Symmetric Keys Generated Using Key-Agreement Schemes
........................... 16
7.4 Symmetric Keys Derived From a Pre-shared Key
............................................. 17

7.5 Symmetric Keys Derived From Passwords
....................................................... 17
7.6 Symmetric Keys Produced by Combining Multiple Keys and
Other Data ....... 18
7.7 Replacement of Symmetric
Keys....................................................................... 19
Appendix A: References
............................................................................... 20
1
Recommendation for Cryptographic Key Generation
1 Introduction
Cryptography is often used in an information technology
security environment to protect
data that is sensitive, has a high value, or is vulnerable to
unauthorized disclosure or
undetected modification during transmission or while in
storage. Cryptography relies
upon two basic components: an algorithm (or cryptographic
methodology) and a
cryptographic key. The algorithm is a mathematical function,
and the key is a parameter
used by that function.
The National Institute of Standards and Technology (NIST) has
developed a wide variety
of Federal Information Processing Standards (FIPS) and NIST
Special Publications (SPs)
to specify and approve cryptographic algorithms for Federal

government use. In addition,
guidance has been provided on the management of the
cryptographic keys to be used with
these approved cryptographic algorithms.
This Recommendation discusses the generation of the keys to be
used with the approved
cryptographic algorithms. The keys are either generated using
mathematical processing
on the output of approved Random Bit Generators and possibly
other parameters, or
generated based upon keys that are generated in this fashion.
2 Authority
This publication has been developed by the National Institute of
Standards and
Technology (NIST) in furtherance of its statutory
responsibilities under the Federal
Information Security Management Act (FISMA) of 2002, Public
Law 107-347.
NIST is responsible for developing standards and guidelines,
including minimum
requirements, for providing adequate information security for
all agency operations and
assets, but such standards and guidelines shall not apply to
national security systems.
This Recommendation has been prepared for use by federal
agencies. It may be used by
non-governmental organizations on a voluntary basis and is not
subject to copyright.
(Attribution would be appreciated by NIST.)
Nothing in this document should be taken to contradict
standards and guidelines made
mandatory and binding on federal agencies by the Secretary of
Commerce under statutory
authority. Nor should these guidelines be interpreted as altering
or superseding the

existing authorities of the Secretary of Commerce, Director of
the OMB, or any other
federal official.
Conformance to the requirements in this Recommendation are
the responsibility of
entities installing, configuring or using applications or
protocols that incorporate this
Recommendation.
2
3 Definitions, Acronyms and Symbols
3.1 Definitions
Approved FIPS-approved and/or NIST-recommended.
Asymmetric key A cryptographic key used with an asymmetric-
key (public-key)
algorithm. The key may be a private key or a public key.
Asymmetric-key
algorithm
A cryptographic algorithm that uses two related keys, a public
key and a private key. The two keys have the property that
determining the private key from the public key is
computationally infeasible. Also known as a public-key
algorithm.
Bit string An ordered sequence of 0 and 1 bits.

Ciphertext Data in its encrypted form.
Compromise The unauthorized disclosure, modification or use
of sensitive
data (e.g., keying material and other security-related
information).
Cryptographic
algorithm
A well-defined computational procedure that takes variable
inputs, often including a cryptographic key, and produces an
output.
3
Cryptographic key
(key)
A parameter used in conjunction with a cryptographic algorithm
that determines its operation in such a way that an entity with
knowledge of the key can reproduce or reverse the operation,
while an entity without knowledge of the key cannot. Examples
of cryptographic operations requiring the use of cryptographic
keys include:
1. The transformation of plaintext data into ciphertext data,
2. The transformation of ciphertext data into plaintext data,
3. The computation of a digital signature from data,
4. The verification of a digital signature,
5. The computation of an authentication code from data,
6. The verification of an authentication code from data and a

received authentication code,
7. The computation of a shared secret that is used to derive
keying material.
8. The derivation of additional keying material from a key-
derivation key (i.e., a pre-shared key).
Cryptographic module The set of hardware, software, and/or
firmware that implements
security functions (including cryptographic algorithms and key
generation) and is contained within a cryptographic module
boundary. See [FIPS 140].
Cryptographic module
boundary
An explicitly defined perimeter (i.e., the set of hardware,
software and/or firmware) that establishes the boundary of a
cryptographic module. See [FIPS 140].
Cryptoperiod The time span during which a specific key is
authorized for use
or in which the keys for a given system or application may
remain in effect.
Data integrity
A property possessed by data items that have not been altered in
an unauthorized manner since they were created, transmitted or
stored.
Decryption The process of changing ciphertext into plaintext
using a
cryptographic algorithm and key.

4
Digital signature The result of a cryptographic transformation
of data that, when
properly implemented, provides origin authentication, assurance
of data integrity and signatory non-repudiation.
Encryption The process of changing plaintext into ciphertext
using a
cryptographic algorithm and key.
Entity An individual (person), organization, device or process.
Used
interchangeably with “party”.
Entropy
The entropy of a random variable X is a mathematical measure
of the expected amount of information provided by an
observation of X. As such, entropy is always relative to an
observer and his or her knowledge prior to an observation.
Full entropy For the purposes of this Recommendation, an n-bit
string is said
to provide full entropy if the string is obtained through a
process that is estimated to have at least (1−ε)n bits of entropy,
where 0 ≤ ε ≤ 2-64.
Key See cryptographic key.
Key agreement A (pair-wise) key-establishment procedure in
which the
resultant secret keying material is a function of information

contributed by both participants, so that neither party can
predetermine the value of the secret keying material
independently from the contributions of the other party.
Contrast with key transport.
Key-agreement
primitive
A primitive algorithm used in a key-agreement scheme
specified in [SP 800-56A], or in [SP 800-56B].
Key derivation
1. A process by which one or more keys are derived from a
shared secret and other information during a key agreement
transaction.
2. A process that derives new keying material from a key (i.e.,
a key-derivation key) that is currently available.
Key-derivation key
A key used as an input to a key-derivation method to derive
other keys. See [SP 800-108].
Key establishment A procedure that results in secret keying
material that is shared
among different parties.
5
Key-generating
module

A cryptographic module in which a given key is generated.
Key generation The process of generating keys for
cryptography.
Key pair A private key and its corresponding public key; a key
pair is
used with an asymmetric-key (public-key) algorithm.
Key-pair owner The entity that is authorized to use the private
key associated
with a public key, whether that entity generated the key pair
itself or a trusted party generated the key pair for the entity.
Key transport A key-establishment procedure whereby one party
(the sender)
selects a value for the secret keying material and then securely
distributes that value to another party (the receiver) using an
asymmetric algorithm.
Key update A procedure in which a new cryptographic key is
computed as a
function of the (old) cryptographic key that it will replace.
Key wrapping A method of encrypting and decrypting keys and
(possibly)
associated data using a symmetric key; both confidentiality and
integrity protection are provided.
Module See Cryptographic module.
Non-repudiation A service that may be afforded by the
appropriate application of
a digital signature. Non-repudiation refers to the assurance that
the owner of a signature key pair that was capable of generating

an existing signature corresponding to certain data cannot
convincingly deny having signed the data.
Origin authentication A process that provides assurance of the
origin of information
(e.g., by providing assurance of the originator’s identity).
http://en.wikipedia.org/wiki/Key_%28cryptography%29
http://en.wikipedia.org/wiki/Cryptography
6
Owner 1. For an asymmetric key pair, consisting of a private
key and
a public key, the owner is the entity that is authorized to use
the private key associated with a public key, whether that
entity generated the key pair itself or a trusted party
generated the key pair for the entity.
2. For a symmetric key (i.e., a secret key), the entity or
entities
that are authorized to share and use the key.
Party See Entity.
Password A string of characters (letters, numbers and other
symbols) that
are used to authenticate an identity or to verify access
authorization. A passphrase is a special case of a password that
is a sequence of words or other text. In this document, the use
of the term “password' includes this special case.
Permutation An ordered (re)arrangement of the elements of a

(finite) set; a
function that is both a one-to-one and onto mapping of a set to
itself.
Plaintext data In this Recommendation, data that will be
encrypted by an
encryption algorithm or obtained from ciphertext using a
decryption algorithm.
Pre-shared key A secret key that has been established between
the parties who
are authorized to use it by means of some secure method (e.g.,
using a secure manual-distribution process or automated key-
establishment scheme).
7
Private key A cryptographic key used with an asymmetric-key
(public-key)
cryptographic algorithm that is not made public and is uniquely
associated with an entity that is authorized to use it. In an
asymmetric-key cryptosystem, the private key is associated
with a public key. Depending on the algorithm that employs the
private key, it may be used to:
1. Compute the corresponding public key,
2. Compute a digital signature that may be verified using
the corresponding public key,
3. Decrypt data that was encrypted using the corresponding

public key, or
4. Compute a key derivation key, which may then be used
as an input to a key derivation process.
Public key
A cryptographic key used with an asymmetric-key (public-key)
cryptographic algorithm that may be made public and is
associated with a private key and an entity that is authorized to
use that private key. Depending on the algorithm that employs
the public key, it may be used to:
1. Verify a digital signature that is signed by the
corresponding private key,
2. Encrypt data that can be decrypted by the corresponding
private key, or
3. Compute a piece of shared data (i.e., data that is known
only by two or more specific entities).
Public-key algorithm See Asymmetric-key algorithm.
Random Bit Generator
(RBG)
A device or algorithm that outputs bits that are computationally
indistinguishable from bits that are independent and unbiased.
Rekey A procedure in which a new cryptographic key is
generated in a
manner that is independent of the (old) cryptographic key that it
will replace. Contrast with Key update.
Secret key A cryptographic key used by one or more
(authorized) entities

in a symmetric-key cryptographic algorithm; the key is not
made public.
8
Secure channel A path for transferring data between two entities
or components
that ensures confidentiality, integrity and replay protection, as
well as mutual authentication between the entities or
components. The secure channel may be provided using
cryptographic, physical or procedural methods, or a
combination thereof.
Security strength A number associated with the amount of work
(that is, the
number of basic operations of some sort) required to break a
cryptographic algorithm or system. Security strength is often
expressed in bits. If the security strength is S bits, then it is
expected that (roughly) 2S basic operations are required to
break
the algorithm or system.
Shall This term is used to indicate a requirement of a Federal
Information Processing Standard (FIPS) or a requirement that
must be fulfilled to claim conformance to this
Recommendation. Note that shall may be coupled with not to
become shall not.
Shared secret A secret value that has been computed using a
key-
establishment scheme and is used as input to a (single-step) key
derivation function or an extraction-then-expansion procedure

that derives keying material in a two-step process.
Support a security
strength
A term applied to a method (e.g., an RBG, or a key with its
associated cryptographic algorithm) that is capable of providing
(at a minimum) the security strength required or desired for
protecting data.
Symmetric key See Secret key.
Symmetric-key
algorithm
A cryptographic algorithm that uses the same secret key for its
operation and, if applicable, for reversing the effects of the
operation (e.g., an HMAC key for keyed hashing, or an AES
key for encryption and decryption). Also known as a secret-key
algorithm.
Target data The data that is ultimately to be protected (e.g., a
key or other
sensitive data).
9
Trusted Party A party that is trusted by its clients to generate
cryptographic
keys.
3.2 Acronyms

AES Advanced Encryption Standard. See [FIPS 197].
CMAC Cipher-based MAC. See [SP 800-38B].
CTR Counter mode for a block cipher algorithm. See [SP 800-
38A].
DLC Discrete Logarithm Cryptography.
FIPS Federal Information Processing Standard.
HMAC Keyed-Hash Message Authentication Code. See [FIPS
198].
IFC Integer Factorization Cryptography.
KDF Key Derivation Function.
MAC Message Authentication Code.
NIST National Institute of Standards and Technology.
RBG Random Bit Generator.
RSA Rivest-Shamir-Adelman.
SP Special Publication.
3.3 Symbols
Symbol Meaning
⊕ Bit-wise exclusive-or. A mathematical operation that is
defined as:
0 ⊕ 0 = 0,

0 ⊕ 1 = 1,
1 ⊕ 0 = 1, and
1 ⊕ 1 = 0.
|| Concatenation
H(x) A cryptographic hash function with x as an input.
T(x, k) Truncation of the bit string x to the leftmost k bits of x,
where k ≤ the
length of x in bits.
10
4 General Discussion
4.1 Keys to Be Generated
This Recommendation addresses the generation of the
cryptographic keys used in
cryptography. Key generation includes the generation of a key
using the output of a
random bit generator, the derivation of a key from another key,
the derivation of a key
from a password, and key agreement performed by two entities
using an approved key-
agreement scheme. All keys shall be based directly or indirectly
on the output of an
approved Random Bit Generator (RBG). For the purposes of this
Recommendation, keys
that are derived during a key-agreement transaction (see [SP
800-56A] and [SP 800-

56B]), derived from another key using a key derivation function
(see [SP 800-108]) or
derived from a password for storage applications (see [SP 800-
132]) are considered to be
indirectly generated from an RBG, since an ancestor key1 or
random value (e.g., the
random value used to generate a key-agreement key pair) was
obtained directly from the
output of an approved RBG.
Two classes of cryptographic algorithms that require
cryptographic keys have been
approved for Federal government use: asymmetric-key
algorithms and symmetric-key
algorithms. The generation of keys for these algorithm classes
is discussed in Sections 6
and 7.
4.2 Where Keys are Generated
Cryptographic keys shall be generated within FIPS 1402-
compliant cryptographic
modules [FIPS 140]. For explanatory purposes, consider the
cryptographic module in
which a key is generated to be the key-generating module. Any
random value required by
the key-generating module shall be generated within that
module; that is, the RBG (or
portion of the RBG3) that generates the random value shall be
implemented within the
FIPS 140 cryptographic module that generates the key. The
generated keys shall be
transported (when necessary) using secure channels and shall be
used by their associated
cryptographic algorithm within FIPS 140-compliant
cryptographic modules.
4.3 Supporting a Security Strength

A method (e.g., an RBG, or a key and its associated
cryptographic algorithm) supports a
given security strength if the security strength provided by that
method is equal to or
greater than the security strength required for protecting the
target data; the actual
security strength provided can be higher than required.
1 Ancestor key: A key that is used in the generation of another
key. For example, an ancestor key for a key generated
by a key derivation function would be the key-derivation key
used by that key derivation function.
2 “FIPS 140” without a reference to a particular version is
intended to mean the version(s) of the FIPS that are currently
being validated (e.g., FIPS 140-2).
3 The RBG itself might be distributed (e.g., the entropy source
may not co-reside with the algorithm that generates the
(pseudo) random output). See [FIPS 800-90].
http://en.wikipedia.org/wiki/Key_%28cryptography%29
http://en.wikipedia.org/wiki/Cryptography
11
Security strength supported by an RBG: A well-designed RBG
supports a given security
strength if the amount of entropy (i.e., randomness) available in
the RBG is equal to or
greater than that security strength. The security strength
supported depends on the
secrecy of the information designated as the entropy bits and,
when used for the
generation of keys and other secret values, on the secrecy of the

RBG output. For
information regarding the security strength that can be
supported by approved RBGs, see
[SP 800-90].
Security strength supported by an algorithm: Discussions of
cryptographic algorithms
and the security strengths they can support, given certain
choices of parameters and/or
key lengths, are provided in [SP 800-57-1]. The security
strength of a cryptographic
algorithm that uses keys of a certain size (i.e., length) is
assessed under the assumption
that those keys are generated using an approved process that
provides entropy equal to or
greater than the security strength assessed for that algorithm
and key size (where both the
entropy and the security strength are measured in bits).
Security strength supported by a key: The security strength that
can be supported by a key
depends on 1) the algorithm with which it is used, 2) the size of
the key (see [SP 800-57-
1]), 3) the process that generated the key (e.g., the security
strength supported by the
RBG that was used to generate the key), and 4) how the key was
handled (e.g., the
security strength available in the method used to transport the
key)4. The use of such
terms as “security strength supported by a key” or “key supports
a security strength”
assumes that these factors have been taken into account. For
example, if an approved
RBG that supports a security strength of 128 bits has been used
to generate a 128-bit key,
and if (immediately after generation) the key is used with AES-
128 to encrypt target data,
then the key may be said to support a security strength of 128

bits in that encryption
operation (for as long as the key is kept secret).
5 Using the Output of a Random Bit Generator
Random bit strings required for the generation of cryptographic
keys shall be obtained
from the output of an approved Random Bit Generator (RBG);
approved RBGs are
specified in [SP 800-90], [FIPS 186-2], [X9.31] and [X9.62].5
The RBG shall be
instantiated at a security strength that supports the security
strength required to protect
the target data (i.e., the data that will be protected by the
generated keys).
The output of an approved RBG may be used as specified in this
section to obtain either
a symmetric key or the random value needed to generate an
asymmetric key pair.
Asymmetric key pairs require the use of an approved algorithm
for their generation.
4 Note that the security strength that can be supported by a key
is not solely dependent on its length; for example, even
though a 128-bit key is used with AES, an AES operation using
that key can only provide 112 bits of security strength
if the key was generated using an RBG that supports a security
strength of only 112 bits.
5 [SP 800-90] addresses the issues associated with security
strengths, whereas [FIPS 186-2], [X9.31] and [X9.62] do
not. Note that in [SP 800-131A], the use of the RBGs specified
in [FIPS 186-2], [X9.31] and [X9.62] have been
deprecated. Their security strengths may be limited by either
the RBG algorithm or the amount of entropy in the
RBG seed.

12
Examples are those included in [FIPS 186-3] for generating
DSA, ECDSA and RSA
keys. The generation of asymmetric key pairs from a random
value is discussed in
Section 6.
Methods for the generation of symmetric keys are discussed in
Section 7.
Let K be either a symmetric key or the random value to be used
as input to an approved
asymmetric-key pair generation algorithm. K shall be a bit
string value of the following
form:
K = U ⊕ V, (1)
where
• U is a bit string of the desired length that is obtained as the
output of an approved
Random Bit Generator (RBG) that is capable of supporting the
desired security
strength required to protect the target data,
• V is a bit string of the same length as U, and
• The value of V is determined in a manner that is independent
of the value of U
(and vice-versa).

The algorithm with which K will be used, and the security
strength that this usage is
intended to support will determine the required bit length and/or
the minimum security
strength that this process must provide. Since there are no
restrictions on the selection of
V (other than its length and its independence from U), a
conservative approach
necessitates an assumption that the process used to select U
provides most (if not all) of
the required entropy.
The independence requirement on U and V is interpreted in a
computational and a
statistical sense; that is, the computation of U does not depend
on V, the computation of V
does not depend on U, and knowing one of the values (U or V)
must yield no information
that can be used to gain insight into the other value. Assuming
that U is the output of an
approved RBG, the following are examples of independently
selected V values:
1. V is a constant (selected independently from the value of U).
(Note, that if V is a
string of binary zeroes, then K = U, i.e., the output of an
approved RBG.)
2. V is a key obtained using an approved key-derivation method
from a key-
derivation key and other input that is independent of U; see SP
800-108.
3. V is a key that was independently generated in another
cryptographic module. V
was protected using an approved key-wrapping algorithm or
transported using an

approved key transport scheme during subsequent transport.
Upon receipt, the
protection on V is removed within the key-generating module
that generated U
before combining V with U.
4. V is produced by hashing another bit string (V ′) using an
approved hash function
and (if necessary) truncating the result to the appropriate length
before combining
it with U. That is, V = T(H(V ′), k) where T(x, k) denotes the
truncation of bit
string x to its k leftmost bits, and k is the length of U. The bit
string V ′ may be a)
13
a constant; b) a key derived from a shared secret during an
approved key-
agreement scheme between the key-generating module and
another cryptographic
module; or c) a key that was i) independently generated by
another module, ii)
sent using an approved key wrapping algorithm or transported
using an
approved key transport scheme, and iii) upon receipt, the
protection on the key
was removed.
6 Generation of Key Pairs for Asymmetric-Key Algorithms
Asymmetric-key algorithms, also known as public-key
algorithms, require the use of

asymmetric key pairs, consisting of a private key and a
corresponding public key. The
key to be used for each operation depends on the cryptographic
process being performed
(e.g., digital-signature generation or verification). Each
public/private key pair is
associated with only one entity; this entity is known as the key-
pair owner. The public
key may be known by anyone, whereas the private key must be
known and used only by
the key-pair owner. Key pairs shall be generated by:
• The key-pair owner, or
• A Trusted Party that provides the key pair to the owner in a
secure manner. The
Trusted Party must be trusted by all parties that use the public
key.
6.1 Key Pairs for Digital Signature Schemes
Digital signatures are generated on data to provide origin
authentication, assurance of
data integrity or signatory non-repudiation. Digital signatures
are generated by a signer
using a private key, and verified by a receiver using a public
key. The generation of key
pairs for digital signature applications is addressed in [FIPS
186-3] for the DSA, RSA
and ECDSA digital signature algorithms.
A value of K, computed as shown in Section 5, shall be used to
provide the random value
needed to generate a key pair for DSA, ECDSA or RSA as
specified in [FIPS 186-3]. The
maximum security strength that can be supported by these
algorithms and the key lengths
used by these algorithms are provided in [SP 800-57-1].

For example, [SP 800-57-1] states that a DSA key pair with a
public-key length of 2048
bits and a private-key length of 224 bits can support (at most) a
security strength of 112
bits. [FIPS 186-3] specifies that for such DSA key pairs, the
random value used to
determine a private key must be obtained using an RBG that
supports a security strength
of 112 bits. Using the method in Section 5, a random value K
that is to be used for the
generation of the key pair is determined by U (a value of an
appropriate bit length
obtained from an RBG that supports a security strength of at
least 112 bits) and V (which
could be zero). The value K is then used to determine the DSA
key pair, as specified in
[FIPS 186-3].
6.2 Key Pairs for Key Establishment
Key establishment includes both key agreement and key
transport. Key agreement is a
method of key establishment in which the resultant secret
keying material is a function of
14
information contributed by the participants, so that no party can
predetermine the value of
the keying material independent of any other party’s
contribution. For key-transport, one
party (the sender) selects a value for the secret keying material
and then securely

distributes that value to another party (the receiver).
Approved methods for generating the (asymmetric) key pairs
used by approved key-
establishment schemes between two parties are specified in [SP
800-56A] (for schemes
that use finite-field or elliptic-curve cryptography) and in [SP
800-56B] (for schemes that
use integer-factorization cryptography, e.g., RSA).
A value of K, computed as shown in Section 5, shall be used to
provide the random
value6 needed to generate key pairs for the finite field or
elliptic curve schemes in [SP
800-56A], or to generate a key pair for the integer-factorization
schemes specified in [SP
800-56B]. The maximum security strength that can be supported
by the approved key-
establishment schemes and the key sizes used by these schemes
is provided in [SP 800-
57-1].
6.3 Distributing the Key Pairs
A general discussion of the distribution of asymmetric key pairs
is provided in [SP 800-
57-1].
The private key shall be kept secret. It shall either be generated
1) within the key-pair
owner’s cryptographic module (i.e., the key-pair owner’s key-
generating module), or 2)
within the cryptographic module of an entity trusted by the key-
pair owner and any
relying party not to misuse the private key or reveal it to other
entities (i.e., generated
within the key-generating module of a Trusted Party, and
securely transferred to the key-
pair owner’s cryptographic module).
If a private key is ever output from a cryptographic module, the

key shall be output and
transferred in a form and manner that provides appropriate
assurance7 of its
confidentiality and integrity. The protection shall provide
appropriate assurance that only
the key-pair owner and/or the party that generated the key pair
will be able to determine
the value of the plaintext private key (e.g., the confidentiality
and integrity protection for
the private key uses a cryptographic mechanism that is at least
as strong as the
(maximum) security strength that must be supported by the
asymmetric algorithm that
will use the private key).
The public key of a key pair may be made public. However, it
shall be distributed and
verified in a manner that assures its integrity and association
with the key-pair owner
(e.g., using a X.509 certificate that provides a level of
cryptographic protection that is at
least as strong as the security strength associated with the key
pair).
6 Note that in Section 5, if V is all zeroes, then K (the random
value) is the output of an RBG.
7 The term “provide appropriate assurance” is used to allow
various methods for the input and output of critical security
parameters to/from the different security levels that may be
implemented for a cryptographic module (see [FIPS 140]
and Section 7.8 of [ImpGuide]).
15

7 Generation of Keys for Symmetric-Key Algorithms
Symmetric-key algorithms use the same (secret) key to both
apply cryptographic
protection to information8 and to remove or verify the
protection9. Keys used with
symmetric-key algorithms must be known by only the entities
authorized to apply,
remove or verify the protection, and are commonly known as
secret keys. A secret key is
often known by multiple entities that are said to share or own
the secret key, although it is
not uncommon for a key to be generated, owned and used by a
single entity (e.g., for
secure storage). A secret key shall be generated by:
• One or more of the entities that will share the key, or
• A Trusted Party that provides the key to the intended sharing
entities in a secure
manner. The Trusted Party must be trusted by all entities that
will share the key
not to disclose the key to unauthorized parties or otherwise
misuse the key.
A symmetric key K could be used, for example, to:
• Encrypt and decrypt data in an appropriate mode (e.g., using
AES in the CTR
mode as specified in [FIPS 197] and SP [800-38A]),
• Generate Message Authentication Codes (e.g., using AES in
the CMAC mode, as
specified in [FIPS 197] and [SP 800-38B], or HMAC, as
specified in [FIPS 198],

or
• Derive additional keys using a key derivation function
specified in [SP 800-108],
where K is the pre-shared key that is used as the key-derivation
key.
7.1 The “Direct Generation” of Symmetric Keys
Symmetric keys that are to be directly generated from the
output of an RBG shall be
generated as specified in Section 5, where K is the desired key.
The length of the key to
be generated is determined by the algorithm with which it will
be used and the desired
security strength to be provided; see [SP 800-57-1] for
discussions on key lengths and the
(maximum) security strengths supported by symmetric-key
algorithms.
7.2 Distributing the Generated Symmetric Key
The symmetric key generated within the key-generating module
often needs to be shared
with one or more other entities that have their own
cryptographic modules. The key may
be distributed manually, or using an approved key transport or
key wrapping method
(see [SP 800-56A], [SP 800-56B] and [SP 800-38F]). See [SP
800-57-1] for further
discussion. The method used for key transport or key wrapping
shall support the desired
security strength needed to protect the target data (i.e., the data
to be protected using the
8 For example, transform plaintext data into ciphertext data
using an encryption operation or compute a message
authentication code (MAC).

9 For example, remove the protection by transforming the
ciphertext data back to the original plaintext data using a
decryption operation, or verify the protection by computing a
message authentication code and comparing the newly
computed MAC with a received MAC)
16
symmetric key). The requirements for outputting a key from a
cryptographic module are
discussed in [FIPS 140].
7.3 Symmetric Keys Generated Using Key-Agreement Schemes
When an approved key-agreement scheme is available within an
entity’s key-generating
module, a symmetric key may be established with another entity
that has the same
capability; this process results in a symmetric key that is shared
between the two entities
participating in the key-agreement transaction; further
distribution of this symmetric key
is not required between the two entities.
Figure 1 depicts a typical key-agreement process. Asymmetric
key-agreement keys are
used with a key-agreement primitive to generate a shared secret.
The shared secret is
provided to a key-derivation method (e.g., a single-step key
derivation function or an
extraction-then-expansion (E-E) procedure) to derive keying
material. [SP 800-56A]
specifies approved key-agreement methods based on DLC; [SP

800-56B] includes
specifications for approved key-agreement methods based on
IFC. Approved single-step
key derivation functions are specified in [SP 800-56A] and [SP
800-56B]; approved
extraction-then-expansion procedures are specified in [SP 800-
56C] and may be used by
the key-agreement schemes, as specified in [SP 800-56A].
Figure 1: Key-agreement Process per SP 800-56A, B and C
17
The key-agreement schemes used by many widely used internet
security protocols do not
fully comply with [SP 800-56A] and [SP 800-56B]. For
example, the key-derivation
method used to derive keying material from the shared secret
may be different. [SP 800-
135] discusses some of these protocols, conditionally approves
the use of the key
derivation functions employed by those protocols, and specifies
requirements for that
approved use.
The maximum security strength that can be supported by a key
derived in this manner is
dependent on 1) the security strength supported by the
asymmetric key pairs (as used
during key establishment), 2) the key-derivation method used,
3) the length of the derived
key and 4) the algorithm with which the derived key will be

used. See [SP 800-57-1] for
items 1, 3 and 4. For item 2, see [SP 800-56A], [SP 800-56B]
and [SP 800-56C] when
the key-derivation method specified therein is used; no
statement is made at this time
concerning the security strengths that may be supported by a
key derived using the
methods specified in [SP 800-135].
7.4 Symmetric Keys Derived From a Pre-shared Key
Symmetric keys are often derived using a key derivation
function (KDF) and a pre-shared
key known as a key-derivation key. The pre-shared key may
have been:
• Generated from an approved RBG (see Section 5) and
distributed as specified in
Section 7.2, if required,
• Agreed upon using a key-agreement scheme (see Section 7.3),
or
• Derived using a KDF and a (different) pre-shared key as
specified in [SP 800-
108].
Approved methods are provided in [SP 800-108], which
specifies approved KDFs for
deriving keys from a pre-shared key (i.e., a key-derivation key).
The KDFs are based on
HMAC [FIPS 198] and CMAC [SP 800-38B].
If the derived keys need to be distributed to other entities, this
may be accomplished as
discussed in Section 7.2.
In addition to the symmetric algorithm with which a derived key
will be used, the

security strength that can be supported by the derived key
depends on the security
strength supported by the key-derivation key and the KDF
method used (see [SP 800-57-
1] for the maximum security strength that can be supported by
HMAC and CMAC, and
[SP 800-107] for further discussions about the security strength
of HMAC).
7.5 Symmetric Keys Derived From Passwords
In a number of popular applications, keys are generated from
passwords. This is a
questionable practice, as the passwords usually contain very
little entropy (i.e.,
randomness), and are, therefore, easily guessed. However,
approved methods for
deriving keys from passwords for storage applications are
provided in [SP 800-132]. For
these applications, users are strongly advised to select
passwords with a very large
amount of entropy.
18
When a key is generated from a password, the entropy provided
(and thus, the maximum
security strength that can be supported by the generated key)
shall be considered to be
zero unless the password is generated using an approved RBG.
In this case, the security
strength that can be supported by the password
(password_strength) is no greater than the

minimum of the security strength supported by the RBG
(RBG_strength) and the actual
number of bits of RBG output (RBG_outlen) used in the
password. That is,
password_strength ≤ min(RBG_strength, RBG_outlen).
7.6 Symmetric Keys Produced by Combining Multiple Keys and
Other
Data
When symmetric keys K1, …, Kn are generated and/or
established independently, they
may be combined within a key-generating module to form a key
K. Other items of data
(V1, …, Vm) that are independent of these keys can also be
combined with the Ki to form
K, under the conditions specified below. Note that, while the Ki
values are required to be
secret, the Vi values need not be kept secret.
The independent generation/establishment of the component
keys K1, …, Kn is
interpreted in a computational and a statistical sense; that is, the
computation of any
particular Ki value does not depend on any one or more of the
other Ki values, and it is
not feasible to use knowledge of any proper subset of the Ki
values to obtain any
information about the remaining Ki values.
The independence of the component keys from the other items
of data is also interpreted
in a computational and a statistical sense. This means that the
computation of the Ki
values does not depend on any of the Vj values, the computation
of the Vj values does not
depend on any of the Ki values, and knowledge of the Vj values
yields no information that

can feasibly be used to gain insight into the Ki values. In cases
where some (or all) of the
Vj values are secret, and the rest of the Vj values (if any) are
public, “independence” also
means that knowledge of the Ki values and public Vj values
yields no information that can
feasibly be used to gain insight into the secret Vj values.
The component symmetric keys K1, …, Kn shall be generated
and/or established
independently using approved methods10. The other items of
data (i.e., V1, …, Vm) may
be generated or obtained using any method that ensures their
independence from those
keys.
The approved methods for combining these symmetric keys (and
other items of data)
are:
1. Concatenating two or more keys, i.e., K = K1 || …|| Kn. The
sum of the bit lengths
of the n component keys shall be equal to the required bit length
of K.
2. Exclusive-Oring one or more symmetric keys, i.e., K = K1 ⊕
… ⊕ Kn. The length
of each component key (Ki) shall be equal to the length required
for K.
10 See Sections 7.1, 7.3, 7.4 and 7.5.
19

3. Exclusive-Oring one or more symmetric keys and one or
more other items of data,
i.e., K = K1 ⊕ … ⊕ Kn ⊕ V1 ⊕ … ⊕ Vm. The length of each
component key (Ki)
and each item of data (Vi) shall be equal to the length required
for K.
Each Ki used in one of the three methods above shall be kept
secret, shall be considered a
key-derivation key, and shall not be used for any purpose other
than the computation of a
specific symmetric key K (i.e., a given Ki shall not be used to
generate more than one
key).
7.7 Replacement of Symmetric Keys
Sometimes, a symmetric key may need to be replaced. This may
be due to a compromise
of the key or the end of the key’s cryptoperiod (see [SP 800-57-
1]). Replacement may be
accomplished by a rekeying process or by a key-update process.
Rekeying is the
replacement of a key with a new key that is generated in a
manner that is entirely
independent of the value of the old key (i.e., knowledge of the
old key provides no
knowledge of the value of the replaced key and vice versa). In a
key-update process, the
new key is usually related in some way to the old key that it
replaces.
Compromised keys shall only be rekeyed, rather than updated.
When a compromised key
is replaced, the new key shall be generated in a manner that
provides assurance of its
independence from the compromised key. The new key may be

generated using any
method in Section 7 with the following restrictions:
1. The method used shall provide assurance that there is no
feasibly detectable
relationship between the new key and the compromised key. To
that end, the new
key shall not be derived or updated using the compromised key.
2. If the compromised key was generated in a manner that
depended (in whole or in
part) on a password (see Sections 7.5 and 7.6), then that
password shall be
changed prior to the generation of any new key; in particular,
the new key(s) shall
be generated in a manner that is independent of the old
password value.
If an uncompromised symmetric key is to be replaced, it shall
be replaced using any
method in Section 7 that supports the required amount of
security strength. However, if
the key to be replaced was generated in a manner that depended
(in whole or in part) on a
password (see Sections 7.5 and 7.6), that password shall be
changed prior to the
generation of the new key.
20

Appendix A: References
[FIPS 140] FIPS 140-2, Security Requirements for
Cryptographic Modules, May
2001, available at
http://csrc.nist.gov/publications/PubsFIPS.html.
[FIPS 180] FIPS 180-4, Secure Hash Standard, March 2012.
[FIPS 186-2] Digital Signature Standard, January 2000.
[FIPS 186-3] FIPS 186-3, Digital Signature Standard, June
2009.
[FIPS 197] Advanced Encryption Standard (AES), November
2001.
[FIPS 198] FIPS 198-1, Keyed-Hash Message Authentication
Code (HMAC), July
2008.
[SP 800-38A] Recommendation for Block Cipher Modes of
Operation - Methods and
Techniques, December 2001.
[SP 800-38B] SP 800-38B, Recommendation for Block Cipher
Modes of Operation: The
CMAC Mode for Authentication, May 2005.
[SP 800-38F] DRAFT Recommendation for Block Cipher Modes
of Operation: Methods
for Key Wrapping, August 2011 (Draft).
[SP 800-56A] SP 800-56A, Recommendation for Pair-Wise Key
Establishment Schemes
Using Discrete Logarithm Cryptography, March 2007.
[SP 800-56B] SP 800-56B, Recommendation for Pair-Wise Key
Establishment Using
Integer Factorization Cryptography, August 2009.

[SP 800-56C] SP 800-56C, Recommendation for Key Derivation
through Extraction-
then-Expansion, November 2011.
[SP 800-57-1] SP 800-57, Part 1, Recommendation for Key
Management: General, July
2012.
[SP 800-67] Recommendation for the Triple Data Encryption
Algorithm (TDEA)
Block Cipher, January 2012.
[SP 800-90] SP 800-90A, Recommendation for Random Number
Generation Using
Deterministic Random Bit Generators, January 2012.
Draft SP 800-90B, Recommendation for the Validation of
Entropy
Sources for Random Bit Generation, September 5, 2012.
Draft SP 800-90C, Recommendation for Random Bit Generator
(RBG)
Constructions, September 5, 2012.
[SP 800-108] SP 800-108, Recommendation for Key Derivation
Using Pseudorandom
Functions (Revised), October 2009.
21
[SP 800-131A] Recommendation for the Transitioning of
Cryptographic Algorithms and
Key Lengths, January 2011.

[SP 800-132] SP 800-132, Recommendation for Password-Based
Key Derivation, Part
1: Storage Applications, December 2010.
[SP 800-135] SP 800-135, Recommendation for Existing
Application-Specific Key
Derivation Functions, December 2010.
[ImpGuide] Implementation Guidance for FIPS PUB 140-2 and
the Cryptographic
Module Validation Program, available at
http://csrc.nist.gov/groups/STM/cmvp/standards.html.
[X9.31] American National Standard (ANS) X9.31-1998, Digital
Signatures Using
Reversible Public Key Cryptography for the Financial Services
Industry
(rDSA), Withdrawn, but available from X9.org.
[X9.62] American National Standard X9.62-2005, Public Key
Cryptography for the
Financial Services Industry: The Elliptic Curve Digital
Signature Algorithm
(ECDSA), available at x9.org.
1 Introduction2 Authority3 Definitions, Acronyms and
Symbols3.1 Definitions3.2 Acronyms3.3 Symbols4 General
Discussion4.1 Keys to Be Generated4.2 Where Keys are
Generated4.3 Supporting a Security Strength5 Using the Output
of a Random Bit Generator6 Generation of Key Pairs for
Asymmetric-Key Algorithms6.1 Key Pairs for Digital Signature
Schemes6.2 Key Pairs for Key Establishment6.3 Distributing
the Key Pairs7 Generation of Keys for Symmetric-Key
Algorithms7.1 The “Direct Generation” of Symmetric Keys7.2
Distributing the Generated Symmetric Key7.3 Symmetric Keys
Generated Using Key-Agreement Schemes7.4 Symmetric Keys

Derived From a Pre-shared Key7.5 Symmetric Keys Derived
From Passwords7.6 Symmetric Keys Produced by Combining
Multiple Keys and Other Data7.7 Replacement of Symmetric
KeysAppendix A: References
Instructions: Do not combine topics. Answer each letter
separately. All answers must be at least five (5) sentences.
Include any references.
1) "Cryptography" Please respond to the following:
• A) Analyze the overall attributes of symmetric and asymmetric
cryptography technologies. Discuss the advantages and
disadvantages of each, and speculate upon the main reasons why
organizations utilize both technologies today. Give an example
of where you would consider using each of these forms of
encryption within an organization to support your response.
• B) From the e-Activity (see attachments), give your opinion of
whether cryptography should be a part of every email security
strategy or if there are specific characteristics of organizations
where such measures are not needed. Justify your answer.
2) Routing and Switching Selection Criteria. Please respond to
the following:
· A) Compare and contrast distance-vector and link state
routing, and analyze the limitations that would prevent the
usage of each.
· B) Choose the method best suited for designing a new routing
protocol for a LAN architecture. Justify your decision.

3) Transmission Medium. Please respond to the following:
· A) Suggest a way to improve the way LLC and MAC are used
for LAN operation.
· B) Evaluate guided and unguided transmission medium to
determine which you would use to design a new facility.

4202016 NIST SP 800-12, Chapter 19httpfas.orgirpdod.docx

Recommended

Recommended

More Related Content

Similar to 4202016 NIST SP 800-12, Chapter 19httpfas.orgirpdod.docx

Similar to 4202016 NIST SP 800-12, Chapter 19httpfas.orgirpdod.docx (20)

More from alinainglis

More from alinainglis (20)

Recently uploaded

Recently uploaded (20)

4202016 NIST SP 800-12, Chapter 19httpfas.orgirpdod.docx