Cryptography, Key Management and Trust Services

Introduction and Context

Cryptography is the discipline of protecting information through mathematical techniques that control confidentiality, integrity, authentication, and non-repudiation. It is a foundational capability of information security rather than a complete security solution. Encryption cannot compensate for compromised endpoints, poor access control, insecure key storage, or flawed operational procedures. Consequently, postgraduate security practice requires both technical understanding and critical evaluation of cryptographic systems across their entire lifecycle.

Modern organisations use cryptography in web communication, mobile applications, payment systems, identity management, cloud services, software distribution, databases, virtual private networks, and industrial control systems. These applications rely on several related technologies: symmetric encryption, asymmetric cryptography, cryptographic hash functions, message authentication codes, digital signatures, public key infrastructure (PKI), certificates, trust services, and key-management processes.

This chapter examines how these mechanisms work, how they should be selected and deployed, and why implementation and governance failures frequently undermine mathematically strong algorithms.

Learning Objectives

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

1. Distinguish confidentiality, integrity, authentication, and non-repudiation requirements.

2. Compare symmetric and asymmetric cryptographic systems and identify appropriate use cases.

3. Explain hashing, message authentication codes, authenticated encryption, and digital signatures.

4. Evaluate PKI, certificate chains, trust anchors, revocation, and trust services.

5. Design and assess cryptographic key lifecycles and key-management controls.

6. Analyse protocol and implementation risks, including randomness failures, misuse, downgrade attacks, and side channels.

7. Evaluate cryptographic decisions from technical, organisational, regulatory, and ethical perspectives.

1. Security Services and the Cryptographic Model

A cryptographic system normally consists of a plaintext message, a cryptographic transformation, a key, and a resulting ciphertext or verification value. An encryption algorithm is public or assumed to be known; security should depend on the secrecy and protection of the key. This principle, commonly associated with Kerckhoffs, is central to sound engineering: proprietary secrecy of an algorithm is not a substitute for a protected key and public scrutiny.

The principal security services are:

• Confidentiality: preventing unauthorised disclosure.
• Integrity: detecting unauthorised alteration.
• Authentication: establishing the identity or origin of a communicating party or message.
• Non-repudiation: providing evidence that can support attribution of an action, subject to legal, procedural, and technical conditions.
• Accountability: associating events with entities through protected records and identity controls.

Cryptography contributes to all of these services, but not always independently. For example, encryption alone does not necessarily provide integrity. A system that encrypts data without authenticating it may be vulnerable to modification, padding-oracle attacks, or message reordering. Contemporary designs therefore favour authenticated encryption or a carefully designed combination of encryption and authentication.

Threat modelling should precede algorithm selection. A designer should identify assets, adversaries, trust boundaries, failure consequences, regulatory requirements, data retention periods, and the anticipated cryptographic lifetime of the data. Protecting a public brochure and protecting long-lived medical records do not require the same key-management architecture.

2. Symmetric Cryptography

Symmetric cryptography uses the same secret key, or keys that are computationally straightforward to derive from one another, for encryption and decryption. Its major strengths are speed, relatively low computational cost, and suitability for large data volumes.

A block cipher transforms fixed-length blocks under a secret key. AES, standardised with 128-, 192-, and 256-bit keys, is the dominant general-purpose block cipher. A block cipher must be used with an operating mode. ECB mode should not be used for ordinary confidential data because identical plaintext blocks produce identical ciphertext blocks, revealing patterns. More suitable authenticated-encryption modes include GCM and CCM; other contexts may use modes such as CTR or CBC only with separately designed and correctly implemented authentication.

Authenticated encryption with associated data (AEAD) protects both confidential plaintext and the integrity of selected unencrypted metadata. Conceptually, an AEAD operation takes a key, nonce, plaintext, and associated data and produces ciphertext and an authentication tag. The recipient verifies the tag before releasing or processing the plaintext. Associated data might include a protocol version, record identifier, or sender context.

Nonce management is critical. In modes such as GCM, nonce reuse with the same key can seriously compromise confidentiality and authentication. A nonce need not always be secret, but it must satisfy the uniqueness and construction requirements of the selected algorithm. Systems should use standards-based nonce generation, enforce uniqueness across devices and restarts, and rotate keys when design limits require it.

