Part 1: General - Computer Security Resource Center - National ...
Part 1: General - Computer Security Resource Center - National ... Part 1: General - Computer Security Resource Center - National ...
March, 2007 protection. In addition, the signature must be generated using a hash algorithm of comparable or greater strength, such as SHA-224 or SHA-256. 5.6.3 Using Algorithm Suites Algorithm suites that combine non-comparable strength algorithms are generally discouraged. However, algorithms of different strengths and key sizes may be used together for performance, availability or interoperability reasons, provided that sufficient protection is provided. In general, the weakest algorithm and key size used to provide cryptographic protection determines the strength of the protection. Exceptions to this principle require extensive analysis. Determination of the strength of protection provided for information includes an analysis not only of the algorithm(s) and key size(s) used to apply the cryptographic protection(s) to the information, but also any algorithms and key sizes associated with establishing the key(s) used for information protection, including those used by communication protocols. The following is a list of several algorithm combinations and discussions on the security implications of the combination: 1. When a key establishment scheme is used to establish keying material for use with one or more algorithms (e.g., TDEA, AES, or HMAC), the strength of the selected combination is comparable to the weakest algorithm and key size used. For example, if a 160 bit ECC key is used to establish a 128-bit AES key (as defined in [SP800-56]), only 80 bits of security are provided for any information protected by that AES key, since the 160 bit ECC provides only 80 bits of security. If 128 bits of security are required for the information protected by AES, then either an ECC key size of at least 256 bits, or another key establishment algorithm of appropriate key size needs to be selected to provide the required protection. 2. When a hash function and digital signature algorithm are used in combination to compute a digital signature, the strength of the signature is determined by the weaker of the two algorithms. For example, SHA-256 used with RSA using a 1024 bit key provides 80 bits of security because a 1024 bit RSA key provides only 80 bits of security. If 112 bits of security is required, a 2048 bit RSA key would be appropriate. 3. When a random bit generator is used to generate a key for a cryptographic algorithm that is intended to provide X bits of security, an Approved random bit generator shall be used that provides at least X bits of security. If it is determined that a specific level of security is required for the protection of data, then an algorithm and key size suite needs to be selected that would provide that level of security as a minimum. For example, if 128 bits of security are required for data that is to be communicated and provided with confidentiality, integrity, authentication and non-repudiation protection, the following selection of algorithms and key sizes may be appropriate: a. Confidentiality: Encrypt the information using AES-128. Other AES key sizes would also be appropriate, but perform a bit slower. b. Integrity, authentication and non-repudiation: Suppose that only one cryptographic operation is preferred. Use digital signatures. SHA-256 could be selected for the hash function. Select an algorithm for digital signatures from what is available to an application (e.g., ECDSA with at least a 256-bit key). If more than one algorithm and key 67
March, 2007 size is available, the selection may be based on algorithm performance, memory requirements, etc. as long as the minimum requirements are met. c. Key establishment: Select a key establishment scheme based on the application and environment (see [SP800-56]), the availability of an algorithm in an implementation, and its performance. Select a key size from Table 2 for the algorithm that provides at least 128 bits of security. For example, if an ECC key agreement scheme is available, use the ECC scheme with a 256-bit key. However, it is recommended that the key used for key agreement be different from an ECDSA key used for digital signatures. Agencies that procure systems should consider the potential operational lifetime of the system. The agencies shall either select algorithms that are expected to be secure during the entire system lifetime, or should ensure that the algorithms and key sizes can be readily updated. 5.6.4 Transitioning to New Algorithms and Key Sizes The estimated time period during which data protected by a specific cryptographic algorithm (and key size) remains secure is called the algorithm security lifetime. During this time, the algorithm may be used to both apply cryptographic protection (e.g., encrypt data) and to process the protected information (e.g., decrypt data); the algorithm is expected to provide adequate protection for the protected data during this period. Typically, an organization selects the cryptographic services that are needed for a particular application. Then, based on the algorithm security lifetime and the security life of the data to be protected, an algorithm and key size suite is selected that is sufficient to meet the requirements. The organization then establishes a key management system (if required), including validated cryptographic products that provide the services required by the application. As an algorithm and key size suite nears its expiration date, transitioning to a new algorithm and key size suite should be anticipated. There are many legacy applications currently available that use algorithms and key sizes not specified in Table 2. When the algorithm or key size is determined to no longer provide the desired protection for information (e.g., the algorithm may have been "broken"), any information "protected" by the algorithm or key size is considered to be "exposed" (e.g., no longer confidential, or the integrity cannot be assured). If the protected data is retained, it should be reprotected using an Approved algorithm and key size that will protect the information for the remainder of its security life. However, it should be assumed that encrypted information could have been collected and retained by unauthorized entities (adversaries). The unauthorized entity may attempt to decrypt the information at some later time. In addition, the recovered plaintext could be used to attempt a matched plaintext-ciphertext attack on the new algorithm. When using Table 2 and Table 4 to select the appropriate key size for an algorithm, it is very important to take the expected security life of the data into consideration. As stated earlier, an algorithm (and key size) is used both to apply cryptographic protection to data and process the protected data. When the security life of the data is taken into account, cryptographic protection should not be applied to data using a given algorithm (and key size) if the security life of the data extends beyond the end of the algorithm security lifetime. The period of time that an algorithm (and key size) may be used to apply cryptographic protection is called the algorithm originator usage period. The algorithm security life = (the algorithm usage period + the security life of the data). 68
- Page 17 and 18: March, 2007 1.2 Audience The audien
- Page 19 and 20: March, 2007 1. Section 1, Introduct
- Page 21 and 22: March, 2007 Backup A copy of inform
- Page 23 and 24: March, 2007 Digital signature The r
- Page 25 and 26: Key Management Policy Key Managemen
- Page 27 and 28: Proof of possession (POP) Pseudoran
- Page 29 and 30: March, 2007 Split knowledge A proce
- Page 31 and 32: March, 2007 3 Security Services Cry
- Page 33 and 34: March, 2007 However, it is often th
- Page 35 and 36: March, 2007 4 Cryptographic Algorit
- Page 37 and 38: March, 2007 operates on blocks (chu
- Page 39 and 40: March, 2007 minimum key size 7 of 1
- Page 41 and 42: March, 2007 2. The protocols trigge
- Page 43 and 44: March, 2007 7. Symmetric key wrappi
- Page 45 and 46: March, 2007 9. Random numbers: The
- Page 47 and 48: March, 2007 In general, where stron
- Page 49 and 50: March, 2007 a. When a symmetric key
- Page 51 and 52: March, 2007 information. For less s
- Page 53 and 54: 8. Symmetric and Asymmetric RNG key
- Page 55 and 56: 15. Private ephemeral key agreement
- Page 57 and 58: Key Type 12. Symmetric Key Agreemen
- Page 59 and 60: March, 2007 establishment keys, see
- Page 61 and 62: March, 2007 c. Restricting plaintex
- Page 63 and 64: March, 2007 algorithms completely i
- Page 65 and 66: March, 2007 Table 3: Hash function
- Page 67: Table 4: Recommended algorithms and
- Page 71 and 72: Security life of data up to 4 years
- Page 73 and 74: March, 2007 6 Protection Requiremen
- Page 75 and 76: Table 5: Protection requirements fo
- Page 77 and 78: Key Type Security Service Private e
- Page 79 and 80: March, 2007 Crypto. Security Securi
- Page 81 and 82: March, 2007 may be applied only to
- Page 83 and 84: March, 2007 All cryptographic infor
- Page 85 and 86: March, 2007 8. Domain parameters (e
- Page 87 and 88: March, 2007 6. Destroyed Compromise
- Page 89 and 90: March, 2007 a. A private signature
- Page 91 and 92: 2 Pre-Operational Phase 3 7 1 4 Ope
- Page 93 and 94: March, 2007 8.1 Pre-operational Pha
- Page 95 and 96: 8.1.5.1.1 Distribution of Static Pu
- Page 97 and 98: March, 2007 and then provide eviden
- Page 99 and 100: March, 2007 listed in Section 8.1.5
- Page 101 and 102: March, 2007 encrypting key or publi
- Page 103 and 104: March, 2007 8.1.5.3.5 Intermediate
- Page 105 and 106: March, 2007 of keying material and
- Page 107 and 108: March, 2007 2. The application in w
- Page 109 and 110: March, 2007 and the key derivation
- Page 111 and 112: March, 2007 Type of Key Archive? Re
- Page 113 and 114: March, 2007 All records of the enti
- Page 115 and 116: March, 2007 other cryptographic inf
- Page 117 and 118: March, 2007 access to information e
March, 2007<br />
size is available, the selection may be based on algorithm performance, memory<br />
requirements, etc. as long as the minimum requirements are met.<br />
c. Key establishment: Select a key establishment scheme based on the application and<br />
environment (see [SP800-56]), the availability of an algorithm in an implementation, and<br />
its performance. Select a key size from Table 2 for the algorithm that provides at least<br />
128 bits of security. For example, if an ECC key agreement scheme is available, use the<br />
ECC scheme with a 256-bit key. However, it is recommended that the key used for key<br />
agreement be different from an ECDSA key used for digital signatures.<br />
Agencies that procure systems should consider the potential operational lifetime of the system.<br />
The agencies shall either select algorithms that are expected to be secure during the entire<br />
system lifetime, or should ensure that the algorithms and key sizes can be readily updated.<br />
5.6.4 Transitioning to New Algorithms and Key Sizes<br />
The estimated time period during which data protected by a specific cryptographic algorithm<br />
(and key size) remains secure is called the algorithm security lifetime. During this time, the<br />
algorithm may be used to both apply cryptographic protection (e.g., encrypt data) and to process<br />
the protected information (e.g., decrypt data); the algorithm is expected to provide adequate<br />
protection for the protected data during this period.<br />
Typically, an organization selects the cryptographic services that are needed for a particular<br />
application. Then, based on the algorithm security lifetime and the security life of the data to be<br />
protected, an algorithm and key size suite is selected that is sufficient to meet the requirements.<br />
The organization then establishes a key management system (if required), including validated<br />
cryptographic products that provide the services required by the application. As an algorithm and<br />
key size suite nears its expiration date, transitioning to a new algorithm and key size suite should<br />
be anticipated.<br />
There are many legacy applications currently available that use algorithms and key sizes not<br />
specified in Table 2. When the algorithm or key size is determined to no longer provide the<br />
desired protection for information (e.g., the algorithm may have been "broken"), any information<br />
"protected" by the algorithm or key size is considered to be "exposed" (e.g., no longer<br />
confidential, or the integrity cannot be assured). If the protected data is retained, it should be reprotected<br />
using an Approved algorithm and key size that will protect the information for the<br />
remainder of its security life. However, it should be assumed that encrypted information could<br />
have been collected and retained by unauthorized entities (adversaries). The unauthorized entity<br />
may attempt to decrypt the information at some later time. In addition, the recovered plaintext<br />
could be used to attempt a matched plaintext-ciphertext attack on the new algorithm.<br />
When using Table 2 and Table 4 to select the appropriate key size for an algorithm, it is very<br />
important to take the expected security life of the data into consideration. As stated earlier, an<br />
algorithm (and key size) is used both to apply cryptographic protection to data and process the<br />
protected data. When the security life of the data is taken into account, cryptographic protection<br />
should not be applied to data using a given algorithm (and key size) if the security life of the<br />
data extends beyond the end of the algorithm security lifetime. The period of time that an<br />
algorithm (and key size) may be used to apply cryptographic protection is called the algorithm<br />
originator usage period. The algorithm security life = (the algorithm usage period + the security<br />
life of the data).<br />
68