Cryptography and Public Key Infrastructure

Introduction

Cryptography is the discipline of protecting information by transforming it so that only authorized parties can use or verify it. In Internet and network security, cryptography supports confidentiality, integrity, authentication, non-repudiation, secure communication, identity management and trustworthy software distribution. It does not, however, make a system secure by itself. A strong algorithm can be undermined by stolen keys, poor randomness, insecure storage, incorrect configuration or an unverified certificate.

Modern security engineering therefore treats cryptography as part of a larger control system. The designer must identify the security objective, select an appropriate primitive and protocol, manage keys throughout their life cycle, and monitor the implementation. This chapter introduces symmetric encryption, asymmetric encryption, hashing, digital signatures, certificates, key exchange and public key infrastructure (PKI), with emphasis on professional selection and common weaknesses.

Learning Objectives

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

• distinguish confidentiality, integrity, authentication and non-repudiation;
• explain symmetric and asymmetric encryption and their appropriate uses;
• describe cryptographic hashing, message authentication codes and digital signatures;
• explain key exchange and the role of certificates and certificate authorities;
• describe PKI components and certificate life-cycle management;
• select suitable cryptographic controls for common security requirements;
• identify weaknesses such as obsolete algorithms, poor randomness, key leakage and certificate-validation errors.

1. Security Services and Cryptographic Building Blocks

The principal security services are:

Cryptography uses algorithms, keys and protocols. An algorithm specifies a transformation; a key selects one member of a large family of transformations. Security should depend on the secrecy or controlled use of keys, not on keeping a well-designed algorithm secret. This principle is commonly associated with Kerckhoffs's principle.

A threat model identifies the capabilities of an adversary. For example, an attacker may observe network traffic, modify messages, replay valid messages, impersonate a server, steal an endpoint or obtain a database backup. A cryptographic control is meaningful only in relation to such assumptions.

1.1 Confusion, diffusion and computational security

Block ciphers are designed to obscure relationships between plaintext, ciphertext and key. Diffusion spreads the influence of each plaintext bit across many ciphertext bits, while confusion makes the relationship between key and ciphertext complex. Contemporary algorithms are evaluated against known attack models and are considered computationally secure when the required resources are infeasible under stated assumptions. “Unbreakable” is generally an inappropriate claim: security depends on the algorithm, key length, implementation, operational environment and future computing capability.

2. Symmetric Encryption

Symmetric encryption uses the same secret key, or computationally related secret keys, for encryption and decryption. If plaintext P is transformed using key K into ciphertext C, the relationship can be represented as:

Decryption recovers the plaintext:

Here, P is the plaintext, C is the ciphertext, K is the secret key, Enc is the encryption algorithm and Dec is the corresponding decryption algorithm. Correct recovery assumes that the legitimate recipient possesses the correct key and that the algorithm and mode are used correctly.

Symmetric algorithms are efficient and are therefore used for bulk data: disk encryption, database fields, backups, VPN traffic and application sessions. Examples include AES and ChaCha20. AES supports 128-, 192- and 256-bit keys. ChaCha20 is a stream cipher commonly paired with Poly1305 for authenticated encryption.

2.1 Block ciphers and modes

A block cipher processes fixed-size blocks. A mode of operation defines how multiple blocks are processed and how nonces or initialization vectors are used. ECB mode should not be used for ordinary confidential data because identical plaintext blocks produce related ciphertext blocks. CBC requires careful padding and integrity protection; encryption alone does not detect modification. CTR turns a block cipher into a stream-like construction but requires a unique nonce for each key.

Authenticated encryption with associated data (AEAD) provides confidentiality and integrity together. AES-GCM and ChaCha20-Poly1305 are widely used AEAD constructions. They protect plaintext and may authenticate unencrypted metadata such as protocol headers. A typical abstract operation is:

K is the secret key, N is a nonce, P is plaintext, A is associated data, C is ciphertext and T is an authentication tag. Decryption accepts the result only if T verifies. The nonce need not usually be secret, but its uniqueness requirement is critical. Reusing a nonce with the same key can disclose information and, in some constructions, compromise authentication.

2.2 Key distribution challenge

Symmetric encryption creates a key-distribution problem. If n parties must communicate directly and each pair requires a separate key, the number of pairwise keys is:

K is the number of distinct pairwise keys and n is the number of parties, assuming one unique key per unordered pair. For 10 parties, K = 10 × 9 ÷ 2 = 45. This does not mean that every practical system stores exactly this many keys; key servers and group-key designs can reduce operational burden. The example demonstrates why large networks need scalable key-management mechanisms.