A stream cipher generates a keystream combined with plaintext, commonly through an exclusive-OR operation. Reusing the same keystream for two messages can expose relationships between the plaintexts. ChaCha20-Poly1305 is a widely deployed AEAD construction, particularly useful where software performance or hardware acceleration characteristics favour it.

Symmetric cryptography creates a distribution problem. If n parties need independent pairwise keys, the number of pairwise relationships is n(n−1)/2. This grows approximately with the square of n and becomes operationally difficult in large organisations. Hierarchical key-encryption keys, group keys, session keys, and centralised key-management systems reduce this burden, but introduce their own trust and availability dependencies.

Worked Example: Pairwise Key Growth

Suppose 100 systems must communicate using unique pairwise symmetric keys. The number of keys is:

n(n−1)/2 = 100 × 99 / 2 = 4,950.

This calculation assumes every pair requires a separate key and that keys are not shared among groups. A central key-distribution service or a hybrid public-key system can reduce the number of long-term keys that must be manually managed.

3. Asymmetric Cryptography

Asymmetric, or public-key, cryptography uses a related key pair: a public key that may be distributed and a private key that must be protected. The mathematical relationship allows operations such as encryption for a recipient, digital signature generation, and signature verification.

Public-key encryption is generally slower than symmetric encryption and is therefore usually used to establish or protect a symmetric session key rather than to encrypt large files. In a hybrid design, the parties use public-key techniques to authenticate and establish a shared secret, then use AEAD for application data.

RSA remains important in legacy systems, although new deployments increasingly favour elliptic-curve cryptography (ECC) or modern protocols based on elliptic-curve Diffie–Hellman. RSA security depends on the difficulty of factoring large integers and requires secure padding schemes such as RSA-OAEP for encryption and RSA-PSS for signatures. Raw RSA or obsolete padding constructions should not be used.

Diffie–Hellman key agreement allows two parties to establish a shared secret over an untrusted channel. The basic exchange does not by itself authenticate the parties and is therefore vulnerable to man-in-the-middle attacks unless combined with certificates, pre-shared keys, authenticated signatures, or another authentication mechanism. Ephemeral Diffie–Hellman keys provide forward secrecy when long-term private-key compromise does not permit retrospective decryption of recorded sessions.

ECC achieves comparable security with shorter keys than traditional finite-field systems, reducing bandwidth and computational requirements. Its implementation is nevertheless difficult: secure parameter choices, validated libraries, constant-time operations, and correct validation of public inputs are essential.

Post-quantum cryptography addresses the possibility that sufficiently capable quantum computers could undermine widely used public-key schemes based on factoring and discrete logarithms. Symmetric cryptography is affected differently; increasing key sizes can mitigate known quantum search advantages. Organisations should inventory cryptographic dependencies, prioritise long-lived confidential data, and plan migration through crypto-agility rather than waiting for an emergency replacement.

4. Hashing, MACs and Authenticated Data

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

• Preimage resistance: given a digest, finding an input that produces it should be computationally infeasible.
• Second-preimage resistance: given one input, finding a different input with the same digest should be infeasible.
• Collision resistance: finding any two distinct inputs with the same digest should be infeasible.
• Avalanche behaviour: a small input change should produce a substantially different digest.

SHA-256 and SHA-3 are examples of general-purpose cryptographic hash functions. MD5 and SHA-1 are unsuitable for collision-resistant security applications. A hash does not encrypt data and does not prove who generated it. Anyone can calculate a hash of modified content.

A message authentication code (MAC) combines a secret key with a message to produce an authentication value. HMAC, based on a cryptographic hash function, is a mature construction. A MAC provides integrity and origin authentication to parties sharing the secret, but it does not provide public verifiability or strong non-repudiation because either party could have generated the value.

Passwords should not normally be stored as ordinary hashes. Password-based derivation functions such as Argon2id, scrypt, or properly configured bcrypt apply a salt and deliberately expensive computation. A unique salt prevents identical passwords from having identical stored values and reduces the value of precomputed tables. Work factors must be calibrated to current hardware and reviewed periodically. Password hashing does not protect against online guessing unless accompanied by rate limiting and account controls.

5. Digital Signatures

A digital signature is generated using a private key and verified using the corresponding public key. It normally provides integrity, evidence of origin, and public verifiability. Signature systems generally sign a digest or a structured representation of the message rather than applying a costly public-key operation directly to an arbitrarily large message.

