CISSP Cryptography: Encryption, Digital Signatures, and Key Management

Introduction

CISSP cryptography questions connect encryption, signatures, key management, and cryptanalytic attacks to business requirements. This lesson covers tasks 3.6 and 3.7 of Domain 3, Security Architecture and Engineering (13% of the exam, ISC2 exam outline effective 15 April 2024): select and determine cryptographic solutions, and understand methods of cryptanalytic attacks. Cryptography is the toolkit behind confidentiality, integrity, authentication, and nonrepudiation. The CISSP does not ask you to do mathematics; it asks you to choose the right primitive for a requirement, to manage keys across their lifecycle, and to recognize an attack from its description.

Expect questions such as "which mechanism provides nonrepudiation?", "what is the main weakness of symmetric encryption at scale?", "which attack lets an intruder replay captured authentication material?", and "how should a key be retired?".

Learning objectives

After this lesson you can:

1. Distinguish symmetric, asymmetric, and elliptic curve cryptography, and hash functions, and say what each provides.
2. Choose a mode of operation and explain why authenticated encryption matters.
3. Explain digital signatures, message authentication codes, and certificates.
4. Describe a public key infrastructure (PKI) and certificate lifecycle, including revocation.
5. Manage the key lifecycle: generation, distribution, storage, rotation, escrow, and destruction.
6. Explain the quantum threat and the direction of post-quantum cryptography.
7. Identify cryptanalytic attacks: brute force, ciphertext-only, known-plaintext, chosen-plaintext, chosen-ciphertext, side channel, birthday, replay, and man-in-the-middle.
8. Recognize related attacks on identity and systems: pass-the-hash, Kerberos abuse, and ransomware.

1. Goals and building blocks

Terminology: plaintext is the readable message, ciphertext the encrypted form, the algorithm (cipher) is public by Kerckhoffs's principle, and the key is the secret. Work factor is the effort required to break the system. Confusion (complex relationship between key and ciphertext) and diffusion (a change in one plaintext bit changes many ciphertext bits) are the two classic properties of a strong cipher. Old ciphers such as substitution and transposition, one-time pads (unbreakable only if the pad is truly random, as long as the message, secret, and never reused), and book ciphers are exam background.

2. Symmetric cryptography

One shared secret key both encrypts and decrypts. It is fast and suited to bulk data.

2.1 Algorithms to know

Block ciphers process fixed-size blocks; stream ciphers encrypt bit by bit or byte by byte with a keystream.

2.2 Modes of operation

A block cipher alone only encrypts one block. A mode defines how blocks are chained.

Exam tip: AES-GCM requires nonce uniqueness for each key, suitable usage limits, and authentication-tag verification before plaintext is accepted. CBC needs a suitable authenticated construction; adding encryption alone is insufficient. Encryption without authentication does not reliably detect tampering. Modern designs use authenticated encryption such as AES-GCM or ChaCha20-Poly1305.

2.3 Strengths and weaknesses

• Strength: speed, strong security for the key size.
• Weakness 1, key distribution: how do two parties share the secret securely?
• Weakness 2, scalability: in a simple design assigning one unique shared key to each user pair, n users need n(n-1)/2 keys. Key-distribution services and session protocols use different arrangements. Twenty users need 190 keys.
• Weakness 3: provides no nonrepudiation, because both parties hold the same key.

3. Asymmetric cryptography

Each party has a key pair: a public key (shared) and a private key (kept secret). Encryption, key establishment, and signature schemes use these keys differently; signing is not generic private-key encryption.

• Confidentiality: encrypt with the recipient's public key; only the recipient's private key decrypts.
• Digital signature: sign with the sender's private key; anyone verifies with the sender's public key. This supports integrity and origin authentication, and can support nonrepudiation with appropriate key custody and evidence.

Memory aid: to encrypt, use the recipient's public key; to sign, use your own private key.

3.1 Algorithms

Asymmetric operations are much slower than symmetric ones, so real systems are hybrid: asymmetric cryptography (or key agreement) protects a short-lived symmetric session key, and that key encrypts the bulk data. TLS combines key establishment with symmetric traffic protection; not every asymmetric scheme encrypts a session key.

