Cryptography, PKI and Secure Communications

Introduction

Modern computing depends on the ability to communicate over networks that may be monitored, manipulated, or impersonated. Cryptography provides the mathematical and engineering mechanisms used to protect information in storage and transit. It supports confidentiality, integrity, authentication, non-repudiation, secure software updates, electronic commerce, virtual private networks, and digital identity systems.

Cryptography is not simply the practice of “scrambling” data. A secure system must define who may access information, how keys are created and protected, how communicating parties authenticate one another, how messages are checked for alteration, and how compromised keys are revoked. Public-key infrastructure (PKI) provides an organizational and technical framework for managing digital certificates and public keys at scale.

This chapter explains symmetric and asymmetric encryption, cryptographic hashes, message authentication codes, digital signatures, certificates, key exchange, PKI, key management, secure communication protocols, common failures, and professional responsibilities.

Learning Objectives

After studying this chapter, you should be able to:

• distinguish confidentiality, integrity, authentication, and non-repudiation;
• explain and apply symmetric and asymmetric encryption;
• select suitable hashing, MAC, and digital-signature mechanisms;
• describe public-key certificates, certificate authorities, and trust chains;
• explain key exchange and the role of forward secrecy;
• analyze TLS-style secure communication;
• identify common cryptographic implementation failures;
• apply key-management and governance principles in practical systems.

1. Security Services and Cryptographic Goals

Cryptographic design begins with a security requirement rather than an algorithm. The principal services are:

No single primitive supplies every service. Encryption alone does not necessarily authenticate the sender or detect manipulation. A cryptographic hash alone does not prevent an attacker from replacing both a message and its hash. Security therefore depends on correctly combining primitives and managing their keys.

A useful model is the threat distinction between passive and active attackers. A passive attacker observes traffic but does not change it. An active attacker may inject, delete, replay, reorder, or modify messages and may impersonate a participant. Internet protocols must generally be designed against active attackers.

2. Symmetric Encryption

Symmetric encryption uses the same secret key, or closely related secret keys, for encryption and decryption. If plaintext is represented by P, ciphertext by C, and a secret key by K, encryption and decryption can be represented as:

The equations describe an abstract requirement: D_K(E_K(P)) = P. They do not specify a particular algorithm. The key must remain secret, and the algorithm should be publicly studied rather than relying on secrecy of the algorithm.

2.1 Block and stream ciphers

A block cipher transforms fixed-size blocks under a key. AES, the Advanced Encryption Standard, operates on 128-bit blocks and commonly uses 128-, 192-, or 256-bit keys. AES is widely deployed when used with a secure mode of operation.

A stream cipher generates a pseudorandom keystream that is combined with plaintext, commonly using exclusive OR (XOR). ChaCha20 is a modern stream cipher often used with Poly1305 authentication.

Block ciphers require modes of operation when encrypting messages longer than one block. ECB mode is unsafe for structured data because equal plaintext blocks produce equal ciphertext blocks. CBC requires a random, unpredictable initialization vector and separate authentication; CBC encryption without reliable integrity protection is vulnerable to attacks such as padding-oracle attacks. Modern systems generally prefer authenticated encryption.

2.2 Authenticated encryption

Authenticated encryption with associated data (AEAD) provides confidentiality and integrity for plaintext while also authenticating unencrypted metadata called associated data. AES-GCM and ChaCha20-Poly1305 are common AEAD constructions.

An AEAD interface can be represented as:

where 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 must reject the message if the tag is invalid.

The nonce normally need not be secret, but it must satisfy the algorithm’s uniqueness requirements. In particular, nonce reuse with AES-GCM under the same key can seriously compromise confidentiality and authentication. Applications should use carefully designed nonce-management rules rather than relying on ad hoc counters or random values with insufficient size.

2.3 Advantages and limitations

Symmetric encryption is computationally efficient and suitable for bulk data. Its central difficulty is key distribution: two parties must obtain the same secret key without an attacker learning it. In a system with many communicating entities, pairwise keys can become difficult to create, rotate, store, and revoke. Public-key techniques are often used to establish or protect symmetric session keys.