A signature does not automatically establish the identity of the signer. That conclusion depends on how the public key was bound to an identity, whether the private key was controlled by the alleged signer, whether the signing process was authorised, and whether the key was valid at the relevant time. Legal non-repudiation therefore involves evidence, governance, audit trails, certificate policy, and institutional controls in addition to mathematics.

Common risks include signing ambiguous or malleable data formats, failing to validate the algorithm identifier, accepting weak or unexpected key types, and verifying a signature over one representation while displaying another to the user. Secure systems define canonical formats and bind signatures to context, purpose, audience, and transaction details.

6. Public Key Infrastructure and Trust Services

PKI is a framework for creating, distributing, validating, revoking, and governing public-key certificates. A certificate is a digitally signed data structure that binds a subject identity or name to a public key, together with constraints such as validity period, key usage, issuer, and policy information.

A typical certificate chain contains an end-entity certificate, one or more intermediate certification authority (CA) certificates, and a trusted root or trust anchor. The root is generally distributed through an operating system, browser, enterprise platform, or application trust store. Chain validation normally includes signature verification, validity-period checks, issuer constraints, key-usage and extended-key-usage checks, name matching, policy processing where applicable, and revocation status evaluation.

A CA does not make an identity true merely by issuing a certificate. It attests that specified validation procedures were followed. Trust depends on the CA’s certificate policy, registration practices, protection of signing keys, auditability, incident response, and the relying party’s decision to accept that CA.

Certificate revocation is needed when a private key is compromised, a certificate is misissued, or the subject relationship is no longer valid. Certificate revocation lists can be large and slow to distribute. Online Certificate Status Protocol (OCSP) provides an online status query, while stapling allows a server to present recent status evidence. Revocation designs must consider availability: an overly strict failure mode may deny legitimate service during a status-service outage, whereas an overly permissive mode may accept compromised certificates.

Trust services extend beyond TLS. They include code-signing certificates, document-signing services, timestamping authorities, identity proofing, electronic seals, hardware-backed signing, and managed key services. Their assurance depends on documented policies, separation of duties, protected audit records, and reliable time sources.

7. Protocols and Secure Communication

TLS illustrates the integration of cryptographic mechanisms. A modern TLS deployment negotiates protocol parameters, authenticates a server through a certificate, establishes shared session secrets, and protects records with authenticated encryption. Configuration must disable obsolete protocol versions, weak cipher suites, insecure renegotiation behaviour, and unauthenticated fallback paths. Certificate validation must occur in the client; encryption alone does not prevent a man-in-the-middle attack.

Secure protocol analysis asks more than whether encryption is present. It examines identity binding, transcript integrity, downgrade resistance, key separation, replay handling, nonce construction, error behaviour, endpoint authentication, and recovery after compromise. Protocols should be selected from well-reviewed standards rather than assembled from individually plausible primitives.

Threats include downgrade attacks, replay, reflection, message truncation, cross-protocol confusion, certificate substitution, weak randomness, and implementation flaws. Version negotiation and algorithm agility must be constrained: unrestricted agility can become an attack surface, while no agility makes future migration difficult.

8. The Cryptographic Key Lifecycle

Key management is often more important operationally than algorithm selection. A complete lifecycle includes:

1. Requirements and classification: identify data sensitivity, users, legal obligations, retention, and recovery needs.

2. Generation: create keys using approved cryptographic random-number generators and suitable entropy.

3. Registration and activation: record ownership, purpose, algorithm, parameters, creation time, and status.

4. Distribution: deliver keys through authenticated and protected channels, preferably using automated services.

5. Storage and use: protect private and symmetric keys with access control, encryption at rest, hardware security modules (HSMs), secure enclaves, or other appropriate mechanisms.

6. Rotation and renewal: replace keys according to exposure, usage limits, compromise risk, and policy rather than arbitrary schedules alone.

7. Backup and recovery: preserve availability without creating uncontrolled copies. Key backups should be encrypted, access-controlled, tested, and geographically or logically separated where appropriate.

8. Suspension and revocation: stop use when compromise or loss is suspected.

9. Destruction: securely erase keys and validate that obsolete copies are removed or rendered inaccessible.

10. Audit and evidence: maintain tamper-evident records of administrative and cryptographic events.

