2.4 — Cryptography Standards

1. CIS Control 16.11 — Use Standardized Encryption

Full Requirement

CIS 16.11 states: “Use only standardized, currently accepted, and extensively reviewed encryption algorithms.”

This is not guidance. It is a directive. The word “only” is absolute. There is no exception for “but it works” or “we tested it internally” or “our developer wrote a really clever algorithm.”

Why This Matters

The history of cryptography is littered with algorithms that appeared strong until they were broken. The difference between a standardized algorithm and a custom one is not cleverness — it is scrutiny. AES was selected after a multi-year public competition where the world’s best cryptographers attempted to break every candidate. SHA-3 underwent a similar process. These algorithms have survived decades of focused attack by adversaries with nation-state resources.

A custom algorithm written by your team has survived zero days of public scrutiny. The probability that it contains a fatal flaw is approximately 100%.

”Don’t Roll Your Own Crypto”

This is the first commandment of applied cryptography. It applies at every level:

• Do not invent new algorithms: Use AES, RSA, Ed25519, SHA-256, Argon2id. They exist because they work.
• Do not implement existing algorithms yourself: Use well-tested libraries (OpenSSL, libsodium, BoringSSL, the standard crypto libraries in your language). A correct implementation of AES requires constant-time operations to prevent timing side-channel attacks. Your implementation almost certainly does not.
• Do not compose primitives in novel ways: Use standard constructions (AES-GCM, ChaCha20-Poly1305). Combining AES-CBC with a separate HMAC can be done correctly, but it can also be done incorrectly in subtle ways (encrypt-then-MAC vs. MAC-then-encrypt — one is secure, the other is vulnerable to padding oracle attacks).
• Do not invent your own protocols: Use TLS for transport security. Use standard token formats (JWT with well-tested libraries). Use established key exchange protocols. Protocol design is harder than algorithm design.

---

2. Symmetric Encryption

Symmetric encryption uses the same key for encryption and decryption. It is fast and suitable for bulk data encryption.

2.1 AES-256 (Advanced Encryption Standard)

Status: Current standard. Approved by NIST. No known practical attacks against full AES-256.

Key size: 256 bits (32 bytes). AES also supports 128-bit and 192-bit keys. Use 256-bit for maximum security margin.

Mode selection (critical):

Mode	Recommendation	Notes
GCM (Galois/Counter Mode)	Preferred	Authenticated encryption. Provides confidentiality AND integrity. Single operation. Requires unique nonce per encryption with the same key.
CCM	Acceptable	Authenticated encryption. Slightly slower than GCM. Used in some wireless protocols.
CBC (Cipher Block Chaining)	Legacy only	Requires separate integrity check (HMAC). Vulnerable to padding oracle attacks if implemented incorrectly. Do not use for new development.
ECB (Electronic Codebook)	Never use	Each block encrypted independently. Identical plaintext blocks produce identical ciphertext blocks. Leaks patterns. The “ECB penguin” demonstration shows why.
CTR (Counter)	Only with separate MAC	Provides confidentiality but not integrity. Must be combined with a MAC (HMAC). GCM is CTR+GMAC combined — use GCM instead.

Implementation guidance:

• Always use GCM mode for new development
• Never reuse a nonce with the same key in GCM (nonce reuse catastrophically breaks confidentiality and integrity)
• Generate nonces using a CSPRNG (cryptographically secure pseudo-random number generator)
• For high-volume encryption where nonce management is difficult, consider AES-256-GCM-SIV (nonce-misuse resistant)

2.2 ChaCha20-Poly1305

Status: Current standard. Standardized in RFC 8439. Used by TLS 1.3, WireGuard, and many modern protocols.

Why it exists: ChaCha20-Poly1305 is a software-optimized authenticated encryption algorithm. AES-GCM is fast when hardware AES-NI instructions are available (most modern x86 and ARM processors). On devices without AES hardware acceleration, ChaCha20-Poly1305 is significantly faster.

