Cryptography, PKI and Secure Communications

Introduction and context

Cryptography is the discipline of protecting information against unauthorised disclosure, alteration, forgery and repudiation. In network security it provides the mechanisms that allow two parties to communicate over an untrusted medium while obtaining appropriate guarantees about confidentiality, integrity, authenticity and accountability. These guarantees are not automatic consequences of “using encryption”. They depend on algorithms, protocols, key management, implementation quality, endpoint security and operational governance.

Modern security engineering combines several cryptographic techniques. Symmetric encryption protects data efficiently once a shared secret exists. Asymmetric cryptography solves important key-distribution and identity problems, although at higher computational cost. Hash functions provide fixed-length integrity and identification values. Digital signatures bind a message to a signing key and support authentication and non-repudiation claims. Public Key Infrastructure (PKI) connects public keys with identities through certificates and trust relationships. Protocols such as TLS, IPsec, SSH and VPN technologies apply these primitives to real communications.

Cryptography is also undergoing strategic change. Large-scale quantum computers could threaten widely used public-key algorithms, while symmetric cryptography and cryptographic hashes are generally more resilient when sufficiently large parameters are selected. Consequently, security professionals must understand not only how cryptography works, but also how to select, deploy, monitor, rotate and eventually replace it.

Learning objectives

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

1. Distinguish symmetric encryption, asymmetric encryption, hashing, message authentication and digital signatures.
2. Explain confidentiality, integrity, authentication, non-repudiation and forward secrecy.
3. Select appropriate cryptographic algorithms and modes for practical systems.
4. Describe certificates, certificate authorities, trust chains and key-lifecycle management.
5. Explain the operation and security properties of TLS, IPsec, SSH and VPNs.
6. Identify implementation weaknesses such as poor randomness, nonce reuse, obsolete algorithms and inadequate certificate validation.
7. Evaluate cryptographic choices in relation to governance, privacy, operational risk and post-quantum migration.

1. Security services and cryptographic design principles

A cryptographic design begins by identifying the security service required:

• Confidentiality: only authorised parties can read the data.
• Integrity: unauthorised modification can be detected.
• Authentication: an entity or message origin can be verified.
• Non-repudiation: a signature can provide evidence that a particular signing key was used, subject to legal and operational conditions.
• Availability: cryptography does not directly guarantee availability, but secure protocols must resist denial-of-service and resource-exhaustion attacks.

A useful distinction is between a primitive and a protocol. AES, SHA-256 and Ed25519 are primitives or algorithm families. TLS and IPsec are protocols that combine primitives with negotiation, identity, key exchange, message formats, state machines and error handling. A strong primitive used in a badly designed protocol may still produce an insecure system.

The principle of Kerckhoffs’s design states that a system should remain secure even when everything except the key is public. Secret algorithms generally hinder review and make migration difficult. Security should instead depend on well-studied algorithms, protected keys and carefully specified protocols.

Cryptographic strength is commonly discussed in bits of security. A generic idealised key-search attack against a key of length n requires approximately 2ⁿ trials in the worst case and about 2ⁿ⁻¹ trials on average. This is a conceptual estimate, not a universal performance formula: attacks may exploit structure, implementation flaws, weak passwords or reduced algorithm complexity. Effective security is limited by the weakest relevant component.

2. Symmetric cryptography

Symmetric cryptography uses the same secret key, or computationally related secret keys, for encryption and decryption. Its principal advantages are speed and suitability for bulk data. Its central challenge is securely distributing the key to every authorised participant.

2.1 Block and stream ciphers

A block cipher transforms fixed-size blocks under a secret key. AES operates on 128-bit blocks and supports keys of 128, 192 or 256 bits. The cipher alone does not specify how long messages are processed; a mode of operation performs that function.

A stream cipher generates a pseudorandom keystream that is combined with plaintext, commonly using exclusive OR. ChaCha20 is a widely deployed modern stream cipher. A nonce, or number used once, is normally required. Reusing a nonce with the same key can expose relationships between plaintexts and can be catastrophic in some constructions.

2.2 Encryption modes and authenticated encryption

Electronic Codebook (ECB) independently encrypts each block. Equal plaintext blocks produce equal ciphertext blocks, revealing patterns; ECB should therefore not be used for general data encryption.

CBC requires an initialisation vector and uses chaining. It can provide confidentiality, but it does not provide integrity by itself and requires careful padding and validation. Poor error handling can create padding-oracle vulnerabilities.