Forward secrecy uses suitable ephemeral key agreement and deletion of ephemeral secrets to protect prior sessions from later compromise of a long-term authentication key. It does not protect a compromised endpoint, and not every PSK mode provides it.

4. Hashing, MACs, and digital signatures

4.1 Hash functions

A hash function maps any input to a fixed-length digest. Required properties: one-way (preimage resistance), collision resistance (hard to find two inputs with the same digest), and the avalanche effect.

A digest detects changes only when its reference is trustworthy. A plain hash sent beside attacker-modifiable data does not authenticate either item.

Password storage needs deliberately slow, salted functions (bcrypt, scrypt, Argon2, PBKDF2), not a fast hash. A salt is a unique random value per password that defeats precomputed rainbow tables. A pepper is a secret value stored separately from the database.

4.2 Message authentication codes

A MAC uses a shared secret to authenticate data. HMAC is hash-based; other MACs, such as CMAC, use different constructions. Both parties share a key, so a valid MAC proves integrity and that the sender knew the key. It does not provide nonrepudiation because either party could have produced it.

4.3 Digital signatures

A signature algorithm uses the private signing key and a defined message-processing construction, often involving hashing. Verification uses the matching public key and the message; ECDSA and EdDSA do not work by encrypting a digest. A valid signature supports integrity and origin authentication when the public key is reliably bound to the signer. Nonrepudiation also depends on custody, timestamps, validation records, and legal context. FIPS 186-5 specifies classical signature schemes; separate standards cover post-quantum schemes.

Worked example 1: matching the mechanism to the requirement.

Scenario. A pharmaceutical company sends batch release approvals to a regulator. The regulator requires: (1) only the regulator can read the message; (2) the regulator can be sure the approval came from the named quality officer and was not modified; (3) the quality officer cannot later deny sending it.

Reasoning, step by step.

1. Requirement 1 is confidentiality. Bulk encryption is symmetric (AES-GCM), with the session key delivered by encrypting it with the regulator's public key.
2. Requirements 2 and 3 are integrity, authentication, and nonrepudiation. Among the mechanisms compared, a digital signature made with the quality officer's private signing key supports these goals, with reliable identity and evidence controls. An HMAC would give integrity and authentication but not nonrepudiation, because the regulator also knows the key.
3. Combine them: sign the approval, encrypt the signed message with the session key, and protect that key using the regulator's suitable public encryption key.

Solution. Digital signature (quality officer's private key) plus hybrid encryption (AES session key wrapped with the regulator's public key).

Why other choices are weaker. Symmetric encryption alone lacks nonrepudiation. A hash alone lacks authentication. Treating signing as private-key encryption confuses distinct operations and does not provide recipient-only confidentiality.

5. Public key infrastructure (PKI)

A public key is useless unless you can trust that it belongs to its claimed owner. PKI provides that trust.

5.1 Components

• Certificate authority (CA): issues and signs certificates. A root CA is the trust anchor, often kept offline; intermediate (issuing) CAs issue day-to-day certificates, limiting the damage of a compromise.
• Registration authority (RA): verifies identity before the CA issues a certificate.
• Certificate: a signed statement (X.509 format) binding a public key to a subject, with validity dates, issuer, serial number, key usage, and subject alternative names.
• Certificate repository and revocation services.

5.2 Validation and revocation

A client validates the chain of trust from the server certificate to a trusted root, the validity period, the name match, and the revocation status. Revocation methods:

Revocation is not instant worldwide: response caching, client policy, and unavailable responders affect enforcement. After key compromise, replace the key and certificate as well as revoking the old certificate.

Protect CA private keys with an assurance level appropriate to the CA, commonly using HSMs; use short validity periods and automation (such as ACME) to cut human error, and monitor public certificate transparency logs for unexpected certificates issued for your domains. Certificate pinning ties an application to a specific key or CA, reducing risk of rogue certificates but increasing operational burden.

A web of trust (PGP) is an alternative where users sign each other's keys instead of relying on a central CA.