3. Cryptographic Hash Functions

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

where M is the message and h is the digest. A secure hash function is expected to provide:

• Preimage resistance: given h, it should be computationally infeasible to find a message M such that H(M) = h.
• Second-preimage resistance: given a particular message M₁, it should be infeasible to find a different M₂ with the same digest.
• Collision resistance: it should be infeasible to find any two different messages with the same digest.

The ideal generic collision-search effort for an n-bit hash is approximately 2^n/2 operations because of the birthday effect. This is a security estimate under idealized assumptions, not a guarantee for every real algorithm.

SHA-256 and SHA-3 are examples of modern hash standards. MD5 and SHA-1 should not be selected for collision-sensitive security applications. Hashing is not encryption: a hash is not intended to be reversed, and it uses no decryption key.

Password storage

Passwords should not be stored as ordinary hashes. Attackers can test guesses rapidly against a stolen database. Password-specific functions such as Argon2id, scrypt, or bcrypt deliberately consume computational and memory resources. A unique random salt is stored with each password record:

The salt prevents identical passwords from producing identical stored values and defeats precomputed rainbow tables. It does not make a weak password strong. A cost parameter controls the work factor and should be reviewed as hardware changes.

4. Message Authentication Codes

A message authentication code (MAC) uses a shared secret to produce an integrity and origin-authentication tag:

A receiver recomputes the tag with the same key and accepts the message only if the tags match. HMAC, constructed from a cryptographic hash and a secret key, is a common MAC. MACs are efficient and appropriate when the communicating parties already share a secret.

A MAC does not provide public verifiability. Either party possessing the shared key could have generated the tag. This distinguishes a MAC from a digital signature, which uses a private key for signing and a public key for verification.

5. Asymmetric Cryptography

Asymmetric, or public-key, cryptography uses a mathematically related key pair: a public key that may be distributed and a private key that must be protected. Public-key encryption can provide a mechanism in which anyone encrypts to a recipient’s public key, while only the corresponding private key decrypts. Digital signatures use the reverse functional relationship: the private key signs and the public key verifies.

Public-key algorithms are slower and more complex than symmetric algorithms, so they are usually used for authentication, key establishment, or small objects rather than bulk data. Examples include RSA, elliptic-curve cryptography (ECC), and modern elliptic-curve signature and key-agreement schemes such as Ed25519 and X25519.

Security depends on computational assumptions. RSA relies on the difficulty of factoring appropriately generated large integers. ECC relies on the difficulty of the elliptic-curve discrete logarithm problem for approved curves. These assumptions can fail through poor parameter choices, implementation errors, side channels, or future advances such as large-scale quantum computing.

6. Key Exchange and Forward Secrecy

A key-exchange protocol enables two parties to derive a shared secret over an observable network. In the classic Diffie–Hellman construction, a public group and generator are selected. Alice chooses a private value a and sends g^a, while Bob chooses b and sends g^b. Both compute:

The shared value is normally processed through a key-derivation function rather than directly used as an encryption key. This example is conceptual; secure deployments require approved groups, authentication, validation, and protection against man-in-the-middle attacks.

Unauthenticated Diffie–Hellman does not identify the parties. An attacker can establish one secret with Alice and another with Bob. Certificates or pre-shared authentication keys are therefore needed.

Forward secrecy means that compromise of a long-term private key does not allow an attacker to decrypt previously recorded sessions. Ephemeral Diffie–Hellman keys, commonly called DHE or ECDHE, provide this property when generated securely and erased after use. Forward secrecy limits the impact of later key compromise, although it does not protect sessions whose endpoint was compromised during communication.

7. Digital Signatures

A digital signature binds a message to a private signing key. Abstractly:

where SK is the private key and PK is the corresponding public key. Signature systems normally sign a digest or use a standardized encoding of the message, rather than applying the private-key operation directly to arbitrary data.

