Asymmetric Cryptography and Key Exchange

Introduction and Context

Cryptography enables confidentiality, integrity, authentication, and non-repudiation in digital systems. Symmetric cryptography, discussed in earlier foundations, uses one shared secret key for encryption and decryption. It is efficient, but securely distributing that shared key is difficult when communicating parties have not previously met. Asymmetric cryptography addresses this distribution problem by using a mathematically related pair of keys: a public key that may be distributed openly and a private key that must remain secret.

Asymmetric systems do not replace symmetric cryptography. Modern protocols normally use both: asymmetric cryptography authenticates parties and establishes a temporary symmetric session key; symmetric cryptography then protects the bulk data efficiently. This combination is called hybrid cryptography and is used in TLS, secure messaging, virtual private networks, and many identity systems.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish public keys, private keys, ciphertext, signatures, and certificates;
• explain encryption and digital-signature operations using asymmetric keys;
• describe RSA, Diffie–Hellman, and elliptic-curve cryptography (ECC);
• compare asymmetric and symmetric cryptography in terms of purpose, performance, and security assumptions;
• identify implementation risks such as weak randomness, poor validation, key reuse, and lack of authentication;
• explain how hybrid protocols apply these techniques in professional systems.

Public and Private Keys

An asymmetric cryptosystem provides two linked keys. The public key is intended for distribution. The private key is confidential and is normally protected by an operating-system credential, hardware security module (HSM), smart card, or secure enclave.

Two distinct uses must be separated conceptually:

1. Confidentiality: A sender encrypts using the recipient’s public key. Only the recipient, who possesses the corresponding private key, should be able to decrypt.
2. Authentication and integrity: A signer uses a private key to create a digital signature. Anyone with the corresponding public key can verify that the signature was produced by that private key and that the signed data has not changed.

A signature is not simply “encryption with the private key.” Secure signature schemes have their own encoding, hashing, and security definitions. In practice, a system signs a cryptographic hash of a message using a standard signature algorithm and verifies the result with the public key.

Essential terminology

• Plaintext: Original readable or structured data.
• Ciphertext: Encrypted data intended to conceal plaintext.
• Key pair: A mathematically related public key and private key.
• Cryptographic hash: A one-way function producing a fixed-length digest.
• Digital signature: A verifiable cryptographic proof associated with a message and private key.
• Certificate: A signed binding between an identity and a public key.
• Certificate authority (CA): An entity trusted to issue and sign certificates.
• Key exchange: A protocol allowing parties to establish shared secret material.
• Forward secrecy: Protection of past sessions even if a long-term private key is later compromised.
• Hybrid encryption: Use of asymmetric cryptography for key establishment and symmetric cryptography for data protection.

The Public-Key Model and Trust

Possessing a public key does not automatically prove whose key it is. An attacker could substitute their own public key and conduct a man-in-the-middle attack. Public-key infrastructures (PKIs) address this problem using certificates, certificate chains, trusted roots, identity validation, revocation mechanisms, and endpoint verification.

A certificate commonly contains a subject identity, public key, issuer, validity period, permitted purposes, serial number, and the CA’s signature. A verifier checks the CA signature, builds a chain to a trusted root, confirms validity dates, checks key-usage constraints, and verifies that the certificate applies to the intended hostname or identity. Trust stores must therefore be governed carefully; adding an untrusted root can undermine many secure connections.

RSA

RSA is an asymmetric algorithm based on the computational difficulty of factoring a large composite integer. It uses two large primes, usually denoted p and q. The modulus is:

The Euler totient for distinct primes is:

A public exponent e is selected so that:

The private exponent d is the modular inverse of e modulo φ(n):

The public key is (n,e), and the private key contains d and, in practical implementations, additional parameters derived from p and q. RSA encryption is conceptually represented as:

and decryption as:

Here m is a suitably encoded message representative, c is ciphertext, and all operations are modular. These equations describe the mathematical core, not a safe complete implementation. Real systems must use standardized randomized padding such as RSA-OAEP for encryption and RSA-PSS for signatures. Textbook RSA and deterministic, unpadded RSA are insecure.

