Cryptography

5.1 Understand reasons and requirements for cryptography

Core idea: crypto requirement.

Scenario: A team encrypts stored files but cannot prove whether exported reports were altered.

Practitioner response: Add integrity and authenticity controls such as signatures or HMAC in addition to confidentiality controls.

Concepts to Understand

• confidentiality: confidentiality is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• integrity and authenticity: integrity and authenticity is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• PII, IP, and PHI sensitivity: PII, IP, and PHI sensitivity is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• PCI DSS and ISO drivers: PCI DSS and ISO drivers is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• entropy and quantum considerations: entropy and quantum considerations is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

5.2 Apply cryptography concepts

Core idea: crypto concept selection.

Scenario: Passwords are stored with unsalted fast hashes and attackers obtained the database.

Practitioner response: Use a password hashing design with unique salts and a slow approved password-hashing function.

Concepts to Understand

• hashing: Hashing proves a value matches without reversing it. Password storage needs salts and slow password-hashing functions, not ordinary fast hashes alone.
• salting: salting is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• symmetric encryption: symmetric encryption is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• asymmetric encryption: asymmetric encryption is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• ECC: ECC is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• digital signatures: digital signatures is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• certificates: certificates is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• HMAC: HMAC is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• audit trails: audit trails is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• algorithm and key strength: algorithm and key strength is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• cryptographic attacks: cryptographic attacks is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

5.3 Understand and implement secure protocols

Core idea: secure protocol use.

Scenario: A legacy file transfer process sends PII over an unauthenticated plaintext protocol.

Practitioner response: Move to an authenticated encrypted protocol, validate endpoints, and disable the plaintext path.

Concepts to Understand

• services and protocols: services and protocols is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• credit card processing: credit card processing is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• file transfer: file transfer is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• web clients: web clients is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• VPN: VPN is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• PII transmission: PII transmission is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• limitations and vulnerabilities: limitations and vulnerabilities is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

5.4 Understand public key infrastructure

Core idea: PKI operations.

Scenario: A private key was copied to several administrators for emergency certificate renewal.

Practitioner response: Replace copyable key handling with controlled key custody, renewal procedures, revocation readiness, and audit logs.

Concepts to Understand

• key storage: key storage is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• rotation: rotation is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• generation: generation is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• destruction: destruction is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• exchange: exchange is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• revocation: revocation is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• escrow: escrow is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• web of trust: web of trust is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• PGP, GPG, and blockchain: PGP, GPG, and blockchain is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

Hashing vs Encryption

Exam clue: Hashing is not encryption. Do not choose hashing when the original value must be recovered.

Symmetric vs Asymmetric Encryption

Exam clue: Use the property needed: confidentiality, integrity, authenticity, or non-repudiation.

digital signature vs HMAC

This comparison is covered through the domain objectives above and the SSCP review sheet.

certificate revocation vs expiration

This comparison is covered through the domain objectives above and the SSCP review sheet.