When to use:

• Mobile and IoT devices without AES hardware acceleration
• When AES-NI availability cannot be guaranteed across the deployment target
• As an alternative cipher suite in TLS (TLS_CHACHA20_POLY1305_SHA256)
• When you want to avoid the nonce-reuse catastrophe of AES-GCM (ChaCha20’s failure mode under nonce reuse is less severe, though still unacceptable)

2.3 Algorithms to NEVER Use

Algorithm	Why Not
DES	56-bit key. Brute-forceable in hours with commodity hardware. Broken since the late 1990s.
3DES (Triple DES)	Deprecated by NIST (2023 disallowed). 64-bit block size vulnerable to birthday attacks (Sweet32). Extremely slow.
RC4	Stream cipher with known biases. Prohibited in TLS (RFC 7465). Broken.
Blowfish	64-bit block size. Same birthday attack vulnerability as 3DES. Replaced by its successor Twofish, which was also superseded by AES.
Any “home-grown” algorithm	No public review. No adversarial testing. No confidence in security.

---

3. Asymmetric Encryption

Asymmetric (public-key) encryption uses a key pair: a public key for encryption/verification and a private key for decryption/signing.

3.1 RSA

Status: Current standard. Used extensively for key exchange and digital signatures.

Key size requirements:

• RSA-2048: Minimum acceptable key size. Considered secure through approximately 2030.
• RSA-3072: Provides 128-bit security. Recommended for new deployments.
• RSA-4096: Preferred for long-lived keys and high-security applications. Provides comfortable security margin.
• RSA-1024: Broken. Do not use under any circumstances.

Use cases:

• TLS certificate key pairs (RSA-2048 minimum, RSA-4096 preferred for CA certificates)
• Code signing
• S/MIME email encryption
• Key exchange (RSA-OAEP, not RSA-PKCS1v1.5 which is vulnerable to Bleichenbacher attacks)

Padding schemes:

• OAEP (Optimal Asymmetric Encryption Padding): Use for encryption. Secure.
• PSS (Probabilistic Signature Scheme): Use for signatures. Secure.
• PKCS#1 v1.5: Legacy. Vulnerable to padding oracle attacks (Bleichenbacher). Do not use for new implementations.

3.2 Elliptic Curve Cryptography (ECC)

ECC provides equivalent security to RSA with much smaller key sizes, resulting in faster operations and smaller certificate sizes.

ECC Curve	Equivalent RSA	Security Level
P-256 (secp256r1)	RSA-3072	128-bit
P-384 (secp384r1)	RSA-7680	192-bit
P-521 (secp521r1)	RSA-15360	256-bit

ECDSA: Elliptic Curve Digital Signature Algorithm. Standard digital signature scheme using ECC. Widely used in TLS certificates, code signing, and blockchain.

ECDH: Elliptic Curve Diffie-Hellman. Key agreement protocol. Used in TLS handshake for forward secrecy.

3.3 Ed25519

Status: Modern standard. High security, high performance, simple implementation.

What it is: EdDSA (Edwards-curve Digital Signature Algorithm) using Curve25519. Developed by Daniel J. Bernstein.

Advantages:

• Fast signature generation and verification
• Small key size (32 bytes public, 64 bytes private)
• Small signature size (64 bytes)
• Deterministic signatures (no random number needed during signing — eliminates a class of implementation vulnerabilities)
• Resistant to side-channel attacks by design
• Simple, hard to implement incorrectly

Use cases:

• SSH keys (Ed25519 is now the recommended SSH key type)
• Code signing
• API authentication tokens
• Any digital signature application where RSA is not required by legacy constraints

Recommendation: For new systems without legacy constraints, prefer Ed25519 for digital signatures over both RSA and ECDSA.

---

4. Hashing Algorithms

Hash functions produce a fixed-size digest from arbitrary input. They are one-way functions — you cannot recover the input from the hash.

4.1 Approved Hash Functions

