COMP 6660 · Enterprise Cybersecurity Asymmetric Cryptography

00 Introduction

Symmetric cryptography is fast and efficient, but it has a fatal flaw at enterprise scale: both parties must share the same secret key, and there is no obvious way to deliver that key securely without already having a secure channel. Asymmetric cryptography solves this problem.

The idea behind asymmetric cryptography is elegant and — when it was first proposed in the mid-1970s — revolutionary. Instead of a single shared key, each party has a key pair: a public key that can be freely distributed, and a private key that is kept secret. The two keys are mathematically related, such that data encrypted with the public key can only be decrypted with the private key. Because the public key can be shared openly, the key distribution problem disappears.

The consequences of this idea extend far beyond encryption. Digital signatures — the mechanism through which enterprises verify the authenticity of software, certificates, and messages — depend on asymmetric cryptography. Certificate infrastructure — the trust fabric of the web and of enterprise identity — depends on asymmetric cryptography. Modern secure protocols such as TLS, SSH, and IPsec depend on asymmetric cryptography to establish trust and negotiate keys. Without asymmetric cryptography, the digital economy as we know it would not exist.

This lesson examines the principal asymmetric algorithms — RSA, elliptic-curve cryptography, and Diffie–Hellman key exchange — and the criteria for selecting among them. It explains how asymmetric and symmetric cryptography work together in hybrid systems, examines the enterprise contexts in which asymmetric cryptography is most critical, and closes with the emerging challenge of quantum computing, which threatens the mathematical foundations on which RSA and elliptic-curve cryptography rest.

01 Learning objectives

By the end of this lesson you should be able to:

These objectives contribute to Unit 2 outcome U2.1 (cryptographic principles), and to Module 1 outcomes M1.9 and M1.10. See the Unit 2 learning outcomes page for the full mapping.

02 The key distribution problem

Symmetric cryptography, as Lesson 2.2 established, requires both parties to possess the same secret key. This creates a problem that has no obvious solution within the symmetric framework itself.

Why symmetric key distribution is hard

Consider two parties who wish to communicate securely using symmetric encryption. They must first establish a shared secret key. The channel through which they exchange that key must itself be secure — otherwise an attacker who intercepts the key can decrypt all subsequent communication. But the secure channel that would be needed to exchange the key is exactly what they are trying to establish.

This is the circularity at the heart of symmetric cryptography at scale. There are only three ways out:

• Physical key exchange. The parties meet in person and exchange keys physically. This works for a small number of parties but does not scale to thousands of users, systems, and services.
• A trusted intermediary. A central authority distributes keys to all parties. This works within an organisation but creates a single point of failure and does not extend easily across organisational boundaries.
• Asymmetric cryptography. The parties use public-key cryptography to establish a shared secret key over an untrusted channel. This is the approach that made modern secure communication possible.

The scale problem

The distribution problem is compounded by scale. If every pair of communicating parties needs a distinct symmetric key, an enterprise with N parties needs approximately N²/2 keys. The table below shows how quickly this becomes unmanageable.

Even with a trusted key distribution centre, managing pairwise keys at this scale is operationally complex and creates a central point of compromise. Asymmetric cryptography sidesteps the problem entirely by eliminating the need for pairwise shared secrets.

03 Public-key cryptography

Public-key cryptography uses a pair of mathematically related keys instead of a single shared key. The relationship between the two keys is asymmetric — knowledge of one does not readily yield knowledge of the other — which is what gives the approach its name.

The key pair

Two operations: encryption and signing

Public-key cryptography supports two distinct operations, which use the keys in opposite directions:

The distinction matters. Encryption uses the recipient's keys — the sender encrypts with the recipient's public key so that only the recipient can decrypt. Signing uses the sender's keys — the sender signs with their own private key so that anyone holding the sender's public key can verify. Confusing the two is a common conceptual error and, in implementation, a serious vulnerability.

The mathematical foundation: trapdoor functions