Small illustrative RSA example

This example demonstrates the arithmetic only and is not secure. Let p = 5 and q = 11. Then n = 55 and φ(n) = 40. Choose e = 3, since gcd(3,40) = 1. The inverse is d = 27, because 3 × 27 = 81 ≡ 1 (mod 40). For message representative m = 2:

Decryption gives:

The tiny primes make this system trivial to break. Production RSA requires approved key sizes, secure random generation, side-channel-resistant libraries, and safe padding. Current security policy should determine the exact key size; new designs commonly prefer RSA keys of at least 2048 bits when RSA is required, while stronger or longer-term requirements may require larger keys.

RSA limitations and risks

RSA operations are computationally expensive compared with symmetric encryption and produce relatively large keys and signatures. Common failures include insufficient key size, factorable or repeated primes, weak random number generation, use of textbook RSA, incorrect padding validation, private-key exposure, and timing or power-analysis leakage. Implementers should use vetted libraries rather than writing modular arithmetic or padding code themselves.

Diffie–Hellman Key Exchange

Diffie–Hellman (DH) allows two parties to derive a common secret over a public channel without transmitting that secret directly. In a simplified finite-field version, public parameters include a large prime p and a generator g. Alice selects a private random value a and sends:

Bob selects b and sends:

Alice computes:

Bob computes:

Both values are equal because:

The security assumption is that calculating the shared value from public parameters and exchanged values is computationally difficult, generally related to the discrete logarithm problem. The raw shared value should not normally be used directly as an encryption key. A key-derivation function (KDF) should derive independent keys, incorporating context, transcript data, and negotiated parameters.

Authentication and forward secrecy

Unauthenticated DH is vulnerable to a man-in-the-middle attack: an attacker can establish one secret with Alice and another with Bob. Authentication is therefore essential. Protocols may authenticate the exchange using certificates, digital signatures, pre-shared keys, or an authenticated public-key infrastructure.

Ephemeral Diffie–Hellman uses fresh temporary private values for each session. When correctly implemented and erased, it provides forward secrecy: compromise of a long-term signing key does not automatically reveal previously recorded session contents. Static DH reuses a private value and provides weaker protection.

Finite-field DH requires safe parameter selection, subgroup validation, and protection against small-subgroup attacks. Modern protocols often prefer elliptic-curve Diffie–Hellman (ECDH), including ephemeral ECDH (ECDHE).

Elliptic-Curve Cryptography

ECC uses algebraic operations on points of an elliptic curve over a finite field. A simplified curve equation is:

where a, b, and prime p define the curve and field. The curve parameters must satisfy a non-singularity condition, commonly expressed as:

The points, together with a point at infinity, form a mathematical group under a defined point-addition operation. A private key is a randomly selected scalar d, and the public key is:

where G is a standard generator point and dG means repeated scalar multiplication. Given G and Q, recovering d is intended to be difficult; this is the elliptic-curve discrete logarithm problem.

ECDH follows the same conceptual pattern. Alice sends Q_A = d_A G, Bob sends Q_B = d_B G, and both derive:

The shared point is passed through a KDF rather than used directly. ECDSA and EdDSA are examples of elliptic-curve signature systems, although their security properties and implementation requirements differ. A curve and protocol must be selected as a complete standardized suite; arbitrary curve construction is unsafe.

ECC offers comparatively small keys and signatures for a similar classical security level, reducing bandwidth and storage. However, ECC is not automatically safer: invalid-point handling, nonce generation, side-channel resistance, library quality, and protocol integration remain critical. Quantum computers capable of running large-scale Shor’s algorithm would threaten both RSA and conventional ECC, motivating post-quantum migration planning.

Symmetric and Asymmetric Cryptography Compared

For N parties, a naïve pairwise symmetric design may require N(N−1)/2 shared relationships. This is a count of unordered pairs, not a universal requirement for every architecture; centralized key-management systems can reduce that operational burden. Asymmetric cryptography reduces the need to pre-share a unique secret with every possible peer, but introduces certificate management, trust decisions, and more complex algorithms.