3. Hashing and Message Authentication

A cryptographic hash function maps input of arbitrary length to a fixed-length digest:

M is the message, H is the hash function and h is the digest. A secure hash should provide preimage resistance, second-preimage resistance and collision resistance. In a collision, two different messages M₁ and M₂ produce the same digest. Collision resistance is especially important when a digest is used to identify or sign data.

SHA-256 and SHA-3 are examples of modern general-purpose hash functions. MD5 and SHA-1 should not be selected for collision-sensitive security applications. A hash is not encryption: it is normally designed to be one-way and has no decryption key.

Passwords require special treatment. A fast general-purpose hash is unsuitable because attackers can test many guesses rapidly. Password storage should use a password-hashing or key-derivation function such as Argon2id, scrypt, bcrypt or PBKDF2, with a unique salt and a cost setting appropriate to the environment. A salt is not a secret; it prevents identical passwords from having identical stored values and frustrates precomputed rainbow tables.

A message authentication code (MAC) combines a secret key with a message:

A MAC provides integrity and authentication to parties sharing K, but it does not provide public verifiability: either party possessing K can generate a valid tag. HMAC is a widely deployed MAC construction based on a cryptographic hash. AEAD is often preferable for network data because it combines encryption and authentication in one carefully designed operation.

4. Asymmetric Cryptography

Asymmetric, or public-key, cryptography uses a key pair: a public key that may be distributed and a private key that must be protected. The keys are mathematically related, but deriving the private key from the public key should be computationally infeasible under the algorithm's assumptions.

Public-key encryption allows a sender to encrypt using the recipient's public key; only the corresponding private key should decrypt. In practice, public-key encryption is slower than symmetric encryption, so protocols usually use it to establish or protect a short-lived symmetric session key. RSA and elliptic-curve schemes have been used for encryption, although modern protocols often prefer ephemeral key agreement followed by AEAD rather than direct RSA encryption.

Public-key algorithms also support signatures. A signer uses a private key to produce a signature over a message or its digest. Anyone with the public key can verify it. Digital signatures provide origin authentication, integrity and evidence that the private key was used. They do not automatically prove the legal identity of the person or organization; that link depends on certificates, enrollment, key protection and applicable governance.

Elliptic-curve cryptography (ECC) achieves security comparable to older RSA deployments with smaller keys, but implementation must use approved curves and well-tested libraries. Ed25519 is widely used for signatures, while elliptic-curve Diffie–Hellman variants are used for key agreement. Post-quantum cryptography is being standardized because sufficiently powerful quantum computers could threaten widely used RSA and elliptic-curve systems; organizations should track migration guidance and inventory cryptographic dependencies.

5. Key Exchange

Key exchange establishes a shared secret over a channel that an attacker may observe. In the classic Diffie–Hellman method, two parties exchange public values derived from private values and compute a common secret. The shared value can be expressed abstractly as:

Here, p is a suitably chosen public modulus, g is a public generator, a and b are private ephemeral values, and S is the resulting shared value. Both parties calculate the same S because g^(ab) = g^(ba) under the specified modular arithmetic assumptions. The equation is illustrative of the protocol family; real implementations must use approved parameter groups and protected key derivation.

Unauthenticated Diffie–Hellman is vulnerable to a man-in-the-middle attack. An attacker can establish one secret with each endpoint and relay messages. Authentication is therefore required, commonly through certificates and digital signatures. Ephemeral key exchange creates forward secrecy when session-specific private values are erased after use: later compromise of a long-term private key should not reveal recorded past sessions, assuming the protocol and implementation are correct.

A key derivation function (KDF) converts shared material into keys with defined purposes. It should produce separate keys for encryption, authentication and different communication directions rather than reusing one raw secret everywhere. Modern protocols also use transcript binding, key confirmation, nonces and sequence numbers to prevent downgrade and replay attacks.

6. Digital Signatures and Certificates

A simplified signing process is:

1. calculate a digest of the message;
2. apply a signature algorithm using the private key;
3. transmit the message and signature;
4. verify the signature using the public key and the specified algorithm and parameters.

A signature is meaningful only if the verifier obtains the authentic public key. Otherwise, an attacker can create a new key pair and claim that its public key belongs to a trusted server. A digital certificate addresses this binding problem.

A certificate is a signed data structure that associates a subject identity with a public key. X.509 certificates commonly contain the subject, issuer, public key, validity period, serial number, permitted purposes and extensions such as subject alternative names. The issuer, normally a certificate authority (CA), signs the certificate. A browser or operating system trusts a root CA because its public key is distributed in a trust store through a platform or organizational trust process.