A valid signature can demonstrate that the holder of the private key approved a particular message, provided the key was controlled properly and the verification key is authentic. It supports integrity and authentication and may support non-repudiation in a technical or legal framework. However, non-repudiation is not created by mathematics alone. Evidence about key custody, identity proofing, authorization, device security, and applicable law is also relevant.

Signature failures include using weak randomness, signing ambiguous data formats, accepting invalid encodings, failing to validate the correct public key, and reusing fragile cryptographic components. Verification software must reject malformed or invalid signatures rather than attempting to repair them.

8. Certificates and Public-Key Infrastructure

A public key by itself does not identify its owner. A certificate is a signed statement binding an identity or subject name to a public key, along with constraints such as validity period, permitted uses, and issuer information.

A simplified certificate trust process is:

1. A subject generates a key pair and submits a certificate-signing request.
2. A registration authority or certificate authority (CA) verifies the subject according to policy.
3. The CA signs and issues a certificate.
4. A relying party receives the certificate and validates its signature, dates, names, key usage, and chain to a trusted root.
5. The relying party checks whether the certificate has been revoked or otherwise rejected.

PKI consists not merely of certificates but also of policies, roles, procedures, repositories, validation services, hardware, audit processes, and revocation mechanisms. A root CA is trusted by inclusion in a trust store. Intermediate CAs issue end-entity certificates and reduce the need to use the root key frequently. A certificate chain is valid only if each certificate is correctly signed by its issuer and the chain terminates at a trusted root under applicable policy.

Certificate validation

A client should validate at least:

• the issuer signature and chain construction;
• the certificate validity period, including correct time handling;
• the requested hostname or subject identity;
• key-usage and extended-key-usage constraints;
• basic constraints and path-length restrictions for CA certificates;
• revocation status where the deployment requires it;
• algorithm and key-size policy;
• whether the trust anchor is appropriate for the application.

Disabling certificate validation, accepting any certificate, or trusting a certificate merely because it is encrypted defeats the purpose of PKI.

Revocation may be communicated through certificate revocation lists (CRLs) or online status protocols such as OCSP. Revocation systems face availability, privacy, scalability, and “soft-fail” challenges. Short-lived certificates and automated renewal can reduce reliance on large revocation lists, but they do not eliminate the need for incident response.

9. Secure Communications with TLS

Transport Layer Security (TLS) illustrates how cryptographic primitives are combined. Although details vary by version and configuration, a modern authenticated connection generally performs the following logical steps:

1. The client and server negotiate protocol versions and supported cryptographic parameters.
2. They exchange ephemeral key-agreement information.
3. The server presents a certificate and proves possession of its private key.
4. Both sides derive symmetric traffic keys from the shared secret and transcript context.
5. Application data is protected using authenticated encryption.
6. Sequence numbers and authentication tags help detect alteration, truncation, and replay within the connection.

The certificate usually authenticates the server. Client certificates may provide mutual TLS when the server also needs cryptographic client identity. DNS security, endpoint validation, application authorization, and secure server configuration remain necessary; TLS does not make an insecure application automatically secure.

A high-level key schedule can be represented as:

The exact derivation is protocol-specific. The transcript binds negotiation messages to the resulting keys and helps prevent downgrade and substitution attacks.

10. Key Management

Cryptography is often defeated by key-management failures rather than by breaking the underlying algorithm. A key lifecycle includes:

1. Generation: use an approved cryptographic random-number generator.
2. Registration and distribution: establish ownership and authorized use.
3. Storage: protect keys using access controls, encryption, hardware security modules, or secure platform facilities.
4. Use: enforce algorithm, purpose, identity, and authorization constraints.
5. Rotation: replace keys according to risk, exposure, cryptoperiod, and policy.
6. Backup and recovery: preserve availability without creating uncontrolled copies.
7. Revocation: invalidate compromised or unauthorized keys.
8. Destruction: securely delete keys when no longer needed.