Public-key cryptography relies on trapdoor functions — mathematical functions that are easy to compute in one direction but infeasible to reverse without additional information (the "trapdoor"). For example, multiplying two large prime numbers is easy; factoring the product back into the two primes is hard. This asymmetry is what allows a public key to reveal enough information to encrypt but not enough to decrypt.

The difficulty of the underlying mathematical problem determines the security of the algorithm. When that problem becomes tractable — through mathematical advance, computing power, or a new class of algorithm — the cryptographic algorithm built on it becomes insecure. This is precisely the situation that quantum computing threatens (Section 9).

04 RSA

Design and history

RSA was the first publicly available public-key cryptosystem. Its publication in 1977 made the concept of public-key cryptography practical, and RSA became the foundation of early secure communication on the internet. It remains in widespread use nearly five decades later, though its role has shifted as more efficient alternatives have emerged.

RSA's security rests on the integer factorisation problem: given a large number that is the product of two primes, finding those primes is computationally infeasible for sufficiently large numbers. RSA keys are generated by selecting two large primes, computing their product (part of the public key), and deriving the private key from knowledge of the primes. An attacker who could factor the public modulus could derive the private key.

Key lengths

RSA key lengths are measured in bits and are much longer than symmetric key lengths for equivalent security. The following table shows current guidance:

2048-bit RSA is the minimum acceptable key length in current practice, but guidance increasingly recommends 3072 bits or larger for new deployments. The difference in performance between 2048 and 3072 is modest; the difference in security margin is meaningful, particularly for long-lived keys.

Strengths of RSA

• Maturity. RSA has been extensively analysed for nearly five decades. Its security properties are well understood.
• Universal support. RSA is implemented in every modern cryptographic library, operating system, and protocol. Compatibility is rarely an issue.
• Dual use. RSA supports both encryption and digital signatures with the same key pair — a flexibility that has contributed to its widespread deployment.
• Well-understood security assumptions. The factorisation problem is a well-studied mathematical problem; its difficulty is understood.

Weaknesses of RSA

• Large key sizes. RSA requires much longer keys than elliptic-curve cryptography for equivalent security, resulting in larger certificates, more bandwidth, and greater storage requirements.
• Slow performance. RSA operations are computationally expensive, particularly decryption and signing. This limits its use to key exchange and signatures rather than bulk data.
• Implementation pitfalls. RSA is vulnerable to specific implementation errors — improper padding, insufficient randomness in key generation, and side-channel attacks — that have produced real vulnerabilities.
• Quantum vulnerability. RSA is broken by Shor's algorithm running on a sufficiently powerful quantum computer. This is the most significant long-term concern.

Common RSA pitfalls

• Weak padding. RSA without proper padding — or with the obsolete PKCS#1 v1.5 padding — is vulnerable to a range of attacks. Modern implementations should use OAEP for encryption and PSS for signatures.
• Small key lengths. RSA keys below 2048 bits should be considered compromised. Some legacy systems still use 1024-bit keys.
• Shared prime factors. Keys generated with insufficient randomness may share prime factors with other keys, allowing an attacker who collects many public keys to factor some of them.
• Side-channel attacks. RSA implementations that leak information through timing or power consumption can be attacked even when the algorithm itself is sound.

05 Elliptic-Curve Cryptography (ECC)

Design and history

The use of elliptic curves in cryptography was independently proposed by Neal Koblitz and Victor Miller in 1985. ECC's security rests on the elliptic-curve discrete logarithm problem — determining the scalar multiple of a point on an elliptic curve given the curve and the result. This problem is believed to be substantially harder than the integer factorisation problem on which RSA is based, which is why ECC achieves equivalent security with much smaller keys.

ECC's adoption was initially slow, in part because the mathematics is more complex and in part because RSA was already entrenched. Over the past two decades, however, ECC has become increasingly common — particularly on constrained devices, in mobile applications, and in modern protocols. TLS 1.3, for example, favours ECC over RSA in its recommended cipher suites.

Key lengths

The key-size advantage of ECC is substantial. The table below compares equivalent security levels:

A 256-bit ECC key provides security equivalent to a 3072-bit RSA key — a difference that matters significantly for performance, certificate size, and storage. This is why ECC is increasingly preferred for new deployments, particularly in bandwidth-constrained or storage-constrained environments.

Common elliptic curves

Unlike RSA, which has a single underlying algorithm, ECC is a family of algorithms defined over a choice of curves. The curves matter: not all curves are equally secure, and some have been suspected of harbouring weaknesses. The following curves are widely used:

The choice of curve matters for cryptographic assurance. Curves published by NIST have been subjected to significant scrutiny; some have been suspected of containing weaknesses known to the designers (though no practical attacks have been demonstrated against the recommended curves). Curves such as Curve25519, designed without government involvement, are often preferred where independence from such concerns is important.

Strengths of ECC

• Smaller keys. Equivalent security with substantially smaller keys, reducing bandwidth, storage, and certificate size.
• Better performance. ECC operations are generally faster than RSA operations of equivalent security, particularly for signing and key agreement.
• Suited to constrained environments. Smaller keys and lower computational requirements make ECC well-suited to mobile devices, IoT devices, and embedded systems.
• Modern protocol preference. TLS 1.3 and modern cryptographic libraries favour ECC for key exchange and signatures.

Weaknesses of ECC

• More complex mathematics. ECC is harder to understand than RSA, which means implementation errors can be subtler and harder to detect.
• Implementation pitfalls. ECC implementations are vulnerable to specific attacks — invalid curve attacks, side-channel attacks, weak randomness in key generation — that have produced real vulnerabilities.
• Curve choice matters. Not all elliptic curves are equally secure. Some curves (notably certain binary-field curves) have been deprecated or are no longer recommended.
• Quantum vulnerability. Like RSA, ECC is broken by Shor's algorithm on a sufficiently powerful quantum computer.

06 Diffie–Hellman key exchange

Design and history

Diffie–Hellman was published in 1976 by Whitfield Diffie and Martin Hellman, a year before RSA. It was the first public demonstration that two parties could establish a shared secret over an untrusted channel without prior contact — an idea that had previously been considered impossible. Its publication launched the modern era of public-key cryptography.

Diffie–Hellman is a key agreement protocol rather than a general encryption algorithm. It does not encrypt data; it establishes a shared secret key that can then be used for symmetric encryption. Its security rests on the discrete logarithm problem — determining the exponent given the base and the result.

How it works (conceptually)

The protocol works as follows. Two parties, Alice and Bob, agree on public parameters. Each selects a private value and computes a public value from it. They exchange public values. Each then combines their own private value with the other party's public value to compute a shared secret. Because of the mathematical properties involved, both parties arrive at the same shared secret, which an eavesdropper cannot compute from the public values alone.

The protocol is elegant because it requires no prior shared secret and no trusted third party. Both parties can be certain that the shared secret is known only to them (subject to authentication, discussed below) — a property that would have seemed magical to earlier cryptographers.

Variants

• Classical Diffie–Hellman. Uses modular exponentiation over finite fields. Requires relatively large keys for adequate security.
• Elliptic-Curve Diffie–Hellman (ECDH). Uses elliptic-curve mathematics. Provides equivalent security with much smaller keys and better performance. Increasingly the default choice.
• Ephemeral Diffie–Hellman (DHE, ECDHE). Generates a fresh key pair for each session, providing forward secrecy — the property that compromise of a long-term key does not compromise past sessions. ECDHE is the standard for modern TLS.

The authentication problem

Diffie–Hellman by itself does not authenticate the parties. An attacker who can intercept the exchange can establish separate shared secrets with each party, then relay messages between them — a man-in-the-middle attack. Each party believes they are communicating with the other, but both are communicating with the attacker.

This weakness is addressed by combining Diffie–Hellman with authentication. In TLS, for example, the server authenticates using a digital signature (based on RSA or ECDSA), proving its identity to the client. The Diffie–Hellman exchange then establishes the session key, with the assurance that the client is genuinely communicating with the authenticated server.