Algorithm	Digest Size	Status	Use Cases
SHA-256	256 bits	Current standard	File integrity, digital signatures, general-purpose hashing
SHA-384	384 bits	Current standard	Higher security applications, certificate signing
SHA-512	512 bits	Current standard	Maximum security, faster than SHA-256 on 64-bit processors
SHA-3 (Keccak)	256/384/512 bits	Current standard	Alternative to SHA-2 family, different internal construction
BLAKE2	Configurable	Widely accepted	High-performance hashing, file integrity
BLAKE3	256 bits	Modern	Extremely fast, suitable for file hashing, content addressing

4.2 Deprecated Hash Functions (NEVER Use for Security)

Algorithm	Why Not	Still Acceptable For
MD5	Collision attacks demonstrated in 2004. Practical collision attacks trivial. Broken.	Non-security checksums only (file transfer verification where tampering is not a threat)
SHA-1	Collision attacks demonstrated in 2017 (SHAttered). Deprecated by NIST, browsers, and all major standards bodies.	Nothing. Fully deprecated.

Critical distinction: MD5 and SHA-1 are broken for collision resistance (an attacker can create two different inputs with the same hash). They remain pre-image resistant (given a hash, finding an input that produces it is still hard). But collision resistance is required for digital signatures, certificates, and integrity verification. Do not use them.

---

5. Password Hashing

Password hashing is a distinct category from general-purpose hashing. Password hashes must be:

1. Slow (to resist brute-force attacks)
2. Salted (to prevent rainbow table attacks)
3. Memory-hard (to resist GPU/ASIC attacks)

5.1 Approved Password Hashing Algorithms

Algorithm	Status	Notes
Argon2id	Preferred	Winner of the 2015 Password Hashing Competition. Memory-hard and CPU-hard. Resistant to GPU/ASIC attacks. Combine Argon2d (data-dependent) and Argon2i (data-independent) for optimal security.
bcrypt	Acceptable	Widely deployed, well-tested. CPU-hard but not memory-hard. Maximum password length of 72 bytes.
scrypt	Acceptable	Memory-hard. Good resistance to hardware attacks. More complex to configure correctly than Argon2id.

Recommended Argon2id parameters (OWASP 2024):

• Memory: 19 MiB (19456 KiB)
• Iterations: 2
• Parallelism: 1
• Salt: 16 bytes from CSPRNG
• Output: 32 bytes

5.2 What NEVER to Use for Password Storage

Approach	Why Not
Plaintext	Attacker who accesses database has all passwords immediately
MD5/SHA-1/SHA-256 without salt	Rainbow table attack recovers passwords in seconds
MD5/SHA-1/SHA-256 with salt	Still too fast. GPU can compute billions of hashes per second. Brute force is feasible.
Single iteration of any fast hash	Not designed for passwords. Speed is a vulnerability, not a feature.
Encryption (reversible)	Key compromise reveals all passwords. Passwords should be hashed (irreversible), not encrypted (reversible).
Custom “password stretching"	"We run SHA-256 1000 times” is not bcrypt. Custom constructions have not been analyzed for security.

---

6. TLS Configuration

6.1 Protocol Versions

Version	Status	Guidance
TLS 1.3	Preferred	Faster handshake, mandatory forward secrecy, removed legacy cipher suites. Use this.
TLS 1.2	Minimum acceptable	Still secure when properly configured. Required for legacy client compatibility.
TLS 1.1	Deprecated	Removed by all major browsers. Do not support.
TLS 1.0	Deprecated	Prohibited by PCI DSS since 2018. Do not support.
SSL 3.0	Broken	POODLE attack (2014). Do not support under any circumstances.
SSL 2.0	Broken	Broken since the 1990s. Do not support under any circumstances.

6.2 Cipher Suite Selection (TLS 1.3)

TLS 1.3 dramatically simplified cipher suite selection. Only five cipher suites are defined:

TLS_AES_256_GCM_SHA384        (preferred)
TLS_CHACHA20_POLY1305_SHA256  (preferred, especially for mobile)
TLS_AES_128_GCM_SHA256        (acceptable)
TLS_AES_128_CCM_SHA256        (IoT use cases)
TLS_AES_128_CCM_8_SHA256      (IoT, reduced tag length)

All TLS 1.3 cipher suites provide forward secrecy (via ephemeral Diffie-Hellman) and authenticated encryption. There is no need to agonize over cipher suite ordering in TLS 1.3.

6.3 Cipher Suite Selection (TLS 1.2)

TLS 1.2 has many more cipher suites, and selection matters:

Prefer:

• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-CHACHA20-POLY1305
• ECDHE-RSA-CHACHA20-POLY1305

Accept:

• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256

Reject:

• Anything with RSA key exchange (no forward secrecy)
• Anything with CBC mode (padding oracle risk)
• Anything with RC4, DES, 3DES, NULL, EXPORT
• Anything with MD5

6.4 HSTS (HTTP Strict Transport Security)

HSTS instructs browsers to always use HTTPS, preventing protocol downgrade attacks.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age=31536000: Cache the HSTS policy for one year
• includeSubDomains: Apply to all subdomains
• preload: Register in browser preload lists (permanent HSTS enforcement)

Warning: Enabling HSTS preload is effectively irreversible. Ensure HTTPS is fully functional before enabling.

6.5 Certificate Pinning Considerations

Certificate pinning binds a server to a specific certificate or public key, preventing MITM attacks even if a CA is compromised.

Current guidance: Certificate pinning is generally not recommended for most applications as of 2024+. The risks (outage from expired pins, difficult rotation, operational complexity) typically outweigh the benefits. Google deprecated HPKP (HTTP Public Key Pinning) in Chrome.

Exceptions: Mobile applications communicating with a single known backend may benefit from certificate pinning, especially in high-security contexts (banking, healthcare).

Alternative: Certificate Transparency monitoring detects misissued certificates without the operational risk of pinning.

---

7. Key Management Lifecycle

Cryptographic keys require lifecycle management. A key that is properly generated but improperly stored is worthless. A key that is never rotated accumulates risk. A key that is never destroyed persists as a liability.

7.1 Key Generation

• Use cryptographically secure random number generators (CSPRNG) for key generation
• Never derive keys from weak sources (timestamps, PIDs, sequential counters, user input without KDF)
• Generate keys in secure environments (HSMs for high-value keys, KMS for cloud deployments)
• Document the key generation procedure for audit

7.2 Key Distribution

• Never transmit keys in plaintext over any channel
• Use key exchange protocols (Diffie-Hellman, ECDH) or out-of-band delivery
• For cloud deployments, use KMS key grants and IAM policies to control key access
• For distributed systems, use envelope encryption (data encrypted with DEK, DEK encrypted with KEK, KEK in KMS)

7.3 Key Storage

• Never store keys in source code (no hardcoded keys, no keys in configuration files in version control)
• Never store keys in environment variables for production systems (acceptable for development only)
• Use dedicated key management systems: AWS KMS, Azure Key Vault, HashiCorp Vault, HSMs
• Encrypt keys at rest if stored outside a KMS
• Limit key access to the minimum set of services and personnel required

7.4 Key Rotation

• Define rotation schedules based on key type and use:
  • TLS certificates: Annually (automate with ACME/Let’s Encrypt — 90-day certificates are common)
  • Data encryption keys: Annually minimum, or upon suspected compromise
  • API keys: Quarterly for high-privilege, annually for standard
  • Signing keys: Annually minimum
• Implement rotation without downtime (dual-key period where both old and new keys are valid during transition)
• Automate rotation wherever possible

7.5 Key Revocation

• Revoke keys immediately upon suspected compromise
• Use CRLs (Certificate Revocation Lists) or OCSP (Online Certificate Status Protocol) for certificate revocation
• Maintain a key revocation process that can execute within hours, not days
• Test key revocation procedures regularly