Counter mode turns a block cipher into a keystream generator. It is efficient and parallelisable, but nonce reuse under the same key is unsafe.

Authenticated Encryption with Associated Data (AEAD) combines confidentiality and integrity. AES-GCM and ChaCha20-Poly1305 are common AEAD constructions. They protect plaintext and can authenticate unencrypted context, called associated data, such as a protocol header. A successful decryption tag check must occur before plaintext is trusted or processed.

A general AEAD interface can be represented as:

Here, K is the secret key, N is a unique nonce for that key, P is plaintext, A is associated data, C is ciphertext and T is an authentication tag. Decryption accepts the message only if the tag verifies:

The notation describes the interface rather than a universal internal algorithm. The key and nonce lengths, tag length and nonce-uniqueness requirements depend on the selected AEAD construction. Nonces need not always be secret, but they must meet the construction’s uniqueness requirements.

2.3 Key derivation and passwords

A Key Derivation Function (KDF) derives one or more cryptographic keys from an input secret. HKDF is designed for deriving keys from high-entropy material. Passwords have low and predictable entropy, so password storage requires a deliberately expensive, salted password-hashing function such as Argon2id, scrypt or bcrypt rather than a fast hash alone.

A salt is public, unique per password record and prevents identical passwords from producing identical stored values. It does not need to be secret. Work factor, memory cost and parallelism should be selected according to current hardware and periodically reviewed. Password-derived encryption keys may also use a KDF, but password authentication and encryption-key management are separate design problems.

3. Hash functions, MACs and digital signatures

3.1 Cryptographic hash functions

A cryptographic hash function maps an arbitrary-length input to a fixed-length digest. Important properties include preimage resistance, second-preimage resistance and collision resistance. SHA-256 and SHA-3 are examples of current general-purpose hash families. MD5 and SHA-1 are unsuitable for collision-resistant security applications.

A digest is not encryption: it is not intended to be reversible. Hashes support file integrity checks, content addressing, password-hashing constructions and digital signatures. An unkeyed hash alone does not authenticate a message, because an attacker who changes the message can also recalculate its hash.

For an ideal n-bit hash, generic collision search has approximately 2ⁿᐟ² complexity because of the birthday effect. This is an approximation under an idealised model; structural weaknesses can make a real algorithm less secure.

3.2 Message Authentication Codes

A Message Authentication Code (MAC) uses a shared secret to provide integrity and origin authentication to parties possessing that secret. HMAC is a standard MAC construction based on a hash function. AEAD authentication tags also provide a MAC-like integrity function as part of authenticated encryption.

A MAC does not provide public verifiability. Either party holding the shared key could have generated the tag, so a MAC generally cannot establish to an independent third party which party created a particular message.

3.3 Digital signatures

A digital signature uses a private signing key and a corresponding public verification key. The signer computes a signature over a message or a securely encoded digest, and anyone with the public key can verify it. RSA-PSS, ECDSA and EdDSA are important signature families, though exact algorithm and parameter selection must follow current standards and implementation guidance.

Signatures require secure private-key protection and, for some algorithms, reliable per-signature randomness. Reuse or predictable generation of a nonce in ECDSA can reveal the private key. Deterministic signing methods can reduce dependence on runtime randomness where supported, but they do not eliminate the need for secure key storage.

A signature proves possession and use of a private key at signing time; it does not automatically prove that the human or organisation associated with the key intended every interpretation of the message. Identity binding, legal policy, timestamping, revocation and audit records remain important.

4. Asymmetric cryptography and key exchange

Asymmetric cryptography uses a public key that may be distributed openly and a private key that must remain secret. It supports encryption to a recipient, signatures by a signer and key-agreement protocols.

Public-key encryption is generally slower than symmetric encryption and is therefore commonly used to establish or protect a symmetric session key. In a hybrid design, two endpoints authenticate and agree on a session secret using asymmetric mechanisms, then use AEAD for application data.

4.1 Diffie–Hellman key agreement

Diffie–Hellman allows two parties to derive a common secret over a public channel. In the finite-field version, a public prime p and generator g are selected. Alice chooses secret a and sends A = g^a mod p. Bob chooses secret b and sends B = g^b mod p. Alice computes S = B^a mod p, while Bob computes S = A^b mod p. Both obtain S = g^(ab) mod p.