This combination — key agreement plus authentication — is the standard pattern in modern secure protocols. Diffie–Hellman alone is insufficient; Diffie–Hellman with authentication is the basis of secure communication.

Forward secrecy

A particularly valuable property of ephemeral Diffie–Hellman is forward secrecy. Because a fresh key pair is generated for each session and discarded afterward, compromise of a long-term private key does not allow an attacker to decrypt past sessions. The attacker would need to have recorded the session and then compromise the ephemeral key, which has already been discarded.

Forward secrecy is now considered essential for enterprise systems that handle sensitive data. Without it, compromise of a server's private key retroactively compromises all past communication — a catastrophic outcome in a breach. Modern protocol configurations (TLS 1.3, for example) require forward secrecy by default.

07 Comparing asymmetric algorithms

RSA, elliptic-curve cryptography, and Diffie–Hellman are not alternatives in the sense that one replaces the other. They serve overlapping but distinct purposes, and the choice among them depends on the operation required, the performance constraints of the environment, and the compatibility requirements of the system.

Selection guidance

The following guidance reflects current best practice:

• For key agreement: Use ECDHE (ephemeral elliptic-curve Diffie–Hellman) where supported. It provides forward secrecy, is efficient, and is the standard choice in TLS 1.3.
• For digital signatures: Use ECDSA with a modern curve (P-256, P-384, or Curve25519) where supported. RSA with PSS padding and key lengths of 3072 bits or larger remains acceptable for compatibility.
• For encryption of bulk data: Do not use asymmetric cryptography directly. Use symmetric encryption (AES) with keys established via asymmetric key agreement.
• For certificates: ECDSA certificates are smaller and faster; RSA certificates remain more widely supported in legacy systems. The choice depends on the ecosystem.
• For constrained environments: ECC is strongly preferred due to its smaller key sizes and lower computational requirements.
• For long-lived keys: Consider the quantum implications (Section 9) and plan for migration.

What to avoid

• RSA below 2048 bits. Deprecated; migration to larger keys or to ECC is required.
• RSA without modern padding. PKCS#1 v1.5 padding for encryption is deprecated; use OAEP. PKCS#1 v1.5 for signatures is deprecated; use PSS.
• Elliptic curves not recommended by standards bodies. Some curves have been deprecated; use P-256, P-384, or Curve25519.
• Diffie–Hellman without authentication. Vulnerable to man-in-the-middle attack; always pair with authentication.
• Non-ephemeral key agreement. Does not provide forward secrecy; use ephemeral variants.

08 Hybrid cryptography

Asymmetric cryptography is slow — orders of magnitude slower than symmetric cryptography. It is also mathematically limited: an RSA key of 2048 bits cannot directly encrypt a message longer than 245 bytes. This is why real-world cryptographic systems do not use asymmetric cryptography to protect bulk data. Instead, they combine asymmetric and symmetric cryptography in a hybrid scheme.

The hybrid pattern

1. Establish trust Parties authenticate each other using digital signatures or certificates. The server proves its identity to the client (or vice versa).
2. Negotiate a shared secret Using Diffie–Hellman (typically ECDHE) or by transporting a symmetric key encrypted with a public key, the parties establish a shared secret that only they know.
3. Derive symmetric keys From the shared secret, the parties derive symmetric keys for encryption and integrity using a key-derivation function.
4. Protect the data with symmetric cryptography All subsequent data is protected using symmetric encryption (typically AES-GCM), exploiting its speed and efficiency.

This is exactly the pattern used by TLS, SSH, IPsec, and almost every other secure protocol. When you see "encryption" in an enterprise context, the underlying mechanism is almost always hybrid.

Why the hybrid approach works

The hybrid approach exploits the strengths of each family:

• Asymmetric cryptography solves the key distribution problem. Parties can establish a shared secret without prior contact or a secure channel.
• Symmetric cryptography handles the volume. Once a shared secret is established, symmetric encryption protects the actual data with the speed and efficiency the workload requires.
• Forward secrecy is provided by ephemeral key agreement. Because the session key is generated freshly and discarded, past sessions remain secure even if long-term keys are later compromised.