Hybrid Encryption in Practice

A typical secure connection follows this sequence:

1. The client and server negotiate an approved protocol and cryptographic suite.
2. The server presents a certificate containing its public key.
3. The client validates the certificate and identity.
4. The parties perform authenticated ephemeral DH or ECDH.
5. A KDF derives symmetric encryption and authentication keys from the shared secret and transcript.
6. Bulk traffic is protected using an authenticated-encryption mode, such as AES-GCM or ChaCha20-Poly1305.
7. Fresh nonces are used according to the selected algorithm’s requirements, and keys are rotated or discarded as specified.

This design reflects an important engineering principle: use asymmetric cryptography for what it does well—authentication and key establishment—and symmetric cryptography for high-volume data.

Implementation Risks and Best Practices

Weak or predictable randomness

Private keys, ephemeral values, RSA primes, signature nonces, and encryption nonces require unpredictable randomness. A predictable random-number generator can reveal keys or permit signature attacks. Use the operating system’s cryptographically secure random source or a validated library. Never use timestamps, ordinary pseudo-random functions, usernames, or counters as private-key randomness.

Key and nonce reuse

A private key should have a documented purpose and lifecycle. Reusing an encryption key across incompatible protocols can create cross-protocol attacks. Nonce reuse can be catastrophic for authenticated encryption and can reveal an ECDSA private key when a signing nonce repeats. Follow the exact nonce-generation rules of the chosen algorithm.

Missing authentication

Encryption alone does not prove who is communicating. Certificate validation, hostname checking, signature verification, and transcript binding are essential. Disabling certificate validation “temporarily” creates a serious vulnerability and is especially dangerous in mobile applications, APIs, and internal services.

Poor parameter and input validation

Implementations must reject invalid public points, unacceptable groups, malformed encodings, weak certificates, and unsupported algorithms. Key agreement must validate that the result is not an invalid or trivial value. Protocol negotiation must prevent downgrade attacks.

Side channels and fault attacks

Execution time, cache behaviour, power consumption, electromagnetic emissions, and error messages can reveal secret-dependent information. Use constant-time cryptographic primitives where required, blind RSA operations, avoid detailed cryptographic error messages, and use hardware protection for high-value keys.

Private-key management

Protection includes access control, encryption at rest, secure backup, rotation, revocation, audit logging, separation of duties, and destruction at end of life. HSMs can prevent direct extraction of key material and enforce signing policies. Backups must be protected as carefully as live keys.

Algorithm agility without insecurity

Systems should support controlled migration, but excessive algorithm negotiation can increase attack surface. Prefer a small set of approved, interoperable suites and define deprecation dates. Do not invent proprietary cryptographic algorithms or protocols.

Applied Case: Securing an Online Examination Service

Background

A university operates an online examination platform. Students connect from personal devices, while the service handles login credentials, examination questions, answers, and result records.

Problem

The original prototype used a single symmetric key embedded in the application. Anyone extracting the application could recover the key, impersonate the server, and decrypt recorded traffic. The service also lacked reliable certificate validation and used home-developed encryption code.

Analysis

The system needs server authentication, confidentiality, integrity, and efficient protection for large answer submissions. A single embedded key cannot provide these properties because it is shared among all clients and can be copied. The design also requires forward secrecy so that later compromise of a server credential does not expose archived sessions.

Approach and solution

The institution replaces the prototype with a standards-based TLS deployment. The server uses a CA-issued certificate and a protected private key. Clients validate the certificate chain and hostname. The handshake uses authenticated ephemeral elliptic-curve Diffie–Hellman, with the certificate key used for authentication rather than bulk encryption. A KDF derives traffic keys, and authenticated encryption protects examination data. The server stores long-term keys in an HSM, rotates certificates according to policy, logs administrative key use, and tests revocation and incident-response procedures.