The private exponents a and b must be protected, and secure parameter groups are required. Unauthenticated Diffie–Hellman is vulnerable to a man-in-the-middle attack because an attacker can establish separate secrets with each endpoint. Authentication, commonly through certificates and signatures, is therefore essential.

Ephemeral Diffie–Hellman creates fresh private values for sessions. When implemented correctly and old ephemeral secrets are erased, compromise of a long-term private key does not ordinarily reveal recorded past sessions. This property is called forward secrecy.

Elliptic-curve key agreement, such as X25519, provides comparable functionality with smaller keys under appropriate assumptions. The mathematical details differ, but the engineering requirements remain: authenticated peers, approved parameters, secure randomness and correct implementation.

5. Public Key Infrastructure

PKI is a system of policies, roles, technologies and procedures for managing public keys and their association with identities. It is not merely a database of certificates.

A digital certificate is a signed data structure that binds a subject identity or identifier to a public key. A certificate normally includes the subject, issuer, validity interval, public key, permitted uses and a signature from the issuer. X.509 is the dominant certificate format in TLS and enterprise systems.

A Certificate Authority (CA) issues certificates. A root CA is a trust anchor configured in operating systems, browsers or applications. An intermediate CA is signed by a root or another CA and issues end-entity certificates. During path validation, a verifier checks the signature chain, validity periods, permitted key usage, subject names, policy constraints and revocation status according to the relevant rules.

A certificate does not make a key inherently trustworthy. Trust is contextual: a browser may trust a public web PKI root, while an enterprise may operate a private CA for internal services. Trust stores must be governed; adding an unauthorised root can enable interception of protected traffic.

5.1 Revocation and lifecycle management

Certificates may become invalid before expiry because a private key is exposed, a subject changes or an authority makes an error. Certificate Revocation Lists (CRLs) publish revoked serial numbers. Online Certificate Status Protocol (OCSP) provides a status response, although availability, privacy and stapling considerations affect deployment. Short-lived certificates can reduce reliance on revocation but require reliable automated renewal.

Key management should define generation, registration, activation, backup, distribution, storage, rotation, suspension, recovery, revocation, archival and destruction. Hardware Security Modules (HSMs) can protect high-value keys and perform operations without exposing private material to ordinary application memory. They do not correct a compromised application that is authorised to request arbitrary signatures.

6. Secure communication protocols

6.1 TLS

Transport Layer Security protects application protocols such as HTTPS, secure mail and many API connections. A simplified TLS 1.3 exchange is:

1. The client and server negotiate supported protocol parameters.
2. They exchange ephemeral key-agreement values.
3. The server presents a certificate and proves possession of its private key.
4. Both derive traffic keys from the handshake transcript and shared secret.
5. Application records are protected using AEAD.

The actual protocol contains transcript authentication, key separation, downgrade resistance and precise state transitions. TLS 1.3 removed or restricted many legacy mechanisms and normally provides forward secrecy through ephemeral key exchange. Certificate validation must check the hostname or application identity, chain, validity and key usage. Encrypting traffic without validating the peer can create a false sense of security.

TLS protects the communication channel between specified endpoints. It does not necessarily protect data after it reaches a server, prevent malicious authorised users, or secure a compromised endpoint. Metadata such as destination, timing and traffic volume may remain visible depending on the deployment.

6.2 IPsec

IPsec operates at the network layer and can protect IP traffic between hosts, gateways or security gateways. Encapsulating Security Payload (ESP) provides confidentiality, integrity and authentication when configured accordingly. Authentication Header (AH) provides integrity and authentication for selected IP information but is less commonly deployed because of routing and address-translation issues.

Internet Key Exchange (IKEv2) negotiates security associations, authenticates peers and establishes keys. Transport mode protects the payload of an IP packet, while tunnel mode encapsulates the original packet inside a new IP packet. Tunnel mode is widely used for site-to-site VPNs.

Security policies must specify which traffic is protected, peer identities, algorithms, lifetimes and handling of failures. Broad “encrypt everything” policies can create troubleshooting and availability problems if exceptions and routing are not designed carefully.

6.3 SSH

Secure Shell provides encrypted remote administration, file transfer and tunnelling. A typical SSH connection negotiates algorithms, performs a key exchange, authenticates the server using a host key and then authenticates the user using a password, public key or another method.

The first-use host-key decision is significant. If users blindly accept changed keys, a man-in-the-middle attack becomes possible. Enterprise deployments should manage host-key trust, use strong user authentication, restrict forwarding, log administrative actions and disable obsolete algorithms. SSH keys should have appropriate permissions, passphrases where practical, limited scope and a documented rotation or revocation process.