Certificate validation normally includes:

• building a chain from the end-entity certificate to a trusted root;
• verifying each signature in the chain;
• checking validity dates and permitted key usage;
• matching the requested host name against the subject alternative name;
• checking that the certificate is not revoked or otherwise distrusted;
• rejecting weak algorithms, invalid constraints and malformed extensions.

A certificate does not encrypt traffic by itself. In TLS, certificates authenticate endpoints and support key establishment; symmetric session keys then protect application data.

7. Public Key Infrastructure

PKI is the people, processes, technologies, policies and records used to create, distribute, validate, revoke and replace public-key credentials. Its components commonly include:

• Root CA: a highly protected trust anchor that may sign subordinate CA certificates.
• Subordinate or issuing CA: issues end-entity certificates under constrained authority.
• Registration authority: verifies identity or entitlement before certificate issuance.
• Certificate repository: publishes certificates, policies and revocation information.
• Relying party: validates certificates before trusting a public key.
• Hardware security module (HSM): protects high-value private keys and performs cryptographic operations.
• Certificate policy and practice statement: defines assurance requirements, responsibilities and procedures.

A sound hierarchy keeps root CA keys offline where possible and limits issuing CAs through path-length, name and key-usage constraints. Automated certificate management is increasingly important because short-lived certificates reduce exposure but increase renewal frequency. ACME is an example of an automated certificate issuance protocol used widely for web certificates.

7.1 Revocation and status

If a private key is compromised, a certificate is issued incorrectly or the subject is no longer authorized, relying parties need a way to reject it before its expiry. Certificate revocation lists (CRLs) publish revoked serial numbers. Online Certificate Status Protocol (OCSP) allows a relying party to query status. Both have operational limitations, including availability, privacy, caching and “soft-fail” behavior. Short certificate lifetimes, rapid automated renewal, and well-defined incident procedures can reduce dependence on perfect real-time revocation.

8. Key Management Life Cycle

Cryptographic controls fail frequently because of key-management failures rather than mathematical attacks. A professional life cycle includes:

1. Requirement definition: identify data sensitivity, trust boundaries, retention and recovery needs.
2. Generation: use an approved cryptographic random number generator and sufficient entropy.
3. Registration and distribution: bind keys to identities and deliver them through authenticated channels.
4. Storage and use: restrict access, separate duties and protect private keys with HSMs, secure enclaves or managed key vaults where appropriate.
5. Rotation: replace keys based on policy, exposure, cryptoperiod and algorithm guidance.
6. Backup and recovery: protect backups with independent controls and test restoration.
7. Revocation or suspension: invalidate compromised or unauthorized credentials.
8. Destruction: securely erase keys and document disposal.

Key ownership, custodianship, access logging, dual control and recovery authority should be documented. Encryption keys should not be stored beside encrypted data without additional protection. Secrets should not be embedded in source code, container images, mobile applications or public repositories.

9. Selecting Appropriate Controls

Control selection begins with the required property rather than the fashionable algorithm. The following pattern is useful:

Envelope encryption uses a data-encryption key (DEK) to encrypt data and a key-encryption key (KEK) to protect the DEK. This permits efficient data encryption while allowing centralized control over KEKs. Separation of duties is important: an administrator who can read encrypted data should not automatically control the keys that decrypt it.

10. Common Implementation Weaknesses

Important weaknesses include:

• using obsolete algorithms such as DES, RC4, MD5 or SHA-1 for unsuitable purposes;
• choosing a mode without authentication or reusing a nonce;
• generating keys with predictable pseudo-randomness;
• using short, reused or hard-coded keys;
• failing to validate certificate chains, host names or key usage;
• accepting any certificate or disabling TLS verification in production;
• not checking signature algorithm parameters or supporting downgrade attacks;
• logging plaintext, tokens, private keys or decrypted personal data;
• failing to rotate credentials or revoke compromised certificates;
• using one key for unrelated purposes;
• comparing authentication values with timing-sensitive ordinary string operations;
• exposing keys through backups, memory dumps, source repositories or build logs;
• assuming encryption prevents endpoint compromise or authorization abuse.

Developers should use reputable, maintained cryptographic libraries and protocol implementations rather than inventing algorithms. Security reviews should examine defaults, error handling, dependency versions, random-number sources, certificate validation and test coverage. Cryptographic failures should fail closed: invalid tags, signatures or certificates should cause rejection rather than an insecure fallback.

