As I advance into the heart of PKI in this second installment, the focal point shifts towards two pivotal decisions that anyone involved in setting up a PKI must grapple with — choosing the appropriate key length and the cryptographic algorithm. These choices are far from arbitrary, for they are the bedrock of a secure and efficient PKI. A meticulous selection in this stage ensures a fortification capable of withstanding the numerous cyber threats that litter the digital space in this day and age.
But why is the choice of key length and algorithm so vital? In the simplest terms, the key length and the algorithm act as both the shield and the sword in the cyber battleground, protecting sensitive data from unauthorized access and ensuring the authenticity and integrity of the digital communications.
The key length dictates the cryptographic strength, a longer key offering a sturdier defense against brute force attacks. Meanwhile, the choice of algorithm influences not just the security but also the speed of encryption and decryption processes. It’s a delicate balancing act between security and performance.
Understanding cryptography basics
Text to Ciphertext: An overview
Before I delve into the more intricate aspects of PKI, it’s essential to start with the basics of cryptography. At its core, cryptography is the art of securing communication. When I encrypt plaintext (readable data) into ciphertext (encoded data), I shield the information, making it inaccessible to unauthorized parties. This conversion is executed through a systematic algorithmic process where the plaintext is transformed using a key — a secret parameter known only to the communicating parties.
This secure method of transmission ensures that your confidential data remains just that — confidential.
Simple encryption example: Caesar Cipher
To understand encryption better, let’s look at one of the simplest encryption techniques – the Caesar cipher, named after Julius Caesar, who reportedly used it to communicate confidentially with his generals.
The Caesar cipher is a type of substitution cipher where each character in the plaintext is ‘shifted’ a certain number of places down or up the alphabet. For instance, with a shift of 3, ‘A’ would be replaced by ‘D’, ‘B’ with ‘E’, and so on.
Let’s take a plain text: “HELLO”. With a shift of 3 places, it would be encrypted to “KHOOR”.
This method, although straightforward and easy to decipher in the modern age, lays the foundation of understanding more complex encryption methods, giving us a glimpse into the fascinating world of cryptography.
Defining and understanding key length
As I venture deeper, it’s pertinent to understand the concept of ‘key length.’ The ‘key’ is a piece of information utilized by the encryption algorithm to transform plaintext into ciphertext and vice versa during decryption. The ‘key length’ refers to the number of bits in the key. Typically, a longer key length denotes a higher level of security, as it creates a broader range of potential keys, making it exponentially harder for unauthorized parties to crack the code.
However, a longer key length also demands more computational power, creating a need to strike a balance between security and efficiency. In the coming sections, I will analyze the different key lengths and how to choose the one that suits your requirements best, navigating the delicate interplay between security and performance.
RSA and ECC – A comparative analysis
Overview of RSA and its mathematical foundation
RSA, named after its inventors Rivest, Shamir, and Adleman, stands as one of the first and most widely used public-key cryptosystems. It operates based on the mathematical properties of prime numbers and their usage in factorization problems.
At its core, RSA involves three primary steps: key generation, encryption, and decryption. The security of RSA is rooted in the difficulty of factorizing the product of two large prime numbers, a problem known to be hard to solve, hence providing a secure foundation for encrypting information.
A vital concept here is the key length, which essentially refers to the size of the prime numbers used. Longer key lengths imply a higher security level but come at the cost of computational efficiency.
Overview of ECC and its mathematical foundation
Elliptic Curve Cryptography (ECC), on the other hand, is a newer approach leveraging the algebraic structure of elliptic curves over finite fields. This method promises the same level of security as RSA but requires a much smaller key size, hence resulting in faster computations and reduced storage and memory usage.
The security of ECC is grounded in the elliptic curve discrete logarithm problem, a complex problem to solve, providing a robust defense against potential attacks.
Key lengths: RSA vs. ECC
When it comes to choosing between RSA and ECC, one critical aspect to consider is the key length. Generally, ECC offers a higher security level per bit compared to RSA, meaning you need a much smaller key size with ECC to achieve the same security level you’d get with a much larger RSA key.
For instance, a 256-bit key in ECC is generally considered to be as secure as a 3072-bit key in RSA. This discrepancy in key length allows ECC to facilitate secure communications with less computational power, making it a more efficient option, especially for systems with limited resources (mobile, IOT, etc).
Computational effort required for RSA and ECC
While determining the cryptographic system to use, understanding the computational effort required for each is paramount. RSA, with its longer key lengths, generally demands more computational power, leading to slower encryption and decryption processes compared to ECC.
ECC, with its shorter key lengths, facilitates faster encryption and decryption processes, offering a more streamlined and efficient solution, albeit with a different foundational mathematical approach.
In understanding the computational intricacies of both RSA and ECC, it becomes essential to discuss the computational effort in terms of both key length and CPU cycles. Let’s delve into two tables that detail these aspects, helping us draw a comparative analysis:
Table 1: Key length comparison
In this table, I will illustrate the comparative key lengths between RSA, ECC, and their symmetric key counterparts. It provides a direct comparison, helping in understanding the kind of security level you’d be getting with different key lengths.
RSA key length (bits) | ECC key length (bits) | Symmetric key equivalent (bits) |
---|---|---|
1024 | 160-223 | 80 |
2048 | 224-255 | 112 |
3072 | 256-383 | 128 |
7680 | 384-511 | 192 |
15360 | 512+ | 256 |
In the table:
- RSA key length: These are common key lengths used in RSA encryption, with longer key lengths generally offering stronger security but at the cost of increased computational resources.
- ECC key length: These ranges represent the approximate ECC key lengths that offer security comparable to the RSA key lengths in the adjacent cell.
- Symmetric key equivalent: This column provides the symmetric key lengths (like those used in AES encryption) that offer security roughly equivalent to the RSA and ECC key lengths in the same row.
This table gives a ballpark comparison, aiding in understanding the relative strengths of different key lengths across these cryptographic systems. It’s based on the general consensus among cryptographic communities, and exact equivalences might vary based on specific implementations and updates in cryptographic research.
Table 2: CPU cycles comparison
Following the key length comparison, the second table will focus on the approximate number of CPU cycles required to perform cryptographic operations with RSA and ECC at various key lengths. It is important to note that these values can be somewhat speculative and vary greatly depending on the specific circumstances, including the hardware and software involved.
RSA key length (bits) | ECC key length (bits) | Relative computational effort |
---|---|---|
1024 | 160-223 | 1:3 |
2048 | 224-255 | 1:6 |
3072 | 256-383 | 1:10 |
7680 | 384-511 | 1:32 |
15360 | 512+ | 1:64 |
However, these values are rough estimates. They’re based on general benchmarks and available information and can vary depending on specific implementations, software, hardware, and other factors.
In comparison between the computational effort required for both ECC and RSA, it is clear that ECC provides a more efficient performance, requiring fewer computational cycles for encryption processes with comparable security levels offered by RSA. Despite its computational efficiency, ECC’s adoption rate is still tempered by compatibility and integration complexities in existing systems. Therefore, while ECC stands as a powerful, efficient alternative to RSA.
The world of algorithms
Algorithms play a crucial role in ensuring the security and confidentiality of information. The two primary types of algorithms are symmetric and asymmetric.
Symmetric algorithms use the same key for both encryption and decryption. This type of encryption is faster and requires less computational power. However, the primary challenge here is the secure distribution of the key; since it is the same for both processes, it must be kept highly secure to prevent unauthorized access.
Asymmetric algorithms, on the other hand, employ a pair of keys: a public key, which is shared openly, and a private key, which remains confidential. The public key encrypts data, while the private key decrypts it. Despite being more secure due to the two-key system, asymmetric encryption demands more computational resources, making it slower compared to symmetric encryption.
Understanding the differences and unique benefits of these algorithms is fundamental in the secure and efficient transmission of data in various systems.
Introducing Suite B and its successor, the Commercial National Security Algorithm suite
Suite B, a set of cryptographic algorithms published by the National Institute of Standards and Technology (NIST). Suite B, introduced in 2005, included specifications for encryption, hashing, digital signatures, and key exchange.
Following Suite B, the Commercial National Security Algorithm Suite (CNSA) took the reins as of 2015, superseding Suite B and introducing updated standards to ensure heightened security in cryptographic communications. This suite guides the secure communications within the government and between government entities and their partners in the commercial sector. It presents a more robust set of guidelines, incorporating advancements and lessons learned since the days of Suite B. A few key improvements:
Stronger cryptographic algorithms:
- Encryption: Suite B used AES with key sizes of 128 and 256 bits for top secret information. CNSA continued using AES but emphasized on 256-bit keys for a higher security margin.
- Digital Signatures: While Suite B employed ECDSA, CNSA transitioned to using Digital Signature Algorithm (DSA) alongside ECDSA to offer more secure options.
- Key Exchange: Suite B used ECDH, a trend that CNSA continued but with more secure parameter sets to enhance security.
Enhanced hash functions:
- Hash Functions: SHA-256 and SHA-384 were the hash functions advocated by Suite B. CNSA elevated this recommendation to SHA-384 to ensure a higher security level.
Forward secrecy:
- Key Establishment: CNSA introduced more secure key establishment techniques to provide forward secrecy, a feature that protects past sessions against future compromises of secret keys.
Modernized cryptographic primitives:
- CNSA introduced more contemporary cryptographic primitives to offer enhanced security, including recommendations on more secure elliptic curves for public key cryptography.
Current state of algorithm suites and their usage in systems today
In the modern landscape of cryptographic systems, it is important to note the widespread use of the CNSA Suite in contemporary cryptographic implementations. The suite is designed to protect classified and unclassified National Security Systems (NSS) and information.
The CNSA Suite not only establishes a framework for secure communications but also emphasizes interoperability and consistency in cryptographic mechanisms. It is foundational in present secure communications within various operating systems, including but not limited to, government operations.
Moreover, operating systems like Windows have taken steps to implement CNSA Suite, proving its pivotal role in securing modern infrastructures.
Implementation in Windows operating system
the Windows Operating System stands as one of the most widely used platforms, making its compatibility with various cryptographic algorithms a topic of significant relevance.
Windows has exhibited a progressive approach in adopting robust cryptographic suites to enhance security in its operating systems. It incorporates support for a myriad of cryptographic algorithms, including those specified in the Commercial National Security Algorithm Suite (CNSA), such as modern elliptic curve algorithms, amongst others. This support is pivotal in ensuring secure communications in a plethora of applications and environments, fostering a secure, reliable foundation for both individual and enterprise users.
As users, staying updated on the compatibility and support extended by Windows towards various cryptographic suites will arm you with the knowledge to build secure, efficient, and compatible systems in a Windows environment.
Challenges and considerations for using ECC
Despite the many advantages that ECC (Elliptic Curve Cryptography) presents, including faster computations and lower power consumption for a similar level of security compared to RSA, there are several challenges and considerations to note when looking to implement it.
Firstly, ECC is relatively newer and thus may not be supported across all platforms and systems, potentially causing compatibility issues. Moreover, the migration from RSA to ECC is non-trivial and involves a considerable amount of time and expertise to execute seamlessly.
Furthermore, selecting the correct curve is pivotal. While ECC allows for smaller key sizes, which means faster performance and less storage, it introduces complexity in choosing the right elliptic curve — a choice that impacts both security and performance.
Given the evolving cryptographic landscape, the NSA has recommended organizations that have not transitioned to ECC to hold off on making the switch. Instead, it advises waiting for the advent of quantum-resistant algorithms, which are designed to offer security against the threats posed by quantum computers, marking the next frontier in cryptographic security.
Therefore, when contemplating the shift to ECC, organizations must undertake a meticulous assessment of their existing infrastructure to discern the feasibility and implications of such a move. Moreover, a comprehensive understanding of ECC, right from curve selection to its integration with existing systems, is vital to leveraging its benefits while navigating its intricacies proficiently.
Setting up certificates in an enterprise
Root CA: Key lengths and lifetimes – Finding the balance
With Public Key Infrastructure (PKI), the root certificate authority (Root CA) occupies a pivotal role, being the entity that issues digital certificates. It’s therefore crucial to make prudent choices regarding the key length and lifetime of the Root CA to ensure security and operational efficiency.
When considering key length, it is often advised to opt for a lengthier key to ensure enhanced security. A 4096-bit key length strikes a suitable balance, offering robust security while still being feasible for most computational environments. It’s a choice aligned with a vision for long-term security, positioning your infrastructure to be resilient against cryptographic attacks for many years to come.
Equally important is determining a suitable lifetime for the Root CA. A prolonged lifetime, such as 20 years, offers the convenience of a less frequent renewal cycle. However, it necessitates a robust key with a longer length to maintain a high level of security over time. Conversely, a shorter lifetime demands more frequent renewals but allows for a more adaptable approach to the evolving security landscape.
Microsoft’s recommendation
In a session dedicated to key usage titled “Demystifying Native Mode Security to Deliver Internet-based Client Management“, Microsoft underscored the recommendation to set the Root CA validity period at no longer than 16 years. This guidance comes as a measured approach to maintain a secure environment while also considering the rapid evolution in the field of cryptography, which might render longer validity periods less secure due to potential advancements in computational capabilities and cryptographic techniques. By adhering to a 16-year validity period, organizations can ensure a robust defense against potential cryptographic vulnerabilities, fostering a secure and resilient system.
By opting for a 4096-bit RSA key length, which is known for its wide compatibility and high degree of security, a Root CA can have a lifespan stretching up to 20 years, albeit the Microsoft’s recommendation stands at a maximum of 16 years to strike the optimal balance between security and practicality.
For those venturing into establishing a new Root CA, this presents a golden rule to abide by, setting a precedent for security without compromising on the functional aspects. This also allows for a timely reassessment of the security landscape at the end of the Root CA’s lifecycle, enabling necessary updates and enhancements to be incorporated, maintaining a security posture that is both contemporary and robust.
Enterprise CA and leaf certificates: Best practices
Building upon the foundation established by the Root CA, the Enterprise Certificate Authority (Enterprise CA) undertakes the task of issuing certificates to end entities or other subordinate CAs. When configuring the Enterprise CA, it is typical to opt for a key length of 3072 bits and a lifetime of 10 years, striking a balance between security and operational efficiency.
Leaf certificates, issued by the Enterprise CA, inherit the security configurations of their issuer. It is pertinent to note that the leaf certificates cannot possess a lifetime exceeding that of the issuing CA, emphasizing the need for careful planning when determining the lifetime of your Enterprise CA.
Note! A Certificate Authority (CA) is bound by the limitations of its own certificate’s validity period, meaning it cannot issue certificates with a validity period exceeding its own. Moreover, as time progresses, the CA’s capacity to issue long-term certificates diminishes; it is unable to grant certificates with a lifespan surpassing its own remaining validity period. This not only is a rule to adhere to but also serves as a constantly reducing timeframe within which the CA can operate.
Revocation check on Root CA in Windows
In Windows environments, it is essential to address the dynamics of certificate revocation checks on the Root CA. Windows does conduct revocation checks on certificates; however, it bypasses the check for Root CAs since they are self-signed, and there’s no higher authority to validate their legitimacy. Instead, the trust is established through a different mechanism, often involving the manual installation of the root certificate in the trust store of the systems in your infrastructure, effectively marking it as trusted.
Thus, while revocation checks are a critical aspect of PKI, Root CAs operate on a basis of inherent trust, bypassing the usual need for such checks. Keeping abreast of the best practices in managing Root CA revocation settings is essential to maintaining a secure and functioning PKI environment.
Looking ahead
It is imperative to keep an eye on the horizon to anticipate future advancements and shifts in technology. From enhanced security protocols to a new generation of cryptographic standards, in an ever-evolving cybersecurity landscape.
Introduction to CRYSTALS-Kyber
Navigating the ongoing advancements in cryptography, it is vital to spotlight emerging cryptographic algorithms that are poised to play a significant role in the future of secure communications. One such algorithm is CRYSTALS-Kyber, a lattice-based cryptographic algorithm. This mechanism was developed as a part of the Cryptographic Suite for Algebraic Lattices (CRYSTALS) project, positioning it at the forefront of the post-quantum cryptography era.
Though the name may stir up images of the famous Kyber crystals from the Star Wars series, the reality is far more grounded yet equally fascinating. This algorithm, designed to be resistant to attacks from quantum computers, represents a quantum leap towards more secure cryptographic practices in a world anticipating the advent of quantum computing.
Potential future developments in cryptography
As we stand on the cusp of a new era in cryptography, propelled by advancements in quantum computing, it is imperative to look towards future developments that could redefine the security landscape.
While ECC and RSA have served as reliable staples in the cryptographic community, the entrance of quantum computing paints a complex picture where these stalwarts might find themselves susceptible to unprecedented levels of attacks. It heralds a shift towards post-quantum cryptographic algorithms, like CRYSTALS-Kyber, which are designed to be quantum-resistant, providing a fortress of security in a quantum computing age.
Apart from the advent of quantum-resistant algorithms, we may also witness enhancements in existing cryptographic suites, with institutions continuously working towards updating and fortifying existing security protocols to meet the demands of the evolving threat landscape.
Looking forward, it is vital to keep abreast of developments in the cryptographic space, as it undergoes a transformation influenced by rapid technological advancements, offering a glimpse into a future where security and innovation walk hand in hand.
Choosing the key Length and validity period: The conclusion
In this deep dive into key lengths and cryptographic algorithms, I delved into crucial facets of RSA and ECC. Drawing from everything that I wrote, it’s evident that crafting a cryptographic strategy entails a fine balance between security requisites and compatibility needs. As I round off this part of the series, I would like to present you a compact advisory that encapsulates the recommendations drawn from my research and experience:
- RSA key length and recommended validity period:
- 1024 bits: Not Suitable for this day and age, simply don’t use it anymore.
- 2048 bits: A popular choice for a wide array of organizations, recommended to have a validity period not surpassing 2 years for non critical data, maximum of 1 year is preferred.
- 4096 bits: Ideal for securing sensitive information with a validity period that should not exceed 16 years, keeping in line with contemporary security advisories.
- Root CA, Enterprise CA, and leaf certificate recommendations:
- Root CA:
- Key length: 4096 bits
- Validity period: Up to 20 years, aligning with the strategy of a secure and long-lasting foundation. It’s suggested to adhere to recommendations such as the one from Microsoft, which advises a maximum validity period of 16 years.
- Enterprise CA:
- Key length: Minimum 3072 bits (when used after 2030 (NIST)), the German BSI however recommends this key length usage for anything after 2022. If possible and the devices receiving the certificates are compatible, consider using 4096 bits as well.
- Validity period: Up to 10 years, offering a balanced approach to security and administrative overhead.
- Leaf Certificates:
- Key length: Decided based on the specific use-case requirements, generally a minimum of 2048 bits.
- Validity period: Typically shorter than the issuing CA, often set to 1 or maximum 2 years to ensure security and facilitate smooth certificate management processes.
- Root CA:
- Cryptographic transition advisory:
- Current RSA users: Retain the RSA setup to prioritize compatibility and forefend potential compatibility issues.
- New implementations: For those contemplating a fresh setup, it’s advised to defer transitioning to ECC if not already in use, and await the arrival of quantum-resistant algorithms to make a fortified and future-proof choice.
- Periodic evaluation:
- Every 5 years: It is prudent to undertake a meticulous evaluation of your cryptographic strategy every 5 years to align with the evolving landscape of cryptographic security and ensure sustained robustness against emerging threats.
Note! Although a Microsoft CA can generate RSA keys up to 16384 bits, it’s computational not feasible to use these keys. If there’s a necessity to use stronger keys, consider moving to ECC.
By grounding your cryptographic strategy in the well-established RSA framework, you pave the way for a secure and harmonious system. This pathway not only ensures robust security but grants the flexibility to seamlessly adapt to the imminent wave of cryptographic transformations leveraging quantum-resistant algorithms. Remember, the goal is to foster a security environment that stands tall against threats, both present and future, by making informed and foresighted decisions.
How did I not come across this brilliant article before… (sad face).
Thanks.
I’ve been trying to find PKI educators to have a atleast “intermidiate” level of training for IT staff, but seems everyone is talking “cloud this and cloud that” and it is really hard to find ‘good, experienced’ educators in MS PKI.
Micheal, hope future generation writes sonnets in your name.
Thanks so much for that feedback! Really appreciate it and Yes I agree that the industry is jumping from hype to hype. I’m planning on a few blog posts more on the subject, but I just need to find the time. Thanks again.