6.4 VPN architecture

A VPN creates a protected logical channel across an untrusted network. VPN security depends on endpoint identity, cryptographic configuration, routing, access control, logging and patching—not only on the presence of a tunnel. Remote-access VPNs should enforce multi-factor authentication, device posture controls where justified, least privilege and segmentation. Split tunnelling may improve performance but can allow a device to bridge an untrusted network and an internal network; full tunnelling increases central visibility and control but consumes more bandwidth.

7. Threats and implementation weaknesses

Common failures include:

• using obsolete algorithms, short keys or unsafe modes;
• reusing nonces with AEAD or stream ciphers;
• generating keys with predictable random values;
• storing private keys in source code, logs or unprotected backups;
• failing to validate certificate names, chains or revocation policy;
• accepting any certificate or disabling TLS verification to “fix” an error;
• using encryption without integrity protection;
• deriving keys directly from passwords without a salt and suitable work factor;
• leaking plaintext through error messages, memory dumps or telemetry;
• permitting downgrade to weaker protocol versions;
• using unauthenticated key exchange;
• retaining keys indefinitely without rotation or destruction;
• treating encrypted backups as secure when the decryption keys are stored beside them.

Side-channel attacks exploit information such as timing, power consumption, electromagnetic radiation or cache behaviour. Constant-time implementations, blinding, isolation and carefully reviewed libraries can reduce exposure. Custom cryptographic code should generally be avoided unless there is a compelling, expert-reviewed reason.

8. Selecting and evaluating cryptographic controls

A professional evaluation considers the data classification, threat model, required lifetime, performance, interoperability, regulatory obligations, operational capability and migration path. “Strongest available” is not always the best answer: a complex mechanism that cannot be monitored or renewed may create more risk than a standard, automated design.

A practical selection process is:

1. Identify assets, adversaries, trust boundaries and failure consequences.
2. Define required services: confidentiality, integrity, authentication and auditability.
3. Prefer current, standardised algorithms and protocol versions.
4. Use authenticated encryption for data in transit or at rest where appropriate.
5. Separate keys by purpose, environment and tenant.
6. Establish generation, storage, rotation, recovery and destruction procedures.
7. Test negative cases: invalid tags, expired certificates, revoked keys, replay, downgrade and unavailable status services.
8. Monitor cryptographic events and prepare replacement procedures.

Cryptographic agility means that algorithms, parameters and certificates can be replaced without redesigning the entire system. It should be planned through versioned interfaces, explicit algorithm identifiers, inventory of cryptographic dependencies and tested migration procedures. Agility does not mean enabling every algorithm; insecure options should be removed.

9. Post-quantum implications

A sufficiently capable quantum computer could use Shor’s algorithm to threaten widely deployed RSA and elliptic-curve public-key systems. Grover’s algorithm could reduce the effective brute-force security of ideal symmetric keys and hashes, approximately suggesting a square-root speedup in generic search. These are strategic implications rather than present-day instructions for selecting a particular algorithm.

Organisations face a “harvest now, decrypt later” risk: adversaries may record encrypted traffic today for future decryption, especially where information remains sensitive for decades. Appropriate responses include inventorying cryptographic use, identifying long-lived secrets, prioritising public-key dependencies, selecting standards-track post-quantum algorithms, testing hybrid key establishment and ensuring that protocol messages can accommodate new key and signature sizes.

Post-quantum migration introduces new implementation and operational questions: larger messages, performance on constrained devices, certificate size, hardware support, algorithm maturity and assurance against implementation attacks. Hybrid designs can provide transitional protection but increase complexity and should be adopted only where standardised and properly analysed. Symmetric keys should also be selected with adequate margins, while hash functions should be used in approved constructions rather than assumed secure merely because their digest is long.

10. Governance, ethics and compliance

Cryptographic controls affect privacy, lawful access, evidence handling and organisational accountability. Strong encryption protects citizens, patients, businesses and public institutions, but it can also restrict incident investigation if keys and access procedures are poorly governed. Key escrow or recovery mechanisms may support business continuity, but they create high-value targets and can undermine end-to-end confidentiality.

Policies should define authorised access, separation of duties, emergency recovery, retention, audit logging and independent review. Personal data should not be placed in logs merely because a channel is encrypted. Certificate issuance must be controlled to prevent fraudulent identities, and automated systems must protect signing authority from abuse.