6. Key management

Strong algorithms fail when keys are mismanaged. The lifecycle:

1. Generation with a cryptographically secure random source, sized for the data's protection period, ideally inside an HSM.
2. Distribution using secure channels or key-wrapping with another key. Out-of-band delivery or asymmetric key exchange avoids sending keys in clear.
3. Storage in an HSM, TPM, or key management service; never as unprotected secrets in source code or configuration. Wrapped DEKs may be stored beside ciphertext if the KEK and authorization boundary remain protected. Use key encryption keys (KEK) to protect data encryption keys (DEK), a pattern called envelope encryption.
4. Use limited by purpose (separate keys for encryption and signing) and by volume.
5. Rotation at scheduled intervals and after suspected exposure, to limit the data under one key.
6. Backup and escrow: recover encryption keys where required by retention and availability needs. Escrow is trusted recovery custody, not a universal requirement for signing keys. Split knowledge divides secret knowledge; dual control requires independent participants; threshold recovery is one way to implement a defined m-of-n policy.
7. Revocation and archival: preserve public verification keys, certificates, timestamps, and validation evidence for old signatures; retain decryption keys only while legitimately needed. A signing private key need not be retained merely to verify its past signatures.
8. Destruction at end of life: sanitize relevant key copies and recovery paths using an approved method, verify the outcome, and retain evidence.

Cryptoperiod is the time a key may be used. Crypto-agility is the ability to change algorithms and keys quickly, which requires an inventory of where cryptography is used.

Example. A fintech stores customer records encrypted with AES-256. The key sits in a configuration file on the same server. Compromise of that server hands the attacker both. Better: wrap DEKs under a separately controlled KEK, restrict authorized key use, audit, and rotate under policy. KMS custody reduces extraction risk but cannot by itself stop a compromised application from misusing its still-authorized decryption rights.

7. Applying cryptography

In vault-based tokenization, substitute tokens refer to values in a protected mapping; format-preserving encryption keeps the original format. Homomorphic encryption allows computation on encrypted data (still mostly specialized).

8. The quantum threat and post-quantum cryptography

A large fault-tolerant quantum computer running Shor's algorithm could break RSA, Diffie-Hellman, and ECC by solving factoring and discrete-logarithm problems efficiently. Grover's algorithm has a different impact from Shor's: AES and hashes require analysis of their construction, strength, and use. AES-256 is a common conservative symmetric choice; it does not make RSA, ECC, or DH quantum-resistant.

Attackers can already follow a "harvest now, decrypt later" strategy, capturing encrypted traffic today for decryption once quantum machines exist. Data that must stay confidential for many years is therefore at risk now.

NIST published its first post-quantum standards in August 2024: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for digital signatures, and FIPS 205 (SLH-DSA), a hash-based signature scheme. NIST is also developing further standards (for example, one based on HQC for key establishment and FN-DSA for signatures). Practical steps for a CISSP: build a cryptographic inventory, prioritize long-lived sensitive data, design for crypto-agility, consider hybrid (classical plus post-quantum) key exchange during the transition, and follow applicable migration requirements.

Quantum key distribution (QKD) is different from post-quantum cryptography. It uses specialized physical links and devices to establish key material; it still needs source authentication, and does not itself encrypt application data or create a digital signature. Physical deployment constraints, denial of service, and implementation risks must be considered. PQC uses classical computing implementations designed to resist known quantum attacks.

9. Cryptanalytic attacks

Cryptanalysis studies breaking cryptographic systems. Attacks differ in what the attacker knows.

9.1 Attacks that abuse credentials and systems