7.6 Key Destruction

• Destroy keys when no longer needed
• Ensure destruction is complete (overwrite memory, destroy HSM key material)
• Retain keys long enough to decrypt data that may need to be accessed (legal retention requirements)
• Document key destruction for audit

---

8. Certificate Management

8.1 CA Hierarchy

• Root CA: Offline, air-gapped, used only to sign intermediate CAs. Maximum security.
• Intermediate CA: Signs end-entity certificates. Can be revoked without replacing the root.
• End-entity certificates: Server certificates, client certificates, code signing certificates.

8.2 Certificate Transparency

Certificate Transparency (CT) is a system of public logs that record all issued certificates. It enables detection of misissued or malicious certificates.

• All publicly trusted CAs must submit certificates to CT logs
• Monitor CT logs for certificates issued for your domains
• Tools: crt.sh, Censys, Facebook Certificate Transparency Monitoring

8.3 ACME and Let’s Encrypt

ACME (Automatic Certificate Management Environment) enables automated certificate issuance and renewal.

• Let’s Encrypt: Free, automated CA. Issues Domain Validated (DV) certificates.
• Renewal automation: Use certbot, acme.sh, or built-in ACME clients to automate renewal
• 90-day certificates: Let’s Encrypt certificates expire in 90 days by design, forcing automation and reducing exposure window from compromised keys

8.4 Certificate Renewal Automation

Manual certificate renewal is a ticking time bomb. Expired certificates cause outages.

• Automate renewal using ACME clients
• Monitor certificate expiration (alert at 30, 14, and 7 days before expiry)
• Test renewal automation regularly
• Maintain inventory of all certificates, their issuers, and expiration dates

---

9. Cryptographic Agility

9.1 What It Is

Cryptographic agility is the ability to swap cryptographic algorithms and parameters without rewriting application code. When a vulnerability is discovered in an algorithm (or quantum computing breaks RSA), you need to migrate quickly.

9.2 Design for Agility

• Abstract cryptographic operations behind interfaces (encrypt, decrypt, sign, verify, hash)
• Store algorithm identifiers alongside encrypted data (so you know which algorithm to use for decryption)
• Design data formats with version fields that indicate the cryptographic scheme used
• Use libraries that support algorithm negotiation (TLS cipher suites are an example)
• Avoid hardcoding algorithm names deep in business logic

9.3 Post-Quantum Cryptography

Quantum computers, when sufficiently powerful, will break RSA and ECC by solving the underlying mathematical problems (integer factorization, discrete logarithm, elliptic curve discrete logarithm) efficiently using Shor’s algorithm.

NIST Post-Quantum Cryptography Standards (2024):

Algorithm	Replaces	Type	Standard
ML-KEM (CRYSTALS-Kyber)	RSA/ECDH key exchange	Key Encapsulation Mechanism	FIPS 203
ML-DSA (CRYSTALS-Dilithium)	RSA/ECDSA signatures	Digital Signature	FIPS 204
SLH-DSA (SPHINCS+)	RSA/ECDSA signatures (hash-based)	Digital Signature	FIPS 205

Migration timeline:

• Now (2025-2026): Inventory all cryptographic assets. Identify systems using RSA, ECDSA, ECDH. Begin cryptographic agility improvements. Deploy hybrid approaches where available (combining classical and post-quantum algorithms).
• 2026-2028: Begin migrating non-critical systems to post-quantum algorithms as library support matures.
• 2028-2030: Complete migration of critical systems. Retire classical-only configurations.
• 2030+: NIST target for deprecating classical algorithms vulnerable to quantum attack.

“Harvest now, decrypt later”: Adversaries are already collecting encrypted data today with the expectation of decrypting it with quantum computers in the future. Data with long confidentiality requirements (health records, national security, trade secrets) needs post-quantum protection now.