Key separation is a core design principle. Different keys should be used for different purposes, such as encryption, signing, authentication, and key wrapping. Domain separation reduces the consequences of misuse. Dual control and split knowledge can ensure that no individual can unilaterally access highly sensitive key material.

HSMs provide hardened environments for key generation and cryptographic operations. They do not eliminate risk: poor configuration, insecure administrative procedures, compromised applications requesting valid operations, or inadequate backup governance can still cause failure. Cloud key-management services similarly provide valuable controls but require careful assessment of tenant isolation, provider access, regional availability, logging, deletion semantics, and exit arrangements.

9. Implementation Risks and Assurance

Cryptographic failures commonly result from implementation rather than broken mathematics. Major risks include:

• Weak or predictable random-number generation.
• Hard-coded keys, credentials, salts, or nonces.
• Reuse of nonces or initialization vectors where uniqueness is required.
• Insecure default configurations and obsolete algorithms.
• Incorrect certificate validation or hostname matching.
• Timing, cache, power, or electromagnetic side channels.
• Padding-oracle and error-message leakage.
• Key material exposed in logs, crash dumps, memory, source repositories, or backups.
• Truncated authentication tags or unauthenticated metadata.
• Failure to verify signatures before processing content.
• Insecure key recovery and emergency access procedures.
• Dependency vulnerabilities and supply-chain compromise.

Constant-time implementation is important for algorithms whose operations may reveal secret-dependent timing. Memory management, compiler behaviour, hardware characteristics, and API design all affect this property. Developers should use vetted libraries with safe interfaces instead of implementing primitives themselves.

Assurance practices include threat modelling, secure coding standards, independent review, test vectors, negative testing, fuzzing, formal protocol analysis where justified, penetration testing, key-compromise exercises, and continuous vulnerability monitoring. Cryptographic inventories should identify algorithms, libraries, certificates, keys, owners, systems, data categories, and expiry or migration dependencies.

10. Governance, Ethics and Regulation

Cryptographic governance must balance confidentiality with lawful access, safety, accountability, and resilience. Deliberately weakening encryption or creating universal backdoors introduces systemic risk because the weakness may be discovered or exploited by unintended parties. Access to protected data should instead be governed through narrowly scoped authorisation, endpoint controls, audited investigative procedures, and independent oversight.

Organisations should define cryptographic standards, approved algorithms, minimum parameters, key ownership, exception processes, incident response, retention, destruction, and post-quantum migration responsibilities. Regulatory obligations may require protection of personal data, payment information, health records, or export-controlled technology. Compliance, however, is not equivalent to security; controls must be evaluated against realistic threats and operational evidence.

Privacy-preserving cryptography, including pseudonymisation, secure multiparty computation, homomorphic encryption, and zero-knowledge proofs, can reduce disclosure in specialised applications. These techniques may impose substantial performance, usability, and governance costs, so their adoption should follow a clear threat and value analysis.

Artificial intelligence creates relevant cryptographic concerns. AI systems require protection of training data, model artefacts, credentials, APIs, and provenance records. Digital signatures and hashes can support model and dataset integrity, but they do not prove that data are unbiased or that a model is safe. Conversely, AI-assisted code generation must not be trusted to select cryptographic APIs without expert review, because plausible-looking code can contain subtle nonce, validation, or key-storage errors.

11. Illustrative Case: Certificate Compromise in an Online Service

Background

An online financial service uses TLS certificates issued by a commercial CA, a cloud key-management service for application secrets, and automated deployment pipelines. The service processes customer transactions and retains audit records.

Problem

A developer accidentally commits a private key for a test certificate to a public source repository. The certificate is mistakenly valid for a production subdomain. Automated monitoring detects the exposure two days later, but the organisation cannot initially determine whether the certificate was used by an attacker.

Analysis

The incident affects more than confidentiality. An attacker possessing the private key may impersonate the service if clients accept the certificate and the attacker can intercept or redirect traffic. The organisation must determine certificate scope, validity, deployment locations, DNS and network exposure, logs, and whether the key was used for signing or encryption. It must also assess whether the same key was reused in other environments.

Approach and Solution

The incident team first disables the exposed key and revokes the certificate. It issues a new certificate with a newly generated key, not a copied replacement. DNS, load balancers, containers, repositories, backups, and deployment secrets are searched for residual copies. Logs are examined for suspicious connections, certificate use, administrative actions, and unusual transaction patterns.