Security professionals should avoid claiming that a digital signature proves human intent, that a certificate guarantees a trustworthy organisation, or that encrypted traffic is harmless. Technical claims should be bounded by the assumptions and evidence supporting them.

Applied case: illustrative healthcare API migration

Background

An illustrative regional healthcare provider operates mobile applications, laboratory systems and partner APIs. Several services use TLS, but certificates are manually renewed, some APIs use static shared secrets, and an old integration uses CBC-mode encryption without reliable message authentication.

Problem

An audit identifies expired-certificate outages, inconsistent hostname validation and uncertainty about which systems hold production private keys. The provider also needs to protect long-lived medical records against future cryptographic advances.

Analysis

The principal risks are not simply weak algorithms. They include unmanaged key ownership, inadequate inventory, unauthenticated data, poor renewal processes and excessive trust between partner networks. Static secrets cannot provide strong partner identity separation or convenient rotation. The old encryption design permits undetected modification if an attacker can alter ciphertext.

Approach and solution

The provider creates a cryptographic asset inventory covering certificates, keys, algorithms, protocols, data lifetimes and responsible owners. Public-facing certificates are issued through an automated CA workflow with monitored renewal. Private keys for high-value services are generated and used in managed HSM-backed services. APIs adopt mutual TLS for service identity and AEAD-protected application messages where end-to-end protection is required beyond the TLS termination point.

Legacy CBC encryption is replaced with a standard AEAD construction, with explicit nonce-management rules and test cases for tag failure. Partner access is segmented and least privilege is applied. TLS verification is enforced in clients, while certificate and key events are sent to a security monitoring platform. The provider records data-retention periods and prioritises post-quantum testing for long-lived records and externally exposed key exchanges.

Outcome

The organisation reduces manual renewal failures, gains ownership visibility and detects unauthorised certificate or key activity more quickly. The migration also reveals that some applications cannot safely process larger post-quantum messages, allowing remediation to begin before a forced replacement.

Learning points

The case demonstrates that cryptography is a lifecycle and architecture discipline. Algorithm selection, identity, automation, monitoring, endpoint behaviour and migration planning must be addressed together. Encryption added at a single network boundary does not necessarily protect data throughout its lifecycle.

Best-practice checklist

• Prefer standard, reviewed libraries and protocols.
• Use AEAD rather than encryption without authentication.
• Generate keys with approved cryptographic random generators.
• Never reuse a nonce where the selected construction forbids it.
• Validate certificate identity, chain, time and policy; do not bypass errors.
• Protect private keys with least privilege and appropriate hardware or platform controls.
• Separate keys by purpose, tenant and environment.
• Automate certificate renewal and monitor failures.
• Maintain a cryptographic inventory and tested incident-revocation process.
• Design for forward secrecy and cryptographic agility.
• Test failure, downgrade, replay, compromise and recovery scenarios.
• Include post-quantum requirements in procurement and architecture reviews.

Chapter Summary

Cryptography provides mechanisms for confidentiality, integrity and authentication, but secure outcomes depend on complete protocols and disciplined key management. Symmetric encryption is efficient for bulk data; asymmetric mechanisms support identity, signatures and key agreement. AEAD constructions should normally be preferred because they combine confidentiality with integrity. Hash functions provide fixed-length digests but do not authenticate data without a key. MACs authenticate messages to parties sharing a secret, whereas digital signatures support public verification.

PKI binds identities to public keys through certificates and trust chains. Certificate validation, revocation, issuance controls and private-key protection are as important as the certificate format itself. TLS, IPsec, SSH and VPNs apply these concepts at different layers and have distinct endpoint, routing and operational limitations. Weak randomness, nonce reuse, disabled validation, obsolete algorithms and unmanaged keys are frequent causes of failure.

Professional practice requires threat modelling, standard algorithms, lifecycle governance, monitoring, automation and tested recovery. Quantum computing creates a need to inventory public-key dependencies, address long-lived confidentiality and plan standards-based migration. Cryptographic security is therefore an ongoing engineering and governance process rather than a one-time choice of an encryption algorithm.

Key Terms

Cryptography: 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.

AEAD: Authenticated Encryption with Associated Data; encryption that also authenticates ciphertext and selected unencrypted data.

Nonce: A value intended for controlled, often single, use with a cryptographic key.

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

MAC: A keyed integrity and authentication code shared by communicating parties.

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

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

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

PKI: Policies, authorities, technologies and procedures for managing public-key trust.