---

10. Common AI Cryptographic Mistakes

AI coding assistants — including Claude, GitHub Copilot, and others — frequently generate code with cryptographic errors. These errors are particularly dangerous because the code compiles, runs, and appears to work. The vulnerability is invisible until exploited.

10.1 Suggesting MD5 for Hashing

What the AI generates:

import hashlib
token = hashlib.md5(user_id.encode()).hexdigest()

The problem: MD5 is broken for collision resistance. If this hash is used for any security purpose (token generation, integrity verification, password hashing), it is vulnerable.

The fix: Use SHA-256 minimum for general hashing, Argon2id for password hashing.

10.2 Using ECB Mode

What the AI generates:

from Crypto.Cipher import AES
cipher = AES.new(key, AES.MODE_ECB)
ciphertext = cipher.encrypt(plaintext)

The problem: ECB mode encrypts each block independently. Identical plaintext blocks produce identical ciphertext blocks, leaking patterns.

The fix: Use AES.MODE_GCM with a unique nonce.

10.3 Hardcoding Keys

What the AI generates:

SECRET_KEY = "my-secret-key-12345678901234567890"
cipher = AES.new(SECRET_KEY.encode(), AES.MODE_GCM)

The problem: The key is in the source code, visible to anyone with repository access, persisted in version history forever.

The fix: Load keys from a KMS, vault, or at minimum from environment variables not committed to source control.

10.4 Suggesting Deprecated TLS Versions

What the AI generates:

context = ssl.SSLContext(ssl.PROTOCOL_TLSv1)

The problem: TLS 1.0 is deprecated and vulnerable to multiple attacks (BEAST, POODLE variant).

The fix: Use ssl.PROTOCOL_TLS_CLIENT with context.minimum_version = ssl.TLSVersion.TLSv1_2.

10.5 Implementing Custom Encryption

What the AI generates:

def encrypt(plaintext, key):
    return ''.join(chr(ord(c) ^ ord(key[i % len(key)])) for i, c in enumerate(plaintext))

The problem: This is a simple XOR cipher. It is trivially breakable with frequency analysis or known-plaintext attacks. The AI sometimes generates “encryption” functions that provide zero security.

The fix: Use cryptography.fernet or nacl.secret.SecretBox — established libraries with authenticated encryption.

10.6 Missing IV/Nonce Generation

What the AI generates:

cipher = AES.new(key, AES.MODE_GCM, nonce=b'\x00' * 12)

The problem: Using a zero nonce, or any fixed nonce, with the same key for multiple encryptions catastrophically breaks GCM security. An attacker can recover the authentication key and forge messages.

The fix: Generate a random nonce for every encryption operation using os.urandom(12) or the library’s nonce generation function. Store the nonce alongside the ciphertext (it is not secret).

10.7 Code Review Implications

Every code review involving cryptographic operations must check for these AI-generated mistakes. Consider adding automated Semgrep rules:

rules:
  - id: md5-usage
    pattern: hashlib.md5(...)
    message: "MD5 is deprecated for security purposes. Use SHA-256 or stronger."
    severity: ERROR

  - id: ecb-mode
    pattern: AES.new(..., AES.MODE_ECB)
    message: "ECB mode leaks patterns. Use GCM mode."
    severity: ERROR

  - id: hardcoded-key
    pattern: |
      $KEY = "..."
      ...
      AES.new($KEY, ...)
    message: "Hardcoded encryption key. Use KMS or vault."
    severity: ERROR

---

11. OWASP Cryptographic Practices Checklist

The OWASP Cryptographic Storage Cheat Sheet and Cryptographic Failures Top 10 entry provide this consolidated checklist:

• All cryptographic functions use algorithms approved by NIST or equivalent standards body
• No deprecated algorithms (MD5, SHA-1, DES, 3DES, RC4) used for security purposes
• All symmetric encryption uses authenticated encryption (GCM, CCM, ChaCha20-Poly1305)
• All asymmetric key sizes meet minimum requirements (RSA-2048+, P-256+, Ed25519)
• Password storage uses Argon2id, bcrypt, or scrypt with appropriate parameters
• TLS 1.2 or higher enforced for all communications
• No hardcoded cryptographic keys in source code
• Key management follows lifecycle practices (generation, rotation, revocation, destruction)
• Random number generation uses CSPRNG exclusively
• Cryptographic operations fail closed (decryption failure = access denied)
• Nonces/IVs are unique and generated from CSPRNG
• Key derivation uses approved KDFs (HKDF, PBKDF2 with high iteration count)

---

12. NIST Reference Standards

NIST SP 800-57: Key Management

SP 800-57 Parts 1-3 provide comprehensive key management guidance:

• Part 1: General guidance — key types, key states, key lifecycle, algorithm selection
• Part 2: Best practices for organizational key management
• Part 3: Application-specific key management guidance

NIST SP 800-175B: Cryptographic Guidelines

SP 800-175B provides guidance on using cryptographic standards and algorithms:

• Algorithm selection based on security strength
• Approved modes of operation
• Random number generation requirements
• Key agreement and key transport

FIPS 140-3: Cryptographic Module Requirements

FIPS 140-3 defines security requirements for cryptographic modules. Relevant for:

• Federal systems (mandatory)
• Regulated industries (often required by contractual or compliance obligations)
• Any system where cryptographic assurance must be formally validated

Four security levels: Level 1 (lowest, software-only) through Level 4 (highest, physical tamper-proof).

---

13. Practical Decision Guide

When to Encrypt at Rest

• Always: PII, PHI (health data), financial data, credentials, authentication tokens, cryptographic keys
• Recommended: All database content, all file storage, all backups
• Consider: Logs (if they contain sensitive data), configuration (if it contains secrets)
• Full-disk encryption: Protects against physical theft but not logical access. Necessary but not sufficient for sensitive data.

When to Encrypt in Transit

• Always: All external communications (internet-facing), all API calls, all database connections, all message queue communications
• Recommended: All internal communications (zero trust — assume internal network is compromised)
• Required by regulation: PCI DSS, HIPAA, GDPR all require encryption in transit for sensitive data

Tokenization vs Encryption

Characteristic	Tokenization	Encryption
Reversibility	Only with token vault access	With decryption key
Format preservation	Yes (tokens match original format)	No (ciphertext is different format)
PCI DSS scope reduction	Yes (tokenized data is out of scope)	No (encrypted cardholder data is still in scope)
Performance	Vault lookup per detokenization	Decryption computation per operation
Use case	Payment card numbers, SSNs	General data protection
Key management	Token vault security	Key lifecycle management

Recommendation: Use tokenization for structured sensitive data (card numbers, SSNs, account numbers) where format preservation and scope reduction matter. Use encryption for bulk data protection and data in transit.

---

Summary

Cryptography is the mathematical foundation of information security. CIS 16.11 mandates standardized, reviewed algorithms because the alternative — custom or deprecated cryptography — consistently fails under adversarial pressure.

Key takeaways:

1. Never roll your own crypto — not algorithms, not implementations, not protocols.
2. AES-256-GCM for symmetric encryption. Ed25519 for digital signatures. Argon2id for password hashing. SHA-256+ for general hashing.
3. TLS 1.2 minimum, TLS 1.3 preferred — with properly configured cipher suites.
4. Key management is as important as algorithm selection — generation, storage, rotation, revocation, destruction.
5. AI coding assistants routinely generate broken cryptography — MD5, ECB mode, hardcoded keys, custom ciphers. Every cryptographic code review must check for these.
6. Post-quantum migration is not future planning — it is current planning. “Harvest now, decrypt later” makes this urgent for long-lived secrets.
7. Cryptographic agility means designing systems to swap algorithms without rewriting code. Build this in from the start.

---

References