11. Applied Case: Illustrative Online Examination Platform

Background

A college deploys an online examination platform. Students authenticate through a web browser, submit answers, and receive results. The system stores personal information and examination material. It uses HTTPS, a cloud database and a separate service that signs official result statements.

Problem

An assessment discovers that the web server accepts certificates without checking the host name in one internal API client. Database backups are encrypted, but the encryption key is stored in the same backup account. The result-signing private key is present as an environment variable on several application servers. Certificates are renewed manually and have previously expired.

Analysis

HTTPS may protect browser traffic, but the internal client weakness permits a man-in-the-middle attack if an attacker can influence routing or DNS. Co-locating the backup and its key weakens confidentiality because compromise of the account may reveal both. Replicating the signing key increases the attack surface and makes authorization difficult to audit. Manual renewal creates an availability risk.

Approach and solution

The institution should use a maintained TLS library with full chain and host-name validation, mutual TLS or an equivalent authenticated service identity for sensitive internal APIs, and network segmentation. A managed key service should protect the database KEK, while data keys are handled through envelope encryption. Backups should be isolated, access-controlled and regularly tested.

The result-signing key should be generated and used in an HSM or managed signing service. Applications should submit approved signing requests, with role separation, authorization records and rate limits. Certificate issuance and renewal should be automated, monitored and tested before expiry. The institution should define certificate policies, incident response procedures and a process for revoking compromised credentials.

Outcome and learning points

The redesigned system reduces the probability that a network interception becomes an identity compromise, separates encrypted data from key control, and limits access to the high-value signing key. The case illustrates that cryptographic strength is only one part of security. Validation, key custody, automation, monitoring and governance determine whether cryptography delivers its intended protection.

12. Governance, Ethics and Contemporary Developments

Organizations must balance confidentiality with lawful access, safety, investigation and individual rights. Any exceptional access mechanism or “back door” increases complexity and creates a target; it should not be treated as a cost-free control. Personal data should be encrypted in transit and at rest, but encryption does not remove obligations concerning collection, retention, access and breach notification. Policies should identify data owners, lawful purposes, retention periods and authorized disclosure processes.

Cryptographic agility is now a governance requirement. Systems should inventory algorithms, key sizes, certificate dependencies and embedded cryptographic libraries so that vulnerable algorithms can be replaced without redesigning the entire service. Organizations should monitor post-quantum standardization and consider hybrid migration strategies where appropriate. AI may assist in discovering exposed secrets, classifying certificates and detecting unusual key use, but automated recommendations require human review because false positives, leaked training data and incorrect remediation can cause outages or disclosure.

Best-Practice Checklist

• Use established, reviewed protocols and libraries.
• Prefer AEAD for new confidential communication and storage designs.
• Generate keys with a cryptographically secure random source.
• Never reuse nonces where the selected construction forbids reuse.
• Validate certificate chains, names, dates, constraints and status.
• Protect private keys with least privilege, hardware protection where justified and audit logs.
• Separate data keys, key-encryption keys and signing keys by purpose.
• Automate certificate renewal and test failure conditions.
• Use memory-hard password KDFs with unique salts.
• Plan rotation, revocation, backup, recovery and destruction before deployment.
• Maintain a cryptographic inventory and a migration plan for emerging threats.

Chapter Summary

Cryptography provides mechanisms for confidentiality, integrity, authentication, freshness and evidence, but successful protection depends on correct implementation and key management. Symmetric encryption is efficient for bulk data but requires secure key distribution. Asymmetric cryptography supports scalable identity, signatures and key agreement, although it is computationally more expensive and requires trusted public-key binding. Hashes provide fixed-length digests; MACs authenticate messages to parties sharing a secret; digital signatures provide public verification when the public key is trustworthy.

Certificates bind identities to public keys, and PKI supplies the authorities, policies, repositories and validation processes needed to operate those bindings. Key exchange must be authenticated to prevent man-in-the-middle attacks, while ephemeral keys can provide forward secrecy. Appropriate control selection includes AEAD for protected traffic, password-specific KDFs for passwords, certificates for identity, HSMs or managed vaults for high-value keys, and automated life-cycle management. Obsolete algorithms, nonce reuse, poor randomness, weak certificate validation, exposed keys and absent rotation remain common causes of failure.

Key Terms

Cryptography: The practice of protecting information using mathematical transformations and controlled keys.

Symmetric encryption: Encryption using a shared secret key.

Asymmetric cryptography: Cryptography using related public and private keys.

Plaintext: Original readable data before encryption.

Ciphertext: Transformed data produced by encryption.