Certificate Authority: An entity that issues and signs digital certificates.

Trust anchor: A public key or root certificate accepted as a starting point for validation.

Certificate revocation: The process of invalidating a certificate before its expiry.

TLS: A protocol for protecting application communications over networks.

IPsec: A suite for protecting IP-layer communications.

SSH: A protocol for secure remote access, administration and tunnelling.

VPN: A protected logical network connection over an untrusted network.

Cryptographic agility: The ability to replace algorithms, keys or parameters in a controlled manner.

Post-quantum cryptography: Cryptographic methods intended to resist attacks from large-scale quantum computers.

Review Questions

Short Answer Questions

1. What are the four principal security services provided by cryptographic controls?
2. Why is AEAD generally preferred to encryption without authentication?
3. What is the difference between a MAC and a digital signature?
4. What role does a root CA play in certificate validation?
5. Why is nonce reuse dangerous in many AEAD or stream-cipher designs?

Long Answer Questions

1. Explain how a hybrid TLS design combines asymmetric and symmetric cryptography.
2. Describe certificate issuance, chain validation and revocation in a PKI.
3. Compare TLS, IPsec and SSH in terms of layer, typical use and operational concerns.
4. Discuss the complete lifecycle of a high-value private key.
5. Explain how post-quantum computing affects present-day cryptographic planning.

Analytical / Application Questions

1. An application disables certificate validation because a partner certificate has expired. Analyse the security consequences and propose a controlled remediation.
2. A service encrypts two messages with AES-GCM using the same key and nonce. Explain the likely risks and design a corrective key and nonce-management approach.
3. Design a cryptographic migration plan for an organisation with public web services, site-to-site VPNs, SSH administration and medical records that must remain confidential for twenty years.

Multiple Choice Questions with Answers

Question 1

Which property is provided by authenticated encryption with associated data (AEAD)?

A. Confidentiality and integrity authentication

B. Availability without any key management

C. Anonymity of every communicating endpoint

D. Protection against all endpoint compromise

Correct Answer: A. Confidentiality and integrity authentication

Question 2

What is the main purpose of a salt in password storage?

A. To make the password secret during transmission

B. To prevent identical passwords from producing identical stored values

C. To replace the password-hashing work factor

D. To provide public-key authentication

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

Question 3

Why is unauthenticated Diffie–Hellman vulnerable to a man-in-the-middle attack?

A. It cannot create a shared secret

B. It uses only symmetric encryption

C. It does not establish the identity of the communicating peer

D. It requires certificates for every packet

Correct Answer: C. It does not establish the identity of the communicating peer

Question 4

Which component normally binds an identity to a public key in PKI?

A. A digital certificate

B. A nonce

C. A firewall rule

D. A plaintext hash without a key

Correct Answer: A. A digital certificate

Question 5

Which statement about a cryptographic hash is correct?

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

B. It provides confidentiality by itself

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

D. It always authenticates the message origin

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

Question 6

What is a principal benefit of ephemeral Diffie–Hellman?

A. It removes the need for peer authentication

B. It can provide forward secrecy when implemented correctly

C. It eliminates all certificate validation

D. It makes symmetric encryption unnecessary

Correct Answer: B. It can provide forward secrecy when implemented correctly

Question 7

Which practice creates a serious risk when using an AEAD construction?

A. Using a unique nonce with each key

B. Verifying the authentication tag before processing plaintext

C. Reusing a nonce with the same key

D. Separating keys by environment

Correct Answer: C. Reusing a nonce with the same key

Question 8

What does IPsec tunnel mode typically do?

A. Encapsulates an original IP packet inside a new IP packet

B. Signs only an application username

C. Replaces all routing decisions with DNS

D. Encrypts only a password database

Correct Answer: A. Encapsulates an original IP packet inside a new IP packet

Question 9

What is the main security concern with blindly accepting a changed SSH host key?

A. It disables file compression

B. It can permit a man-in-the-middle attack

C. It prevents public-key authentication permanently

D. It causes nonce reuse in AES-GCM

Correct Answer: B. It can permit a man-in-the-middle attack

Question 10

Why should organisations begin post-quantum planning before large quantum computers exist?

A. All current symmetric algorithms have already failed

B. Recorded data may be decrypted later and migrations take time

C. TLS cannot currently use certificates

D. Quantum computers make password salts ineffective

Correct Answer: B. Recorded data may be decrypted later and migrations take time