• CIS Controls v8, Control 16.11
• NIST SP 800-57: Recommendation for Key Management (Parts 1-3)
• NIST SP 800-175B: Guideline for Using Cryptographic Standards
• NIST FIPS 197: Advanced Encryption Standard (AES)
• NIST FIPS 203: ML-KEM (Module Lattice-Based Key-Encapsulation Mechanism)
• NIST FIPS 204: ML-DSA (Module Lattice-Based Digital Signature Algorithm)
• NIST FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)
• OWASP Cryptographic Storage Cheat Sheet
• OWASP TLS Cheat Sheet
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 8439: ChaCha20 and Poly1305 for IETF Protocols
• Bernstein, D.J. “Curve25519: New Diffie-Hellman Speed Records”

Study Guide

Key Takeaways

1. Never roll your own crypto — Not algorithms, not implementations, not protocols. Use vetted libraries exclusively (CIS 16.11 mandate).
2. AES-256-GCM is the standard for symmetric encryption — Provides authenticated encryption (confidentiality + integrity); nonce reuse catastrophically breaks security.
3. Ed25519 is preferred for digital signatures — Fast, small keys/signatures, deterministic, side-channel resistant; prefer over RSA and ECDSA for new systems.
4. Argon2id is the preferred password hashing algorithm — Memory-hard and CPU-hard; bcrypt and scrypt are acceptable alternatives. Never use MD5/SHA-256 for passwords.
5. TLS 1.2 minimum, TLS 1.3 preferred — TLS 1.0/1.1 are deprecated; SSL is completely broken.
6. AI coding assistants routinely generate broken cryptography — MD5, ECB mode, hardcoded keys, custom ciphers, deprecated TLS versions are common AI mistakes.
7. Post-quantum migration is current planning, not future — “Harvest now, decrypt later” makes ML-KEM (FIPS 203) and ML-DSA (FIPS 204) urgent for long-lived secrets.

Important Definitions

Term	Definition
AES-GCM	Galois/Counter Mode — authenticated encryption providing both confidentiality and integrity in one operation
Ed25519	EdDSA using Curve25519 — modern digital signature algorithm with deterministic signatures
Argon2id	Password hashing algorithm combining memory-hard and CPU-hard properties; winner of 2015 PHC
CSPRNG	Cryptographically Secure Pseudo-Random Number Generator — required for all security-relevant randomness
Cryptographic Agility	Ability to swap algorithms and parameters without rewriting application code
Harvest Now, Decrypt Later	Adversaries collecting encrypted data today to decrypt with future quantum computers
ML-KEM (FIPS 203)	Post-quantum Key Encapsulation Mechanism (CRYSTALS-Kyber) replacing RSA/ECDH
HSTS	HTTP Strict Transport Security — instructs browsers to always use HTTPS

Quick Reference

• Framework/Process: CIS 16.11 mandates standardized algorithms; NIST SP 800-57 for key management; FIPS 203/204/205 for post-quantum; OWASP Cryptographic Storage Cheat Sheet
• Key Numbers: RSA-2048 minimum key size; 256-bit AES preferred; TLS 1.3 has only 5 cipher suites; Argon2id params: 19 MiB memory, 2 iterations; 2030+ NIST target for deprecating quantum-vulnerable algorithms
• Common Pitfalls: ECB mode (leaks patterns); nonce reuse in GCM (catastrophic); hardcoded keys in source code; using random module instead of secrets for security; PKCS#1 v1.5 padding (Bleichenbacher attacks)

Review Questions

1. Why is AES-ECB mode dangerous despite using a strong algorithm, and what mode should replace it?
2. What makes nonce reuse in AES-GCM catastrophic rather than merely a weakness?
3. How would you design a system for cryptographic agility so algorithm changes do not require code rewrites?
4. Why should organizations begin post-quantum migration planning today rather than waiting for quantum computers?
5. What Semgrep rules would you create to catch the most common AI-generated cryptographic mistakes?