A cryptoperiod is the period during which a key is authorized for a particular purpose. It should reflect data sensitivity, usage volume, compromise probability, regulatory requirements, and algorithm limitations. Key rotation alone does not repair a system if old keys remain accessible or if attackers retain decrypted data.

Secrets should not be embedded in source code, container images, public repositories, URLs, or ordinary configuration files. Centralized secrets-management systems can support access control, auditing, rotation, and separation of duties. Hardware security modules can protect high-value keys and perform operations without exposing private material to ordinary application processes.

11. Common Cryptographic Failures

11.1 “Rolling your own” cryptography

Developers should not invent algorithms or combine primitives without expert review. Security depends on subtle properties, correct encodings, nonce handling, randomness, side-channel resistance, and protocol composition.

11.2 Weak randomness

Predictable random numbers can expose session keys, password-reset tokens, nonces, or private keys. Operating-system cryptographic random generators should be used, and applications must account for early-boot and virtualized environments.

11.3 Reused nonces

Nonce reuse in schemes such as AES-GCM can reveal relationships between plaintexts and may compromise authentication. Nonce uniqueness must be designed and tested as a system property.

11.4 Confusing encoding with encryption

Base64, hexadecimal, URL encoding, and serialization are representations, not confidentiality mechanisms. They may make data portable or readable but do not protect secrets.

11.5 Encryption without authentication

Unauthenticated ciphertext may be modified. Modern applications should prefer AEAD or use a rigorously reviewed encrypt-then-MAC design.

11.6 Improper certificate validation

Accepting expired certificates, ignoring hostnames, trusting arbitrary issuers, or disabling validation enables impersonation and man-in-the-middle attacks.

11.7 Password misuse

Passwords should not be encrypted for ordinary verification or stored with fast general-purpose hashes. Use a memory-hard password KDF, unique salts, rate limiting, and multifactor authentication where appropriate.

11.8 Side-channel leakage

Execution time, memory access patterns, power consumption, and electromagnetic emissions may reveal secrets. Constant-time implementations, blinding, isolation, and tested libraries reduce this risk, although no single measure is universal.

11.9 Poor error handling

Detailed decryption or padding errors may provide an oracle. Systems should fail safely, avoid leaking secret-dependent information, and log security-relevant events without recording plaintext or keys.

12. Applied Case: Protecting a University Student Portal

The following is an illustrative case.

Background

A university student portal allows students to register for courses, view grades, download fee statements, and submit documents. The portal is accessed from personal laptops and mobile devices over untrusted networks.

Problem

An initial design uses HTTPS but disables certificate validation in a mobile client after encountering certificate-renewal errors. Passwords are stored as SHA-256 hashes without salts. A database backup contains API keys in clear text, and an internal service encrypts messages with AES-CBC without authentication.

Analysis

The system has several independent weaknesses. Disabling certificate validation permits server impersonation. Unsalted fast hashes enable efficient offline password guessing and reveal equal passwords. Exposed API keys may allow unauthorized service access. CBC encryption without integrity protection permits message manipulation and potentially exploitable padding behavior.

Approach and solution

The university should use a maintained TLS library with hostname and chain validation, automated certificate renewal, and tested trust-store management. Passwords should be rehashed using Argon2id or another approved password KDF, with a unique salt per account and an adjustable work factor. High-value service credentials should be placed in a secrets-management system with restricted identities, audit logs, and rotation.

Inter-service communication should use TLS, preferably mutual TLS where service identity is required. Application payloads should use an AEAD construction such as AES-GCM or ChaCha20-Poly1305 with carefully managed nonces. Session establishment should use authenticated ephemeral key exchange to provide forward secrecy. Administrative actions should require authorization independent of successful cryptographic authentication, and security events should be monitored.

Outcome

The revised design reduces exposure from network interception, database theft, credential leakage, and message tampering. It also improves operational recovery because certificates and secrets can be rotated without rebuilding application code.

Learning points

Security is a system lifecycle property. Strong algorithms cannot compensate for disabled validation, exposed keys, weak password storage, or missing authorization. Reliability and usability also matter: automated renewal and clear operational procedures help prevent staff from bypassing security controls.