The organisation then introduces automated secret scanning, protected branches, short-lived certificates, environment-specific keys, HSM-backed production operations, and mandatory certificate inventory. Deployment policies prevent test certificates from containing production names. Access to certificate issuance is separated from application development, and compromise exercises are added to incident-response testing.

Outcome

The immediate certificate risk is contained, and no fraudulent transactions are identified. More importantly, the organisation improves its lifecycle controls: discovery, ownership, rotation, revocation, monitoring, and evidence collection become measurable processes rather than informal responsibilities.

Learning Points

The case demonstrates that certificate security depends on private-key protection, inventory accuracy, revocation speed, monitoring, and organisational separation of duties. A valid certificate is not evidence that a system is currently trustworthy; it is one input into a broader validation and governance process.

12. Best Practices and Contemporary Direction

Effective cryptographic programmes should:

• Prefer current, publicly reviewed standards and well-maintained libraries.
• Use AEAD for new application encryption unless a justified alternative exists.
• Separate keys by purpose, environment, tenant, and sensitivity.
• Automate certificate discovery, renewal, deployment, and revocation.
• Treat randomness, nonce uniqueness, and certificate validation as design requirements.
• Protect high-value keys with hardware-backed controls and dual administration.
• Maintain a cryptographic asset inventory and documented ownership.
• Test backup, recovery, revocation, and compromise procedures.
• Minimise cryptographic exceptions and record risk acceptance.
• Design for crypto-agility and post-quantum migration without enabling unsafe algorithm negotiation.
• Include human factors, usability, accessibility, and operational resilience in security evaluation.

The future of cryptography will involve hybrid classical and post-quantum protocols, stronger hardware-backed identity, confidential computing, automated certificate ecosystems, privacy-enhancing computation, and formal verification of security-critical components. These developments do not remove the need for foundational discipline. Secure systems still depend on sound requirements, correct implementation, protected keys, trustworthy identity processes, and effective governance.

Chapter Summary

Cryptography provides mechanisms for confidentiality, integrity, authentication, and evidence, but its assurance depends on design and operation. Symmetric cryptography is efficient for bulk data but creates key-distribution and lifecycle challenges. Asymmetric cryptography supports key agreement, identity binding, and digital signatures, but is computationally more expensive and requires careful authentication. Hashes provide integrity-related fingerprints but not secrecy or identity; MACs authenticate messages to parties sharing a secret; digital signatures provide public verifiability when private-key control and identity binding are credible. AEAD should generally be preferred for new application encryption.

PKI uses certificates, certification authorities, trust anchors, validation rules, and revocation mechanisms to support scalable identity and trust services. Key management spans generation, distribution, storage, use, rotation, recovery, revocation, destruction, and audit. Implementation risks—including weak randomness, nonce reuse, side channels, poor validation, exposed keys, and insecure defaults—frequently defeat strong algorithms. Professional cryptographic practice therefore combines technical controls with governance, incident response, ethical judgement, regulatory awareness, and forward planning for post-quantum migration.

Key Terms

Cryptography: The study and practice of protecting information using mathematical techniques.

Symmetric cryptography: Cryptography using a shared secret key for related encryption and decryption operations.

Asymmetric cryptography: Cryptography using mathematically related public and private keys.

Authenticated encryption: Encryption that also provides integrity and authenticity protection.

Nonce: A value intended to be used once or uniquely within a specified cryptographic context.

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

Collision resistance: The property that finding two inputs with the same digest is computationally infeasible.

MAC: A keyed authentication value used to detect message modification and authenticate a shared-secret origin.

Digital signature: A public-key mechanism for verifying integrity and the claimed origin of data.

Forward secrecy: A property preventing compromise of a long-term key from exposing past session content.

PKI: A framework for managing public keys, certificates, trust relationships, and validation.

Certificate: A signed data structure binding a public key to an identity or name and associated constraints.

Certification authority: An entity that issues and signs certificates according to defined policies.

Trust anchor: A pre-trusted key or certificate from which a validation chain begins.

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

HSM: A hardware security module designed to protect keys and perform cryptographic operations.

Key rotation: Replacement of a cryptographic key according to policy, exposure, or usage conditions.

Crypto-agility: The capability to replace cryptographic algorithms and parameters with limited disruption.