An example: TLS 1.3

A TLS 1.3 handshake illustrates the hybrid pattern in a modern protocol:

• The client sends a ClientHello with supported cipher suites and a key share for Diffie–Hellman.
• The server responds with its ServerHello, its own key share, and its certificate.
• The client verifies the server's certificate against trusted authorities, authenticating the server.
• Both parties compute the shared secret from their key shares using ECDHE.
• Session keys are derived from the shared secret and used for symmetric encryption of application data.
• The server signs the handshake transcript, proving possession of the private key corresponding to its certificate.

The result is a secure channel in which the parties have authenticated each other, established a shared secret through ephemeral key agreement, and are protecting data with symmetric cryptography. Every modern secure connection works this way in essence.

09 Asymmetric cryptography in the enterprise

Asymmetric cryptography is present in almost every enterprise system, though it rarely appears directly to users. The following table shows where it is found and what it provides.

Common enterprise patterns of weakness

• Legacy RSA key lengths. 1024-bit RSA keys still present in some systems, even though they are no longer considered adequate.
• Weak TLS configurations. Support for deprecated protocol versions (TLS 1.0, 1.1) or weak cipher suites enabling downgrade attacks.
• Certificate validation failures. Applications that accept any certificate, ignore hostname mismatches, or fail to check revocation.
• Shared or mismanaged private keys. Private keys stored in code, configuration files, or shared locations without adequate protection.
• Self-signed certificates in production. Often indicating that certificate management has been neglected.
• Missing forward secrecy. Key agreement configurations that do not use ephemeral variants, leaving past sessions exposed if long-term keys are compromised.
• Unmanaged certificate expiry. Certificates allowed to expire, causing outages, or renewed reactively rather than managed proactively.

Assessing enterprise asymmetric cryptographic posture

Useful assessment questions include:

• What key lengths are in use? Confirm RSA keys are 2048 bits or larger; preferably 3072. Confirm ECC keys use recommended curves (P-256, P-384, Curve25519).
• What protocols and versions are supported? Confirm TLS 1.2 and 1.3 only; no TLS 1.0 or 1.1. Confirm SSH uses modern configurations.
• Is forward secrecy provided? Confirm ECDHE (or DHE) is negotiated by default in TLS and SSH configurations.
• How are private keys protected? Confirm keys are stored in HSMs, key management services, or other protected storage — not in code, configuration, or shared locations.
• How are certificates managed? Confirm inventory, monitoring for expiry, and process for renewal. Confirm certificate validation is enforced by applications.
• Is there a cryptographic inventory? Can the enterprise enumerate the asymmetric keys and certificates it relies on, who owns them, and what they protect?
• Is there cryptographic agility? Can the enterprise migrate to new algorithms and key lengths when needed without redesign?

10 The quantum horizon

RSA and elliptic-curve cryptography rest on mathematical problems that are believed to be computationally infeasible to solve with classical computers. Quantum computing changes that assumption — and the implications for enterprise cryptography are significant.

Shor's algorithm

In 1994, mathematician Peter Shor published an algorithm for quantum computers that solves both integer factorisation and discrete logarithms in polynomial time. This means that a sufficiently powerful quantum computer running Shor's algorithm would break RSA and elliptic-curve cryptography entirely — not merely weaken them, but render them unusable.

The practical significance of this depends on whether and when such quantum computers will exist. Current quantum computers are far from the scale required to break real-world cryptographic keys. Estimates of the timeline vary widely, from a decade to several decades, and are the subject of ongoing debate. But the direction of travel is clear: current asymmetric cryptography has a finite lifetime.

Grover's algorithm

A related algorithm, published by Lov Grover in 1996, provides a quadratic speedup for unstructured search problems. Its effect on symmetric cryptography is to halve the effective key length: a 128-bit symmetric key provides only 64 bits of security against a quantum adversary using Grover's algorithm.

The consequence for symmetric cryptography is more manageable than for asymmetric. Doubling key lengths restores security: AES-256 provides adequate margin against Grover's algorithm, as does SHA-384 or SHA-512 for hashing. Symmetric cryptography is quantum-vulnerable but not quantum-broken.