Application-level access control remains necessary: TLS does not decide whether a student may view a particular examination. The service also uses secure session management, least privilege, audit trails, and encrypted backups.

Outcome

The revised design removes the shared embedded secret, provides authenticated connections and forward secrecy, reduces custom cryptographic code, and improves operational accountability. It does not eliminate all risk: compromised endpoints, stolen student credentials, server malware, misconfigured certificate validation, and poor authorization remain possible.

Learning points

• Public-key cryptography solves a distribution and authentication problem, not every security problem.
• Asymmetric and symmetric algorithms should be combined rather than treated as competitors.
• Protocol configuration and lifecycle management are as important as algorithm selection.
• Security controls must include endpoints, identities, authorization, monitoring, and recovery.

Governance, Ethics, and Contemporary Developments

Cryptographic design affects privacy, safety, and lawful access. Organisations should protect personal data, document key ownership, restrict privileged access, and retain only the logs needed for legitimate security and compliance purposes. Key escrow or recovery mechanisms create additional trust and compromise risks and must be assessed transparently.

Post-quantum cryptography is an important development because sufficiently capable quantum computers could break RSA and ECC through Shor’s algorithm. Symmetric cryptography and hash functions are affected differently, generally requiring parameter adjustments rather than complete replacement. Organisations should inventory cryptographic dependencies, identify long-lived confidential data, adopt crypto-agility carefully, and evaluate standardised post-quantum key-establishment and signature algorithms through controlled testing. Hybrid classical/post-quantum approaches may be used during migration, but only when specified by authoritative standards and implemented by trusted libraries.

Artificial intelligence can assist with certificate inventories, anomaly detection, configuration review, and code analysis. It must not be trusted to invent cryptographic algorithms, approve security exceptions without human review, or handle private keys in uncontrolled services. Generated code requires expert review and testing against standards.

Chapter Summary

Asymmetric cryptography uses a public/private key pair to support confidentiality, authentication, signatures, and key establishment. RSA relies on the difficulty of factoring large integers and requires secure padding such as OAEP or PSS. Diffie–Hellman establishes shared secret material but must be authenticated to prevent man-in-the-middle attacks. Ephemeral DH and ECDH can provide forward secrecy. ECC offers smaller keys through the elliptic-curve discrete logarithm problem, but safe curves, validation, randomness, and side-channel protection remain essential.

Symmetric cryptography is faster and therefore protects bulk data, while asymmetric cryptography manages identity and session keys. Modern systems combine them in hybrid protocols. The most serious practical failures usually arise not from the mathematical ideas but from weak randomness, nonce or key reuse, missing authentication, poor certificate validation, unsafe parameters, side channels, insecure key storage, and weak lifecycle governance. Professional practice requires approved standards, vetted libraries, careful configuration, monitoring, and planned migration toward post-quantum security.

Key Terms

Public key: Key intended for distribution and verification or encryption operations.

Private key: Secret key used for decryption, signing, or key agreement.

Asymmetric cryptography: Cryptography based on mathematically related public and private keys.

Symmetric cryptography: Cryptography using a shared secret key.

RSA: Public-key algorithm based on integer factorisation difficulty.

Diffie–Hellman: Key-agreement method based on the discrete logarithm problem.

Elliptic-curve cryptography: Public-key cryptography using groups of elliptic-curve points.

ECDH: Elliptic-curve Diffie–Hellman key agreement.

Digital signature: Cryptographic evidence of message integrity and private-key possession.

Certificate: Signed association between an identity and a public key.

Certificate authority: Trusted issuer of public-key certificates.

PKI: Infrastructure for certificates, trust chains, policies, and key management.

Forward secrecy: Protection of earlier sessions after later long-term-key compromise.

KDF: Key-derivation function that produces cryptographic keys from secret input.

Nonce: Value intended not to repeat within a specified cryptographic context.

OAEP: Secure randomized RSA encryption padding scheme.

PSS: Secure randomized RSA signature encoding scheme.

Hybrid encryption: Combination of asymmetric key establishment and symmetric data encryption.