• Pass-the-hash: the attacker steals an NTLM password hash from memory and authenticates with the hash itself, never learning the password. Defenses: disable NTLM where possible, use credential isolation features such as Credential Guard on supported systems, Windows LAPS for local administrator passwords, tiered administration, and access-path restrictions. MFA protects supported entry points, but does not automatically add a second-factor check to an NTLM/SMB authentication that accepts a stolen hash.
• Kerberos abuse: Kerberoasting requests service tickets and cracks the service account's password offline (use long random passwords or managed service accounts); golden ticket forges ticket-granting tickets using the KRBTGT account key (perform a coordinated two-reset recovery after containing the compromise, with replication checks and a wait based on ticket-lifetime policy); silver ticket forges service tickets; pass-the-ticket reuses stolen tickets.
• Ransomware: malware encrypts data and demands payment, often after stealing it (double extortion). Defenses: protected offline or immutable backups, tested restoration, patching, segmentation, EDR, least privilege, and an incident plan. Paying does not guarantee recovery.
• Credential replay and stuffing: reuse of captured or leaked credentials; mitigated with MFA and unique passwords.

10. Worked example 2: diagnosing an attack from a description

Scenario. A security analyst finds that a contractor's compromised workstation has been used to log in to a file server using the contractor's NTLM hash. No password cracking took place. Separately, an auditor notices that a legacy payment gateway still negotiates TLS 1.0 when a client requests it.

Reasoning, step by step.

1. Authenticating with a stolen hash instead of the password is pass-the-hash.
2. The remedies include restricting NTLM, enabling credential isolation, limiting local admin reuse, and requiring MFA for remote access.
3. Accepting TLS 1.0 permits obsolete protocol use. An active downgrade additionally requires a way to influence negotiation or fallback; merely accepting an old client does not prove that every modern protected handshake can be forced down.
4. Disable TLS 1.0 and 1.1, allow only TLS 1.2 or 1.3 with strong ciphers.

Solution. Restrict NTLM and administrative paths, isolate credentials, and enforce MFA at supported entry points. Separately, disable obsolete TLS versions and configure strong negotiation.

Why other labels fail. A brute force or dictionary attack implies guessing passwords, which did not occur. A birthday attack concerns hash collisions. Kerberoasting involves cracking service tickets offline, which was not described.

11. Mini case study

Scenario. Meridian Legal wants to (a) email contracts that clients can verify as authentic and unaltered, (b) encrypt a 4 TB archive of case files at rest, (c) let 60 paralegals exchange confidential notes, and (d) retain contract signatures verifiable for 20 years. Currently the IT team encrypts the archive with a single AES key stored in a shared spreadsheet, and the firm's internal CA key lives on a general-purpose server.

Task. Recommend a design and fix the key-management issues.

Commented solution.

1. Contracts (a): S/MIME or PDF signatures with certificates from a trusted CA. A properly validated signature supports integrity, origin authentication, and nonrepudiation evidence. Add trusted timestamping.
2. Archive (b): AES-256 in an authenticated or disk-appropriate mode, with DEKs wrapped by a KEK in an HSM or cloud KMS. Remove the spreadsheet; restrict key use to the archive service; log and rotate.
3. Paralegals (c): with 60 users, pairwise symmetric keys would be 1,770 keys (60 × 59 / 2). Use asymmetric key exchange with a hybrid protocol (S/MIME or an encrypted messaging platform) so users do not manage shared secrets.
4. Long-term verification (d): Do not promise any classical RSA or ECC parameter set will remain adequate for 20 years. Preserve trusted timestamps, certificates, and revocation evidence, and plan validation renewal and migration to standardized post-quantum signatures as ecosystem support and applicable requirements permit.
5. CA protection: move the root CA offline in an HSM, create an issuing CA for daily use, and define revocation (CRL/OCSP).
6. Governance: split-knowledge key custody with dual control and documented destruction.

Why. The weaknesses were not the algorithms but custody: shared key in a spreadsheet and an exposed CA key.

12. Common pitfalls and exam tips

• Pitfall: "Encrypt with my private key to keep it secret." Use an appropriate public-key encryption or key-encapsulation scheme for the recipient; signing is a separate operation.
• Exam tip: nonrepudiation requires asymmetric digital signatures. MACs and symmetric encryption cannot provide it.
• Pitfall: treating a hash as authentication. Anyone can recompute a plain hash; use HMAC or a signature.
• Exam tip: key custody is a critical failure point; when a scenario shows keys stored with data, choose HSM/KMS, separation, and rotation.
• Exam tip: symmetric = fast but key distribution problem; asymmetric = solves distribution but slow, so use hybrid.
• Pitfall: confusing CRL and OCSP. CRL is a list; OCSP is a per-certificate query.
• Exam tip: a sufficiently capable quantum computer threatens RSA, ECC, and DH; symmetric and hash security require a separate strength analysis. Plan migration before long-lived secrets become exposed.
• Pitfall: believing a longer key fixes a flawed implementation or mode (such as ECB).