Hash function: A function that maps arbitrary input to a fixed-length digest.

Collision: A pair of different inputs with the same hash output.

MAC: A keyed integrity and authentication value.

AEAD: Authenticated encryption with associated data.

Nonce: A value intended for one-time or controlled-use context in a cryptographic operation.

Digital signature: A private-key-generated value that can be publicly verified.

Certificate: A signed binding between an identity and a public key.

Certificate authority: An authority that issues and signs certificates.

PKI: The infrastructure and governance for public-key credentials.

Key exchange: A protocol for establishing shared secret material.

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

HSM: Hardware security module used to protect and operate on sensitive keys.

Revocation: The process of invalidating a certificate before its expiry.

Key derivation function: A function that derives purpose-specific keys from secret input.

Cryptoperiod: The approved period during which a key may be used.

Review Questions

5 Short Answer Questions

1. What is the principal difference between symmetric and asymmetric encryption?
2. Why is a cryptographic hash not considered an encryption algorithm?
3. What security properties does AEAD provide?
4. Why must a digital signature be associated with a trusted public key?
5. State two responsibilities of a certificate authority.

5 Long Answer Questions

1. Explain the key-distribution challenge in symmetric cryptography and describe how public-key techniques help address it.
2. Describe the validation steps a client should perform when checking a TLS certificate.
3. Explain the life cycle of a cryptographic key from generation through destruction.
4. Compare MACs and digital signatures in terms of verification, key ownership and practical use.
5. Discuss how PKI, certificate policies and revocation mechanisms work together in an enterprise.

3 Analytical / Application Questions

1. A company encrypts customer files with AES-GCM but reuses the same nonce with the same key. Analyze the likely security consequences and propose a correction.
2. An internal service accepts any certificate presented by its peer because “the traffic is encrypted.” Identify the security failure and design a safer authentication process.
3. Design a cryptographic control set for a small healthcare application that stores records, authenticates staff, exchanges data between services and produces legally significant reports. Justify the controls and identify key-management responsibilities.

Multiple Choice Questions with Answers

Question 1

Which control provides confidentiality and integrity together for network data?

A. Plain SHA-256 hashing

B. Authenticated encryption with associated data

C. A certificate revocation list

D. A public key without encryption

Correct Answer: B. Authenticated encryption with associated data

Question 2

What is the principal purpose of a certificate in TLS?

A. To compress application data

B. To bind an identity to a public key

C. To replace all symmetric encryption

D. To generate password salts

Correct Answer: B. To bind an identity to a public key

Question 3

For 10 parties using one unique symmetric key for every pair, how many pairwise keys are required?

A. 10

B. 20

C. 45

D. 100

Correct Answer: C. 45

Question 4

Why is nonce reuse dangerous in many AEAD constructions?

A. It makes certificates expire sooner

B. It can disclose information and compromise authentication

C. It increases password hashing cost

D. It prevents public-key distribution

Correct Answer: B. It can disclose information and compromise authentication

Question 5

Which mechanism is most appropriate for storing user passwords?

A. MD5 without a salt

B. AES encryption with a key in source code

C. A password KDF such as Argon2id with a unique salt

D. Base64 encoding

Correct Answer: C. A password KDF such as Argon2id with a unique salt

Question 6

What weakness exists in unauthenticated Diffie–Hellman key exchange?

A. It cannot produce a shared secret

B. It is vulnerable to a man-in-the-middle attack

C. It requires no private values

D. It only works for password storage

Correct Answer: B. It is vulnerable to a man-in-the-middle attack

Question 7

Which key should normally be kept secret in a digital-signature system?

A. The public verification key

B. The certificate serial number

C. The private signing key

D. The hash algorithm name

Correct Answer: C. The private signing key

Question 8

What is a major function of an HSM?

A. To provide web page content

B. To protect and perform operations with sensitive keys

C. To replace certificate validation

D. To generate public DNS records

Correct Answer: B. To protect and perform operations with sensitive keys

Question 9

Which statement about a cryptographic hash is correct?

A. It is normally reversible with a public key

B. It maps arbitrary-length input to a fixed-length digest

C. It always provides confidentiality

D. It requires the recipient's certificate

Correct Answer: B. It maps arbitrary-length input to a fixed-length digest

Question 10

Which practice best supports certificate availability in a large organization?

A. Manual renewal with no monitoring

B. Disabling expiry checks

C. Automated issuance and renewal with monitoring

D. Using one certificate for every unrelated service

Correct Answer: C. Automated issuance and renewal with monitoring