Post-quantum cryptography

Post-quantum cryptography (sometimes called quantum-resistant or quantum-safe cryptography) refers to cryptographic algorithms believed to be resistant to attack by both classical and quantum computers. These algorithms are based on mathematical problems that are not known to be solvable by quantum algorithms — lattice problems, hash-based constructions, code-based cryptography, and multivariate polynomial systems.

In 2022 and 2023, NIST announced the first standards-track selections for post-quantum cryptography, including CRYSTALS-Kyber for key encapsulation and CRYSTALS-Dilithium, Falcon, and SPHINCS+ for digital signatures. These algorithms are expected to become the basis for future cryptographic standards, and implementations are becoming available in major cryptographic libraries.

The "harvest now, decrypt later" threat

A particularly important consideration is that adversaries can record encrypted traffic today and decrypt it once quantum computers become available. This is known as the harvest now, decrypt later threat. For data with long confidentiality requirements — classified information, personal data with decades of sensitivity, intellectual property — the quantum threat is not merely future; it is potentially already present.

The implication for enterprises is that migration to post-quantum cryptography should be planned rather than deferred. The migration will take years, and enterprises that begin planning now will be better positioned than those that wait. The governance implications are examined in Module 3, Lesson 6.10.

What enterprises should do now

• Inventory cryptographic dependencies. Identify where RSA and ECC are used, and what would need to change in a migration. This is the foundation of any post-quantum plan.
• Prioritise cryptographic agility. Ensure systems can migrate to new algorithms without redesign. Systems with hard-coded algorithms will be difficult and expensive to migrate.
• Use strong symmetric cryptography. AES-256 provides quantum resistance with adequate margin; AES-128 does not. Where symmetric key lengths are being chosen today, AES-256 should be preferred for long-lived data.
• Extend key lengths for asymmetric cryptography where possible. Larger RSA keys and larger elliptic-curve keys provide no protection against Shor's algorithm, but they do provide additional margin against classical attack and extend the window before migration becomes urgent.
• Track post-quantum standards. NIST and other standards bodies are publishing post-quantum algorithms. Enterprises should be aware of the emerging standards and plan for their adoption.
• Plan for migration. Post-quantum migration is a multi-year effort. Enterprises that begin planning now will be better positioned.

11 Key concepts

The terms below are used throughout the course. Capture them in your own words as you work through the lesson.

Asymmetric cryptography

Cryptography using a mathematically related key pair — a public key that can be distributed openly and a private key that is kept secret. Solves the key distribution problem that limits symmetric cryptography.

Public key / private key

A mathematically related pair used in asymmetric cryptography. The public key can be shared openly; the private key must remain secret. Data encrypted with the public key can only be decrypted with the private key, and vice versa.

Key distribution problem

The challenge of securely delivering shared symmetric keys to parties who need them, without a pre-existing secure channel. Asymmetric cryptography solves this problem by eliminating the need for pairwise shared secrets.

Trapdoor function

A mathematical function that is easy to compute in one direction but infeasible to reverse without additional information. Underlies all public-key cryptography.

RSA

The oldest and most widely deployed public-key algorithm, published in 1977. Security based on the integer factorisation problem. Supports encryption and digital signatures. Key lengths of 2048 bits or larger; preferably 3072.

Elliptic-curve cryptography (ECC)

A family of public-key algorithms based on the elliptic-curve discrete logarithm problem. Provides equivalent security to RSA with substantially smaller keys and better performance.

ECDSA

Elliptic-Curve Digital Signature Algorithm. A digital signature scheme based on elliptic-curve cryptography. Widely used in TLS, SSH, and code signing.

Diffie–Hellman key exchange

A key agreement protocol published in 1976 that allows two parties to establish a shared secret over an untrusted channel. The first publicly disclosed public-key algorithm.

ECDH / ECDHE