Key terms

• Kerckhoffs's principle: security depends only on the secrecy of the key.
• AEAD: authenticated encryption that protects confidentiality and integrity together.
• Hybrid cryptosystem: asymmetric key exchange plus symmetric bulk encryption.
• Digital signature: scheme using a private signing key and public verification key; supports integrity, origin authentication, and nonrepudiation evidence.
• HMAC: keyed hash for integrity and authentication without nonrepudiation.
• PKI / CA / RA / CRL / OCSP: infrastructure for issuing, validating, and revoking certificates.
• KEK / DEK: key that wraps other keys / key that encrypts data.
• PFS: suitable ephemeral key agreement and secret deletion protect prior sessions from later long-term-key compromise; endpoint compromise is a separate threat.
• Harvest now, decrypt later: collecting ciphertext today to break it with future quantum computers.
• Pass-the-hash: authenticating with a captured password hash.

Summary checklist

• I can match confidentiality, integrity, authentication, and nonrepudiation to the right mechanism.
• I can compare symmetric, asymmetric, and ECC, and explain hybrid use.
• I know why ECB is weak and why authenticated encryption matters.
• I can explain digital signatures, HMAC, and certificate validation including CRL and OCSP.
• I can describe the full key lifecycle and protections such as HSM, KEK/DEK, and split knowledge.
• I can explain the quantum threat, harvest-now-decrypt-later, and NIST's FIPS 203, 204, and 205.
• I can name cryptanalytic attacks by what the attacker knows or does.
• I can recognize pass-the-hash, Kerberos abuse, MITM, replay, downgrade, and ransomware, and name defenses.

For platform protection of keys, review TPM, HSM, and secure design principles. Coordinate key retirement with data retention and media sanitization, and protect key custody using site and facility security controls.

Official sources

• ISC2 CISSP exam outline: https://www.isc2.org/certifications/cissp/cissp-certification-exam-outline (opens in a new tab)

• NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final (opens in a new tab)

• NIST FIPS 197 (AES) and FIPS 186-5 (Digital Signature Standard): https://csrc.nist.gov/pubs/fips/197/final (opens in a new tab) and https://csrc.nist.gov/pubs/fips/186-5/final (opens in a new tab)

• NIST post-quantum cryptography standards (FIPS 203, 204, 205): https://csrc.nist.gov/projects/post-quantum-cryptography (opens in a new tab)

• NIST SP 800-52 Rev. 2, TLS guidelines: https://csrc.nist.gov/pubs/sp/800/52/r2/final (opens in a new tab)

• NIST SP 800-63B, Digital Identity Guidelines (authentication and lifecycle management): https://pages.nist.gov/800-63-4/sp800-63b.html (opens in a new tab)

• NIST, TDEA withdrawal: https://csrc.nist.gov/pubs/sp/800/67/r2/final (opens in a new tab)

• NSA, QKD limitations: https://www.nsa.gov/Cybersecurity/Quantum-Key-Distribution-QKD-and-Quantum-Cryptography-QC/ (opens in a new tab)

• Microsoft, Credential Guard protection limits: https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/how-it-works (opens in a new tab)

• Microsoft, coordinated KRBTGT recovery: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-reset-the-krbtgt-password (opens in a new tab)

• IETF, OCSP status and freshness: https://www.rfc-editor.org/info/rfc6960/ (opens in a new tab)

• IETF, TLS 1.3: https://www.rfc-editor.org/info/rfc9846/ (opens in a new tab)

• NIST SP 800-38D, GCM and authentication requirements: https://csrc.nist.gov/pubs/sp/800/38/d/final (opens in a new tab)