Side channel: Unintended information leakage through timing, power, cache, or related behaviour.

Post-quantum cryptography: Cryptography designed to resist attacks by quantum computers.

Review Questions

5 Short Answer Questions

1. What is the difference between a public key and a private key?
2. Why is unauthenticated Diffie–Hellman vulnerable to a man-in-the-middle attack?
3. What is the purpose of a certificate authority?
4. Why is symmetric cryptography normally used for bulk data?
5. What does forward secrecy protect?

5 Long Answer Questions

1. Explain RSA key generation conceptually and discuss why textbook RSA is unsafe.
2. Describe the steps of an authenticated ephemeral ECDH-based connection.
3. Compare RSA, finite-field Diffie–Hellman, and ECC in terms of assumptions, performance, and implementation risks.
4. Explain how certificate validation contributes to public-key trust.
5. Discuss the key-management lifecycle from generation through destruction.

3 Analytical / Application Questions

1. A company encrypts all customer traffic with a symmetric key embedded in every mobile application. Analyse the threats and propose a hybrid redesign.
2. A TLS service accepts any certificate whose signature is mathematically valid, regardless of hostname or trust chain. Explain the attack and identify the required validation controls.
3. An organisation has archived sensitive data that must remain confidential for twenty years. Develop a migration and risk-management plan addressing current RSA/ECC exposure and possible post-quantum threats.

Multiple Choice Questions with Answers

Question 1

Which key is normally used to verify a digital signature?

A. The signer’s private key

B. The signer’s public key

C. The recipient’s symmetric key

D. A randomly generated session nonce

Correct Answer: B. The signer’s public key

Question 2

What is the principal purpose of authenticated Diffie–Hellman?

A. To compress ciphertext

B. To establish a shared secret while authenticating the communicating parties

C. To replace all symmetric encryption

D. To generate a certificate authority

Correct Answer: B. To establish a shared secret while authenticating the communicating parties

Question 3

In RSA, what relationship must the private exponent d have to the public exponent e?

A. d = e + 1

B. d is the modular inverse of e modulo φ(n)

C. d must equal one of the prime factors of n

D. d must be smaller than both p and q

Correct Answer: B. d is the modular inverse of e modulo φ(n)

Question 4

Which technique is most directly associated with forward secrecy?

A. Reusing a static private key

B. Ephemeral Diffie–Hellman values for each session

C. Using a public key without a certificate

D. Encrypting a private key with a password only once

Correct Answer: B. Ephemeral Diffie–Hellman values for each session

Question 5

Why are symmetric algorithms commonly used for bulk data in hybrid cryptography?

A. They require no keys

B. They are generally faster and have lower computational overhead

C. They automatically authenticate identities

D. They eliminate the need for random numbers

Correct Answer: B. They are generally faster and have lower computational overhead

Question 6

What is a major danger of reusing an ECDSA signing nonce?

A. It can reveal the private signing key

B. It increases certificate validity

C. It makes public keys confidential

D. It prevents all signature verification

Correct Answer: A. It can reveal the private signing key

Question 7

What does a certificate primarily bind together?

A. A plaintext and a ciphertext

B. An identity and a public key

C. A nonce and a password

D. Two symmetric session keys

Correct Answer: B. An identity and a public key

Question 8

Which RSA mechanism is intended for randomized encryption padding?

A. RSA-OAEP

B. RSA-PSS

C. ECDSA

D. HKDF

Correct Answer: A. RSA-OAEP

Question 9

What mathematical problem is associated with the security of ECC?

A. Integer sorting

B. Elliptic-curve discrete logarithm

C. Data compression

D. Prime counting only

Correct Answer: B. Elliptic-curve discrete logarithm

Question 10

Which practice is safest for producing cryptographic private keys?

A. Use the current time as the seed

B. Use a cryptographically secure operating-system random source or vetted library

C. Use a predictable counter

D. Derive the key from a username

Correct Answer: B. Use a cryptographically secure operating-system random source or vetted library