13. Governance, Ethics, and Contemporary Developments

Cryptographic deployments should follow organizational policy, legal requirements, data-protection obligations, and recognized technical standards. Encryption can protect privacy and safety, but organizations must define lawful access, retention, incident response, and audit procedures without creating uncontrolled universal decryption keys. Excessive key access increases insider and breach risk.

Professionals should minimize collected data, protect vulnerable users, document cryptographic decisions, and disclose weaknesses responsibly. Backdoors and intentional weakening of cryptography create systemic risks because unauthorized parties may eventually discover or exploit them.

Post-quantum cryptography is an important contemporary development. A sufficiently capable quantum computer could threaten widely used public-key systems based on factoring and discrete logarithms, while symmetric systems are affected differently. Organizations should inventory cryptographic dependencies, identify long-lived sensitive data, and plan for algorithm agility. Hybrid key-establishment approaches may combine classical and post-quantum mechanisms during migration, but they must be implemented using standardized, reviewed protocols rather than improvised combinations.

Artificial intelligence can assist with code review, certificate inventory, anomaly detection, and documentation. It must not be trusted to invent or validate cryptographic designs without expert review. AI-generated code may contain insecure randomness, unsafe key storage, incorrect certificate validation, or inappropriate algorithms.

Best-Practice Checklist

• Use established, peer-reviewed libraries and current protocol versions.
• Prefer authenticated encryption for application data.
• Use cryptographically secure randomness.
• Never reuse nonces where an algorithm forbids reuse.
• Validate certificate chains, names, dates, and key usage.
• Store passwords with a password-specific KDF, salts, and an appropriate cost.
• Separate keys by purpose, environment, tenant, and sensitivity.
• Protect private keys and rotate or revoke them through documented procedures.
• Design for forward secrecy where session confidentiality matters.
• Test failure paths, malformed inputs, downgrade resistance, and recovery procedures.
• Keep cryptographic inventories and plan algorithm migration.
• Obtain expert review for high-impact systems.

Chapter Summary

Cryptography provides mechanisms for confidentiality, integrity, authentication, freshness, and support for non-repudiation. Symmetric encryption is efficient for bulk data but requires secure key sharing. Public-key cryptography enables authentication and key establishment but is computationally more expensive and depends on carefully selected assumptions. Hashes provide fixed-length integrity representations, while MACs authenticate messages to parties sharing a secret. Digital signatures provide public verification using private signing keys and public verification keys.

Authenticated encryption, secure key exchange, certificate validation, and disciplined key management are essential components of secure communication. PKI binds identities to public keys through certificates, certificate authorities, trust chains, and operational policies. TLS combines these mechanisms to authenticate endpoints, establish session keys, and protect application traffic.

Most practical failures arise from poor implementation or lifecycle management: weak randomness, nonce reuse, unauthenticated encryption, weak password storage, exposed secrets, disabled certificate validation, and failure to rotate or revoke keys. Secure design therefore requires both mathematical understanding and operational governance.

Key Terms

Cryptography: The discipline of protecting information using mathematical techniques.

Plaintext: Original readable or structured data before encryption.

Ciphertext: Data produced by encryption.

Symmetric encryption: Encryption using a shared secret key.

Asymmetric cryptography: Cryptography using related public and private keys.

Authenticated encryption: Encryption that also detects unauthorized modification.

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

Collision resistance: The property that finding two inputs with the same hash is computationally difficult.

MAC: A keyed tag providing message integrity and shared-secret authentication.

Digital signature: A private-key-generated value verifiable with a public key.

Nonce: A value intended for a single use or unique occurrence under a key.

Key exchange: A protocol for establishing shared secret material over a network.

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

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

Certificate authority: An entity that issues and signs certificates under defined policy.

PKI: The people, processes, policies, technologies, and trust relationships managing public keys.

Trust store: A collection of trusted root certificates or trust anchors.

