![How To Set Up PKI [Choosing a Hash and Key Size] - cover graphic](/_next/image/?url=https%3A%2F%2Fcdn.venafi.com%2F994513b8-133f-0003-9fb3-9cbe4b61ffeb%2F165ff63f-13e0-4133-b93a-04f11c1c3558%2Faid_field_img__5ed15f7e63bdbac6e194926994c37b4b.png%3Fw%3D864%26h%3D370%26fm%3Dwebp%26q%3D75%26fit%3Dcrop&w=3840&q=75&dpl=dpl_H1HoLru8zbnj4wwarzUVadLRmxGZ){kind=small}
Implementing an enterprise-wide strong authentication is critical in today’s hyper interconnected word of increased cyber threats. As hackers get smarter and intrusions get more widespread and more damaging, enterprises should not depend on outdated practices to keep their data, networks and people safe. User names and passwords have been the trusty lock on the front door for decades, but they’re no longer secure enough. With more than 90 percent of organizations reportedly being breached, it is not an issue whether you will be breached but when you will. You just can’t afford to be caught off guard. A breach can cost hundreds of thousands of dollars and do irreversible damage to your reputation.
Welcome to Public Key Infrastructure or PKI, a security framework used by top enterprises, defense departments and governments around the world. With a properly implemented and effectively managed PKI you can rest assure that your sensitive documents and the digital identities of users and machines are well protected. With PKI, you can prevent hackers from intercepting your communications, you can optimize authentication and save costs, and finally you will improve your business processes.
Before running into PKI configuration and implementation, it’s important to adequately plan and understand that certain decisions influence other decisions. If you ignore the planning part, you may spend much time undoing and going backwards in the process. A crucial part of the planning process is security. You will need to determine the level of security required for your PKI, which is closely related with the level of risk. Two aspects of PKI security are key size or key length and the hashing algorithm.
What Key Size Should I Use?
In cryptography, encryption and/or decryption of sensitive and classified information is achieved through the combined use of cryptographic algorithms and keys. Keys are characterized by their key size or key length, which is the number of bits in the key used in the cryptographic algorithm. NIST SP 800-57 Part 1, rev. 4 defines a cryptographic key as “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, reverse or verify the operation, while an entity without knowledge of the key cannot.”
Key length defines an algorithm's security, since it is “associated with the amount of work (that is, the number of operations) that is required to break a cryptographic algorithm or system.” Keys are used to control the operation of a cipher so that only the correct key can convert encrypted text (ciphertext) to plaintext and vice versa. Many ciphers are actually based on publicly known algorithms and so it is only the difficulty of obtaining the key that determines security of the system, provided that there isn’t any structural weakness in the algorithms used, and assuming that the key is not otherwise available, such as via theft, extortion, or compromise of computer systems.
Therefore, a key should be large enough so that a brute-force attack is not feasible, meaning it would take too long to execute and the result would be of no use. Shannon's work on information theory showed that to achieve so called perfect secrecy, the key length must be at least as large as the message and only used once (One-time pad algorithm). Because of the practical difficulty of managing such long keys, modern cryptographic practice has discarded the notion of perfect secrecy as a requirement for encryption, and instead focuses on computational security, under which the computational requirements of breaking an encrypted text must not be feasible for an attacker.
PKI: Are You Doing It Wrong?
Encryption systems are often grouped into families. Common families include symmetric systems (such as AES or 3TDEA) and asymmetric systems (such as RSA or Diffie-Hellman). They may alternatively be grouped according to the central algorithm used (such as finite-field, integer-factorization and elliptic curve cryptography).
As each of these is of a different level of cryptographic complexity, it is usual to have different key sizes for the same level of security, depending upon the algorithm used. NIST defines two cryptographic algorithms as “of comparable strength for the given key sizes (X and Y) if the amount of work needed to “break the algorithms” or determine the keys (with the given key sizes and sufficient entropy) is approximately the same using a given resource.”
Given the above definition, NIST has published a table that gives the current estimates for the maximum security strengths that the approved symmetric and asymmetric cryptographic algorithms can provide for various specified key lengths. These estimates were made under the assumption that the keys used with those algorithms are generated and handled in accordance with specific rules. If these rules are not followed, the security provided may be less than the security strength estimates.
The actual degree of security achieved over time varies, as more computational power and more powerful mathematical analytic methods become available. For this reason cryptologists tend to look at indicators that an algorithm or key length shows signs of potential vulnerability, to move to longer key sizes or more difficult algorithms. Advances in computer technology provided an indication back in 2007 that RSA-1024 encryption (which means RSA algorithm with 1024-bit key) would be breakable before 2010 and in 2015 the Logjam vulnerability proved that Diffie-Hellman algorithm with 1024-bit key is insufficient. Both have been deprecated.
This is where the advancement of quantum computing comes into play. If large-scale quantum computers are ever built, they will be able to break many of the public-key cryptosystems currently in use. This would seriously compromise the confidentiality and integrity of our digital communications. The goal of post-quantum cryptography (also called quantum-resistant cryptography) is to develop cryptographic systems that are secure against both quantum and classical computers, and can inter-operate with existing communications protocols and networks.
As a general guideline, the longer the lifetime of the certificate the longer the key length should be. For applications that will be using certificates you will need to determine the maximum key length they support. Some applications have limitation on the key size not only in the actual certificate it is using, but also for any certificates in the CA hierarchy.
Revisiting our initial question and having in mind the analysis we made, it is obvious that there isn’t a single answer. It depends on various factors, the confidentiality of the data to be protected, the environment where these data are in transit or stored, the duration of the requirement to protect our data and the advances of technology. NIST SP 800-57 pt.1 rev 4 publication provides a thorough background and criteria for selecting appropriate cryptographic algorithm and keys.
What is mostly important is the procedures we follow to safeguard our keys. How do we protect them from unauthorized disclosure, compromise of integrity, misuse, lack of user authentication. Do we use applications that automate the way we manage our keys?
What Hash Should I Use?
Many algorithms and schemes that provide a security service use a hash function as a component of the algorithm. NIST FIPS 180-4 defines secure hash algorithms (SHA), while FIPS 202 defines SHA-3.
Secure Hash Algorithms (SHA) are used for computing a condensed representation of electronic data (message). When a message of any length less than 264 bits (for SHA-224 and SHA-256) or less than 2128 bits (for SHA-384, SHA-512, SHA-512/224 and SHA-512/256) is input to a hash algorithm, the result is an output called a message digest. Common names for the output of a hash function include also hash value, hash, and digital fingerprint. The message digests range in length from 160 to 512 bits, depending on the algorithm.
In accordance with FIPS 180-4, the hash algorithms are called secure because, for a given algorithm, it is computationally infeasible (1) to find a message that corresponds to a given message digest, or (2) to find two different messages that produce the same message digest. Any change to a message will, with a very high probability, result in a different message digest. This will result in a verification failure when the secure hash algorithm is used with a digital signature algorithm or a keyed-hash message authentication algorithm.
Secure hash algorithms are typically used with other cryptographic algorithms, such as digital signature algorithms and keyed-hash message authentication codes, or in the generation of random numbers (bits). Message Authentication Codes (MACs) can be used to provide source and integrity authentication. A MAC is a cryptographic checksum on the data that is used in order to provide assurance that the data has not changed and that the MAC was computed by the expected entity. FIPS 198 specifies the computation of a MAC using an approved hash function. A variety of key sizes are allowed for Hash Message Authentication Codes (HMAC), while the choice of key size depends on the amount of security to be provided to the data and the hash function used.
Digital signatures are used to provide source authentication, integrity authentication and support for non-repudiation. Digital signatures are used in conjunction with hash functions and are computed on data of any length (up to a limit that is determined by the hash function).
In order to determine the appropriate hash functions that may be employed, the minimum security strength index is a factor to consider along with the algorithm, scheme or application in which the hash function is used. Below table, adapted from NIST SP 800-57 Pt 1 Rev 4 lists the approved hash functions that can be used to provide the identified security strength for various hash-function applications.
It is very important to note that SHA-1 is mentioned only for legacy purposes, since it has been deprecated by NIST in May 2011 due to known collision attacks. In addition, all major browser and software vendors like Microsoft, Mozilla and Google have already phased out the use of SHA-1 hashing systems.
Security Strength
Digital Signatures and Hash-only Applications
HMAC
≦80
SHA-1
112
SHA-224, SHA-512/224, SHA3-224
128
SHA-256, SHA-512/256, SHA3-256
SHA-1
192
SHA-384, SHA3-384
SHA-224, SHA-512/224
≧256
SHA-512, SHA3-512
SHA-256, SHA-512/256, SHA-384, SHA-512, SHA3-512
Table 2: Hash functions that can be used to provide the targeted security strengths. Adapted from NIST SP 800-57 Pt1 R4
Recommendation
When choosing hash algorithms and key lengths, one needs to take into account the current landscape. You need to do a little bit of research on how hash algorithms are currently standing up to collision attacks and what key lengths are acceptable.
The U.S. Federal PKI program states that: “Trusted Certificates that expire before January 1, 2031 shall contain subject public keys of 2048 or 3072 bits for RSA or 256 or 384 bits for elliptic curve, and be signed with the corresponding private key. Trusted Certificates that expire on or after January 1, 2031 shall contain subject public keys of 3072 bits for RSA or 256 or 384 bits for elliptic curve, and be signed with the corresponding private key.”
When building that PKI, you could follow the stronger guidance put forth by NIST and the Governmental and Federal policies and choose SHA-256, or SHA-384 along with RSA Keys of 4096 bits or ECC keys of 256 or 384 bits.
If you absolutely must support legacy applications, and are building out a new public key infrastructure, a good recommendation would be to build two hierarchies. The first hierarchy, the legacy one, would have a lower key lifetime with a documented and well-defined end of life. The second PKI would be erected with more current algorithms and key lengths to support more current clients and with much longer expiry periods.
Get a 30 Day Free Trial of TLS Protect Cloud, Automated Certificate Management.
Related posts