Elliptic-Curve Diffie–Hellman. The elliptic-curve variant of Diffie–Hellman key agreement. ECDHE (the ephemeral variant) provides forward secrecy and is the standard for modern TLS.

Forward secrecy

The property that compromise of a long-term private key does not allow decryption of past sessions. Provided by ephemeral key agreement (ECDHE or DHE). Considered essential for modern secure communication.

Man-in-the-middle attack

An attack in which an adversary intercepts communication between two parties and relays messages between them, convincing each that they are communicating directly with the other. Diffie–Hellman without authentication is vulnerable; combining key agreement with authentication prevents the attack.

Hybrid cryptography

The combination of asymmetric and symmetric cryptography used by modern secure protocols: asymmetric for authentication and key agreement, symmetric for bulk data protection.

Certificate

A digitally signed statement binding a public key to an identity. Issued by a certificate authority; used to establish trust in public-key infrastructure. Examined in detail in Lesson 2.4.

Post-quantum cryptography

Cryptographic algorithms believed to be resistant to attack by both classical and quantum computers. Based on mathematical problems not known to be solvable by quantum algorithms. Standards-track algorithms are emerging (CRYSTALS-Kyber, CRYSTALS-Dilithium, and others).

Shor's algorithm

A quantum algorithm that solves integer factorisation and discrete logarithms in polynomial time. Breaks RSA, elliptic-curve cryptography, and Diffie–Hellman on a sufficiently powerful quantum computer.

Grover's algorithm

A quantum algorithm providing quadratic speedup for unstructured search. Halves the effective key length of symmetric cryptography. Countered by doubling key lengths (AES-256).

Harvest now, decrypt later

A threat model in which an adversary records encrypted traffic today and decrypts it once quantum computers become available. Justifies planning for post-quantum migration now rather than waiting.

12 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 1. They are not graded, but completing them will improve the quality of your forum contribution.

13 Self-check

Answer the questions below before moving to Lesson 2.4. If you cannot answer a question confidently, revisit the corresponding section.

14 Summary

This lesson has examined asymmetric cryptography — the technology that made modern enterprise trust infrastructure possible. The essential points are:

• Asymmetric cryptography solves the key distribution problem. By using a key pair — a public key that can be shared openly and a private key that is kept secret — it eliminates the need for a secure channel to distribute keys.
• Public-key cryptography supports two distinct operations. Encryption uses the recipient's keys to protect confidentiality; signing uses the sender's keys to provide authenticity, integrity, and non-repudiation. Confusing the two is a serious error.
• RSA is the oldest and most widely deployed asymmetric algorithm. Based on integer factorisation. Key lengths of 2048 bits minimum; 3072 bits or larger recommended. Both encryption and signatures. Slower and larger keys than ECC.
• Elliptic-curve cryptography provides equivalent security with much smaller keys. A 256-bit ECC key matches a 3072-bit RSA key. Better performance, smaller certificates, suited to constrained environments. Increasingly the preferred choice for new deployments.
• Diffie–Hellman is a key agreement protocol, not an encryption or signature scheme. It allows two parties to establish a shared secret over an untrusted channel. Ephemeral variants (DHE, ECDHE) provide forward secrecy. Requires authentication to prevent man-in-the-middle attacks.
• Hybrid cryptography is the standard in practice. Modern secure protocols combine asymmetric cryptography (for authentication and key agreement) with symmetric cryptography (for bulk data protection). Forward secrecy is provided by ephemeral key agreement.
• Enterprise assessment focuses on configuration, not algorithm choice. Key lengths, protocol versions, forward secrecy, private key protection, and certificate management matter more than which algorithm is used.
• The quantum horizon is real. RSA, ECC, and Diffie–Hellman are broken by Shor's algorithm on a sufficiently powerful quantum computer. Migration to post-quantum cryptography is inevitable. The most useful actions today are to build cryptographic agility, inventory dependencies, and plan for migration.

These ideas prepare for Lesson 2.4, which examines digital signatures and public key infrastructure — where the cryptographic primitives introduced here are assembled into the trust infrastructure on which enterprise identity and secure communication depend.