Key derivation function: A function that derives cryptographic keys from secret input and context.

Cryptoperiod: The authorized period of use for a cryptographic key.

AEAD: Authenticated encryption with associated data.

Review Questions

Short Answer Questions

1. What security services can cryptography provide, and why does encryption alone not provide all of them?
2. Distinguish a cryptographic hash from encryption.
3. Why must an AES-GCM nonce not be reused with the same key?
4. What is the difference between a MAC and a digital signature?
5. What is the purpose of a certificate authority in PKI?

Long Answer Questions

1. Explain the operation, advantages, and limitations of symmetric encryption and authenticated encryption.
2. Describe how certificates and trust chains enable authentication in a TLS connection.
3. Explain Diffie–Hellman key exchange, authentication requirements, and forward secrecy.
4. Discuss the complete lifecycle of a cryptographic key, from generation through destruction.
5. Analyze at least five common cryptographic implementation failures and propose controls for each.

Analytical / Application Questions

1. A development team proposes storing passwords as unsalted SHA-256 hashes and encrypting database backups with a key committed to source control. Identify the risks and design a corrected approach.
2. A mobile application accepts any server certificate because certificate validation causes connection failures during renewal. Explain the attack and propose an operationally safe solution.
3. Design a high-level secure communication architecture for university microservices. Specify where certificates, mutual authentication, AEAD, key rotation, secrets management, and monitoring should be used.

Multiple Choice Questions with Answers

Question 1

Which mechanism is best suited to provide confidentiality and integrity for application data using one symmetric key?

A. Base64 encoding

B. Authenticated encryption with associated data

C. A plain cryptographic hash

D. A digital certificate

Correct Answer: B. Authenticated encryption with associated data

Question 2

What is the primary purpose of a unique salt in password storage?

A. To make passwords reversible

B. To prevent identical passwords from producing identical stored values

C. To replace the password KDF

D. To authenticate a TLS server

Correct Answer: B. To prevent identical passwords from producing identical stored values

Question 3

Which key is used to create a conventional digital signature?

A. The recipient’s public key

B. The sender’s public key

C. The signer’s private key

D. A certificate authority’s root certificate only

Correct Answer: C. The signer’s private key

Question 4

What security property does ephemeral Diffie–Hellman commonly provide when long-term keys are later compromised?

A. Forward secrecy

B. Password hashing

C. Data compression

D. Certificate revocation

Correct Answer: A. Forward secrecy

Question 5

Which statement about a cryptographic hash is correct?

A. It is designed to be decrypted with a public key

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

C. It automatically authenticates the message origin

D. It always produces a unique value for every possible input

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

Question 6

What is the main danger of disabling certificate validation in a client application?

A. The application cannot use symmetric encryption

B. An attacker may impersonate the server through a man-in-the-middle attack

C. Passwords become automatically longer

D. The client becomes unable to calculate hashes

Correct Answer: B. An attacker may impersonate the server through a man-in-the-middle attack

Question 7

In an AEAD operation, what does associated data represent?

A. Data that is authenticated but normally not encrypted

B. A second private key used for decryption

C. A replacement for the nonce

D. A password database

Correct Answer: A. Data that is authenticated but normally not encrypted

Question 8

Which item is normally a trust anchor in a PKI trust store?

A. An arbitrary end-user password

B. A trusted root CA certificate

C. A plaintext session key

D. A Base64-encoded document

Correct Answer: B. A trusted root CA certificate

Question 9

Why is nonce reuse particularly dangerous in AES-GCM?

A. It guarantees stronger authentication

B. It can compromise confidentiality and authentication

C. It converts the cipher into a password KDF

D. It automatically revokes the certificate

Correct Answer: B. It can compromise confidentiality and authentication

Question 10

Which practice best protects high-value private keys?

A. Embedding them in public source code

B. Storing them in URLs for convenience

C. Using controlled key storage such as an HSM with access auditing

D. Printing them in application logs

Correct Answer: C. Using controlled key storage such as an HSM with access auditing