Post-quantum cryptography: Cryptographic methods designed to resist anticipated quantum-computing attacks.

Kerckhoffs principle: The principle that security should depend on secret keys, not secrecy of the algorithm.

Review Questions

Short Answer Questions

1. Why does encryption alone not necessarily provide message integrity?

2. What is the difference between a hash function and a MAC?

3. What role does a trust anchor play in certificate validation?

4. Why is nonce uniqueness important in authenticated-encryption modes?

5. Name four stages in a cryptographic key lifecycle.

Long Answer Questions

1. Compare symmetric and asymmetric cryptography in terms of performance, key distribution, scalability, and typical applications.

2. Explain how a certificate chain is validated and discuss the limitations of CA-based trust.

3. Describe the complete lifecycle of a high-value signing key, including recovery and destruction.

4. Analyse how digital signatures contribute to authentication and why they do not automatically establish legal non-repudiation.

5. Discuss implementation risks that can undermine secure cryptographic algorithms and propose assurance practices.

Analytical / Application Questions

1. An organisation has 500 systems that require secure communication. Evaluate whether pairwise symmetric keys, a central key-distribution service, or a hybrid PKI design is most appropriate. State the assumptions influencing your recommendation.

2. A web service accepts a valid certificate but does not check the requested hostname. Analyse the attack and explain which parts of certificate validation are missing.

3. Design a cryptographic migration plan for an organisation whose public-key systems protect data that must remain confidential for twenty years. Include inventory, prioritisation, crypto-agility, and post-quantum considerations.

Multiple Choice Questions with Answers

Question 1

Which mechanism provides confidentiality and integrity for application data in a single construction?

A. Plain cryptographic hashing

B. Authenticated encryption

C. Digital timestamping alone

D. A certificate revocation list

Correct Answer: B. Authenticated encryption

Question 2

How many unique pairwise symmetric keys are required for 100 parties under the stated pairwise assumption?

A. 100

B. 990

C. 4,950

D. 10,000

Correct Answer: C. 4,950

Question 3

What is the principal purpose of a cryptographic salt in password storage?

A. To make passwords reversible

B. To ensure identical passwords do not have identical stored values

C. To replace rate limiting

D. To provide public-key authentication

Correct Answer: B. To ensure identical passwords do not have identical stored values

Question 4

Which statement about a digital signature is correct?

A. It automatically proves the legal identity of the signer

B. It provides confidentiality without encryption

C. It can provide public verification of integrity and origin when key binding is trustworthy

D. It is generated with the recipient’s private key

Correct Answer: C. It can provide public verification of integrity and origin when key binding is trustworthy

Question 5

What is a trust anchor in PKI?

A. A pre-trusted key or certificate from which validation begins

B. A temporary session nonce

C. A password-hashing work factor

D. A symmetric ciphertext block

Correct Answer: A. A pre-trusted key or certificate from which validation begins

Question 6

Which event most directly requires certificate revocation before normal expiry?

A. A private key is compromised

B. A server receives ordinary traffic

C. A certificate is displayed to a user

D. A hash is calculated successfully

Correct Answer: A. A private key is compromised

Question 7

Why is ephemeral Diffie–Hellman valuable in a properly authenticated protocol?

A. It eliminates the need for authentication

B. It can provide forward secrecy

C. It converts hashes into passwords

D. It prevents all endpoint compromise

Correct Answer: B. It can provide forward secrecy

Question 8

Which practice is generally appropriate for high-value cryptographic keys?

A. Embedding them in public source code

B. Writing them to application logs

C. Using hardware-backed protection and controlled administration

D. Using one key for every cryptographic purpose

Correct Answer: C. Using hardware-backed protection and controlled administration

Question 9

What does collision resistance describe?

A. Difficulty of finding two distinct inputs with the same hash digest

B. Difficulty of decrypting a ciphertext with the public key

C. The speed of certificate renewal

D. The number of parties sharing a MAC key

Correct Answer: A. Difficulty of finding two distinct inputs with the same hash digest

Question 10

What is a major risk of reusing a nonce with the same key in a mode such as GCM?

A. It guarantees stronger confidentiality

B. It can seriously compromise confidentiality and authentication

C. It automatically revokes the certificate

D. It converts asymmetric encryption into hashing

Correct Answer: B. It can seriously compromise confidentiality and authentication