Cryptography and Public Key InfrastructureIntroduction and ContextCryptography is the disciplined use of mathematical techniques to protect information and communications. In cyber security, it supports confidentiality, integrity, authentication, non-repudiation and accountability. These objectives are often represented by the CIA triad—confidentiality, integrity and availability—but cryptography primarily addresses confidentiality and integrity, while authentication and non-repudiation are enabled through cryptographic identities, digital signatures and certificates. Modern organisations use cryptography in web browsing, electronic banking, virtual private networks, mobile applications, cloud storage, software distribution and digital identity systems. However, cryptography is not simply the selection of an encryption algorithm. A secure system also requires sound key generation, secure storage, correct protocol design, certificate validation, lifecycle management and protection against human and operational failures. This chapter examines symmetric and asymmetric cryptography, hashing, digital signatures, certificates, public key infrastructure (PKI), secure protocols, key management, limitations and post-quantum developments. Learning ObjectivesBy the end of this chapter, you should be able to: - distinguish confidentiality, integrity, authentication and non-repudiation;
- apply symmetric encryption, asymmetric encryption and cryptographic hashing appropriately;
- explain digital signatures, certificates and certificate chains;
- describe the components and lifecycle of a PKI;
- evaluate key-management practices and common cryptographic failures;
- explain how TLS and related protocols use several cryptographic mechanisms together;
- assess ethical, governance, regulatory and post-quantum considerations.
1. Security Services and Cryptographic TerminologyA cryptographic design should begin with a security requirement rather than with an algorithm. The principal services are: | Service | Purpose | Typical mechanism |
|---|
| Confidentiality | Prevent unauthorised disclosure | Encryption | | Integrity | Detect unauthorised alteration | Hashes, MACs, signatures | | Authentication | Establish the identity or origin of an entity | MACs, signatures, certificates | | Non-repudiation | Provide evidence relating an action to a signing key | Digital signatures, governance and audit | | Freshness | Prevent replay of old messages | Nonces, timestamps, sequence numbers |
Plaintext is the original readable data. Ciphertext is the transformed result of encryption. A key is secret or public information that controls a cryptographic operation. Encryption transforms plaintext into ciphertext; decryption transforms ciphertext back into plaintext. A secure algorithm is normally designed to remain secure even when the algorithm is public. This principle, commonly associated with Kerckhoffs, means that security should depend on the secrecy of keys, not on keeping the algorithm secret. This supports public review, interoperability and replacement of compromised keys. 2. Symmetric CryptographySymmetric cryptography uses the same secret key, or mathematically related secret keys, for encryption and decryption. If Alice and Bob share a secret key K, a simplified model is: C = EK(P) P = DK(C) Here, P is plaintext, C is ciphertext, E is the encryption operation, D is the decryption operation and K is the secret key. The equations describe the intended inverse relationship; practical security also depends on a secure mode of operation, nonce or initialisation-vector handling and authentication. 2.1 Block and stream ciphersA block cipher processes fixed-size blocks. The Advanced Encryption Standard (AES) is the dominant general-purpose block cipher and supports 128-, 192- and 256-bit keys. AES has a 128-bit block size. The key size and block size are different properties: a larger key does not change the block size. A stream cipher generates a keystream that is combined with plaintext, commonly using exclusive OR (XOR). ChaCha20 is a widely used modern stream cipher. Reusing a nonce with the same key can be catastrophic in stream-cipher systems because relationships between plaintexts may be exposed. 2.2 Modes and authenticated encryptionA block cipher alone does not specify how long messages, repeated blocks or authenticity are handled. Older modes such as ECB can reveal repeated plaintext patterns and should not be used for ordinary structured data. CBC requires careful padding and integrity protection. CTR converts a block cipher into a counter-based stream-like construction but does not authenticate ciphertext. Authenticated encryption with associated data (AEAD) is generally preferred. It provides confidentiality and an authentication tag. Associated data, such as a protocol header, can be authenticated without being encrypted. AES-GCM and ChaCha20-Poly1305 are common AEAD constructions. The tag verifies that the ciphertext and associated data have not been altered. Verification must occur before decrypted data is trusted. A nonce is generally not secret, but it must be unique for a given key according to the algorithm's requirements. A practical system should use a well-designed nonce-management strategy rather than relying on accidental uniqueness. 2.3 Advantages and limitationsSymmetric algorithms are efficient and suitable for bulk data, disk encryption and high-volume network traffic. Their central difficulty is key distribution. If n parties each need a separate pairwise key, the number of shared keys is: K = n(n − 1) ÷ 2 where K is the number of pairwise keys and n is the number of parties, assuming every pair communicates directly and independently. For 100 parties, this gives 100 × 99 ÷ 2 = 4,950 keys. The calculation illustrates why large systems need centralised key-management services and asymmetric techniques. 3. Asymmetric CryptographyAsymmetric, or public-key, cryptography uses a mathematically related public key and private key. The public key may be distributed widely; the private key must remain controlled by its owner. For confidentiality, a sender encrypts using the recipient's public key and the recipient decrypts using the corresponding private key. For signatures, the owner signs using the private key and others verify using the public key. These are conceptually different operations and should not be described as simply “encrypting with the private key”. Public-key algorithms include RSA, elliptic-curve cryptography (ECC) and post-quantum schemes under development or standardisation. RSA security is associated with the difficulty of factoring large integers. ECC uses the difficulty of selected discrete-logarithm problems on elliptic curves. These statements describe security assumptions, not absolute mathematical guarantees. Asymmetric operations are generally slower and use larger representations than symmetric operations. Consequently, modern protocols usually use asymmetric cryptography to authenticate parties and establish a symmetric session key, then use AEAD for bulk traffic. This is called hybrid cryptography. 3.1 Key agreementIn a key-agreement protocol such as Diffie–Hellman or elliptic-curve Diffie–Hellman, two parties derive a shared secret without transmitting that secret directly. A basic finite-field version uses a public prime p and generator g. Alice selects secret a and sends: A = ga mod p Bob selects secret b and sends: B = gb mod p Alice computes S = B^a mod p, while Bob computes S = A^b mod p. Since both equal g^(ab) mod p, they obtain the same shared value. The variables p, g, a and b must satisfy the scheme's mathematical and security requirements. In practice, the shared value is passed through a key-derivation function rather than used directly as an encryption key. Unauthenticated Diffie–Hellman is vulnerable to a man-in-the-middle attack. Authentication, often supplied by certificates and signatures, is therefore essential. Ephemeral key agreement can provide forward secrecy: compromise of a long-term private key should not normally reveal previously recorded sessions, provided ephemeral secrets were properly generated and erased. 4. Cryptographic Hashing and Message AuthenticationA cryptographic hash function maps an input of arbitrary length to a fixed-length digest: h = H(M) where M is the message and h is the digest. Secure hash functions are designed to make it computationally infeasible to find a message producing a chosen digest, to find two different messages with the same digest, or to recover the original message from the digest. The exact security strength depends on the function and attack model. SHA-256 and SHA-3 are examples of modern general-purpose hash functions. MD5 and SHA-1 are unsuitable for collision-sensitive security applications. A hash is not encryption. It is normally one-way and does not contain enough information to recover the original message. Hashes are useful for file-integrity checking, digital signatures, content addressing and password-storage constructions. 4.1 Password protectionPasswords should not be stored as ordinary hashes or plaintext. A password-storage function should use a unique salt and a deliberately expensive, memory-hard or computationally costly process, such as Argon2id, scrypt or bcrypt. A simplified representation is: D = F(password, salt, cost) D is the stored derived value, F is the password-based derivation function, salt is a unique non-secret random value and cost represents configured work factors. The salt prevents identical passwords from producing identical stored values and defeats many precomputed tables. The cost parameter slows guessing and must be reviewed as hardware improves. It does not make a weak password strong; rate limiting and strong authentication remain important. 4.2 MACsA message authentication code (MAC) uses a shared secret to provide integrity and authentication to parties possessing that secret: T = MACK(M) T is the authentication tag, K is the shared key and M is the message. HMAC is a standard construction based on a cryptographic hash function. A MAC does not normally provide non-repudiation because both parties possess the same key and either could have generated the tag. 5. Digital SignaturesA digital signature binds a message to a private signing key. The signer computes a signature over the message, frequently after hashing it. A verifier uses the public key to check whether the signature is valid for the message and key. A valid signature normally provides evidence of integrity and origin relative to the private key. It does not prove that a human personally intended an action unless the surrounding identity, authorisation, device security, legal and audit controls support that conclusion. Non-repudiation is therefore both a technical and governance concept. Signatures are used for software releases, electronic documents, certificates, code commits, secure email and transactions. Private signing keys require strong protection, often through a hardware security module (HSM), smart card or trusted platform module. Key compromise may require revocation, re-issuance and investigation of previously signed material. 6. Certificates and Public Key InfrastructureA public-key certificate is a digitally signed data structure that associates an identity or subject with a public key. A certificate commonly contains the subject, public key, issuer, validity period, serial number, permitted uses and the issuer's signature. The issuer is usually a certificate authority (CA). A certificate does not make a key intrinsically trustworthy. It expresses that a CA performed specified validation and signed an assertion. The relying party must check whether the certificate is appropriate for the intended purpose, valid in time, issued by a trusted chain and not revoked or otherwise disqualified. 6.1 PKI componentsA PKI commonly includes: - Root CA: A trust anchor whose public key is distributed through operating systems, browsers or organisational trust stores.
- Intermediate CA: A subordinate CA that issues end-entity certificates, reducing exposure of the root private key.
- Registration authority (RA): Performs or coordinates identity verification and approval.
- Certificate repository or status service: Publishes certificates and revocation information.
- Relying party: Validates certificates and decides whether to trust them.
- Key owner or subscriber: Controls the private key associated with a certificate.
- Certificate policy and certification practice statement: Define assurance, responsibilities and operating procedures.
A chain of trust may run from an end-entity certificate to an intermediate CA and then to a trusted root. Chain validation includes signature verification, name constraints, validity periods, key-usage restrictions and policy checks. Trust should be limited to the required purpose; a certificate valid for server authentication should not automatically be accepted for code signing. 6.2 Revocation and statusCertificates may become untrustworthy before their expiry because of private-key compromise, inaccurate identity information, organisational change or a CA incident. Certificate revocation lists (CRLs) publish revoked serial numbers. The Online Certificate Status Protocol (OCSP) allows a relying party to request status for a certificate. Stapled status mechanisms can reduce privacy and availability problems by having the server provide signed status evidence. Revocation systems themselves introduce operational challenges. Offline systems, network failures, caching and inconsistent validation policies can cause different parties to reach different conclusions. Organisations must define fail-open and fail-closed behaviour according to risk. 7. TLS and Secure Protocol DesignTransport Layer Security (TLS) illustrates hybrid cryptography in practice. A simplified modern TLS exchange includes: - The client and server negotiate supported protocol versions and cryptographic suites.
- The server presents a certificate and proves possession of the corresponding private key.
- The parties perform authenticated key agreement.
- Both derive symmetric traffic keys using a key-derivation process.
- Application data is protected with an AEAD algorithm and integrity is checked.
The exact protocol details depend on the TLS version and configuration. TLS 1.3 removes many older options and normally uses ephemeral key agreement, supporting forward secrecy. Secure configuration also requires certificate-name validation, trusted-root management, protocol-version control, safe random-number generation and protection against downgrade attacks. Other secure protocols include IPsec for network-layer protection, SSH for secure remote administration and secure email systems that combine encryption and signatures. Security depends on correct endpoint validation: encryption to an impostor is still a security failure. 8. Key Management LifecycleKey management is often more important operationally than the choice between two reputable algorithms. A key lifecycle includes: - Requirement and classification: Identify data, users, legal obligations, retention periods and required assurance.
- Generation: Use an approved cryptographically secure random-number generator.
- Registration and distribution: Bind keys to identities and distribute them through protected channels.
- Storage and use: Restrict access, separate duties and prevent accidental exposure in logs or source code.
- Rotation: Replace keys according to risk, cryptoperiod, algorithm guidance and incident conditions.
- Backup and recovery: Protect backups with equivalent or stronger controls and test restoration.
- Revocation or suspension: Act quickly when a key or identity is no longer trustworthy.
- Destruction: Erase key material securely when retention obligations end.
Key-encryption keys can protect data-encryption keys, reducing exposure during storage and supporting controlled rotation. Access should follow least privilege, dual control and separation of duties. HSMs can protect high-value keys and provide audit evidence, but they do not compensate for incorrect authorisation policies or compromised endpoints. 9. Worked Application: Protecting a Healthcare PortalBackgroundThis illustrative case concerns a healthcare provider introducing an online portal for patients, clinicians and laboratories. The portal transmits personal and medical information and must support secure login, confidential communication and signed clinical documents. ProblemAn initial design proposes one long-lived AES key shared by all application servers, passwords stored as unsalted SHA-256 hashes and a self-signed server certificate. The design creates serious risks: compromise of one server exposes all traffic, password guessing is efficient, and users receive no independently verifiable server identity. AnalysisThe portal needs several distinct controls. Bulk traffic requires efficient authenticated encryption. User passwords require a password-specific derivation function. Server identity requires a certificate issued by a trusted CA or an appropriately managed private PKI. Clinical-document signing requires a controlled signing key and an audit process. Approach and solutionThe revised architecture uses TLS with certificate validation and ephemeral authenticated key agreement. Each session derives fresh symmetric traffic keys and uses AEAD. Application secrets are held in a secrets-management service, with high-value signing keys protected in an HSM. Passwords are processed with Argon2id using unique salts and a reviewed cost configuration. Role-based access control is enforced independently of encryption. Clinical documents are hashed and digitally signed by an authorised service. The system records the signer identity, signing time, document version and certificate status. Key rotation and revocation procedures are tested, and access logs are monitored for unusual use. Backups are encrypted using separately managed keys, and recovery is exercised. OutcomeThe design limits the effect of a single server compromise, improves server authentication, makes password cracking more expensive and provides evidence about document origin and integrity. It does not eliminate all risk: compromised user devices, incorrect authorisation or malicious insiders could still expose information. Learning points- Use different keys for different purposes and security domains.
- Combine encryption with authentication and endpoint validation.
- Treat key lifecycle, access control and monitoring as part of cryptographic security.
- A signature supports technical evidence but does not by itself settle legal responsibility.
10. Common Limitations and Failure ModesCryptography cannot protect data after legitimate decryption on a compromised endpoint. It cannot correct a wrong access-control decision, prevent social engineering or ensure that a user validates a certificate. Metadata such as timing, traffic volume and communicating parties may remain visible even when message content is encrypted. Frequent failures include hard-coded keys, predictable random numbers, nonce reuse, obsolete algorithms, unauthenticated encryption, certificate-validation bypasses, excessive trust-store entries, unprotected private keys, weak password storage and secrets committed to source-control systems. Developers may also misuse cryptographic libraries by selecting unsafe defaults or comparing authentication tags in a way that leaks timing information. A system should use well-reviewed, standardised libraries rather than implementing primitives independently. Security testing should include negative cases: altered ciphertext, expired certificates, unknown issuers, revoked keys, replayed messages, malformed inputs and unavailable status services. 11. Governance, Ethics and RegulationOrganisations must establish cryptographic policies covering approved algorithms, key sizes, certificate authorities, cryptoperiods, recovery, lawful access, incident response and disposal. Data-protection laws commonly require appropriate technical and organisational measures, but legal compliance is not achieved by encryption alone. Data minimisation, purpose limitation, access governance, retention control and breach response remain necessary. Encryption can protect vulnerable populations and support privacy, but it can also be used to conceal criminal activity. Decisions about exceptional access or key escrow require careful assessment because a universal decryption mechanism increases concentration of risk and may create a target. Security professionals should document proportionality, accountability and stakeholder impacts rather than treating cryptography as purely technical. 12. Post-Quantum ConsiderationsLarge-scale quantum computers could use Shor's algorithm to threaten widely deployed RSA and elliptic-curve public-key systems. Grover's algorithm gives a quadratic speed-up for generic search, which affects symmetric-key security differently; increasing symmetric key sizes can provide a practical mitigation, subject to implementation and algorithm assumptions. Post-quantum cryptography (PQC) seeks algorithms that run on conventional computers but are believed to resist relevant quantum attacks. Important families include lattice-based, hash-based, code-based and other structured constructions. They often involve larger public keys, signatures or ciphertexts and may introduce implementation and performance challenges. Organisations should inventory where public-key cryptography is used, identify long-lived confidential data and certificates, assess vendor support, and design systems that can replace algorithms without rebuilding every application. Hybrid key establishment can combine a conventional method with a PQC method during migration, provided the composition and implementation are specified by competent standards and vendors. “Harvest now, decrypt later” makes migration relevant today for information requiring long-term confidentiality. Best-Practice Checklist- Define the security service and threat model before selecting an algorithm.
- Prefer current, standardised AEAD modes for new symmetric encryption.
- Never reuse a nonce where the selected construction forbids reuse.
- Use public-key cryptography for authentication and key establishment, not bulk data where efficiency matters.
- Validate certificate chains, names, purposes, dates and status.
- Protect private keys with least privilege, secure hardware where justified, backup controls and audit.
- Use password-specific, salted and costly derivation functions.
- Separate keys by purpose, environment and data classification.
- Plan rotation, revocation, recovery and destruction before deployment.
- Monitor cryptographic dependencies and prepare for post-quantum migration.
Chapter SummaryCryptography provides essential mechanisms for confidentiality, integrity and authentication, but it must be implemented as part of a wider security architecture. Symmetric encryption is efficient for bulk data but requires secure key distribution. Asymmetric cryptography supports identity, signatures and key agreement, while hybrid protocols combine its authentication advantages with symmetric efficiency. Hashes provide fixed-length integrity representations, MACs authenticate messages shared by trusted parties, and digital signatures bind data to a private key. PKI establishes managed relationships between identities and public keys through certificates, CAs, trust stores, validation and revocation. TLS demonstrates how certificates, ephemeral key agreement, key derivation and AEAD operate together. Effective security depends on the complete key lifecycle, correct implementation, governance, endpoint security and careful handling of limitations. Finally, the potential impact of quantum computing requires inventory, crypto-agility and planned migration to post-quantum algorithms. Key TermsCryptography: The practice of protecting information using mathematical techniques. Symmetric encryption: Encryption using a shared secret key. Asymmetric cryptography: Cryptography using related public and private keys. Plaintext: Original readable information before encryption. Ciphertext: Transformed information produced by encryption. AEAD: Authenticated encryption with associated data. Nonce: A value intended for controlled use, often requiring uniqueness with a key. Hash function: A function producing a fixed-length digest from arbitrary input. Salt: A unique non-secret value used in password derivation. MAC: A keyed message authentication code. Digital signature: A private-key-generated value used to verify integrity and origin. Certificate: A signed binding between an identity and a public key. Certificate authority: An entity that issues and signs certificates. PKI: The people, policies, technologies and processes managing public-key trust. Trust anchor: A pre-trusted public key, usually a root CA. Revocation: Withdrawal of trust in a certificate before its expiry. Forward secrecy: Protection of past sessions if a long-term key is later compromised. HSM: Hardware security module used to protect and operate high-value keys. Post-quantum cryptography: Cryptography designed to resist anticipated quantum attacks. Review QuestionsShort Answer Questions- What is the difference between encryption and hashing?
- Why is AEAD generally preferred to unauthenticated encryption?
- What roles do a root CA and an intermediate CA perform?
- Why should passwords not be stored as ordinary SHA-256 hashes?
- What is forward secrecy?
Long Answer Questions- Compare symmetric and asymmetric cryptography in terms of performance, key distribution and typical applications.
- Explain how a certificate chain is validated by a relying party.
- Describe the complete lifecycle of a cryptographic key and identify controls at each stage.
- Explain how TLS combines certificates, key agreement and symmetric encryption.
- Discuss the technical and governance limitations of digital signatures as evidence of non-repudiation.
Analytical / Application Questions- An organisation encrypts database backups with one AES key shared by every administrator. Analyse the risks and propose a revised key-management design.
- A web application accepts any certificate presented by a server as long as the certificate is mathematically valid. Explain why this is insecure and identify the validation checks required.
- A financial institution must protect transaction records for twenty years. Evaluate why it should begin post-quantum planning now and propose a migration approach.
Multiple Choice Questions with AnswersQuestion 1Which mechanism is primarily designed to provide confidentiality for bulk data efficiently? A. Symmetric encryption B. Digital signature C. Certificate revocation D. Cryptographic hash Correct Answer: A. Symmetric encryption Question 2What is the main purpose of a salt in password storage? A. To make the password reversible B. To ensure identical passwords have different derived values C. To replace the need for a password D. To authenticate a TLS certificate Correct Answer: B. To ensure identical passwords have different derived values Question 3Which property is normally provided by a MAC but not by a public hash alone? A. A fixed-length output B. A shared-secret-based authenticity check C. Compression of the message D. Public verifiability without a key Correct Answer: B. A shared-secret-based authenticity check Question 4In a certificate chain, what is normally the trust anchor? A. The user's password B. The session nonce C. A trusted root CA public key D. The ciphertext Correct Answer: C. A trusted root CA public key Question 5Why is unauthenticated Diffie–Hellman vulnerable to a man-in-the-middle attack? A. It uses only symmetric keys B. It does not authenticate the communicating parties C. It cannot create a shared value D. It prevents public keys from being distributed Correct Answer: B. It does not authenticate the communicating parties Question 6Which practice is unsafe with an AEAD construction that requires nonce uniqueness? A. Using a unique nonce for every message under a key B. Authenticating associated data C. Reusing the same nonce with the same key D. Rejecting an invalid authentication tag Correct Answer: C. Reusing the same nonce with the same key Question 7What is the principal purpose of a digital signature? A. To provide evidence of integrity and possession of a signing private key B. To compress a document C. To hide all communication metadata D. To replace access control Correct Answer: A. To provide evidence of integrity and possession of a signing private key Question 8For 10 parties requiring independent pairwise symmetric keys, how many keys are needed under the pairwise model? A. 10 B. 20 C. 45 D. 100 Correct Answer: C. 45 Question 9Which development is most directly associated with a threat from Shor's algorithm? A. The compromise of RSA and elliptic-curve public-key systems B. The failure of all password policies immediately C. The removal of the need for hashing D. The guaranteed break of every AES implementation Correct Answer: A. The compromise of RSA and elliptic-curve public-key systems Question 10What is a major reason modern protocols use hybrid cryptography? A. Asymmetric cryptography is efficient for unlimited bulk data B. Symmetric cryptography cannot protect confidentiality C. Asymmetric methods assist authentication and key establishment, while symmetric methods efficiently protect traffic D. Certificates eliminate the need for session keys Correct Answer: C. Asymmetric methods assist authentication and key establishment, while symmetric methods efficiently protect traffic
|