I85PREP
⌘ K
eMAPT study materials
eMAPT study resources

eMAPT cheat sheet

eMAPT · Keep the key ideas within reach.

Quick reference

PKI

  • X.509 v3 certificate fields: version, serialNumber, signatureAlgorithm, issuer, validity (notBefore/notAfter), subject, subjectPublicKeyInfo, extensions, and the CA's signature over the TBS (to-be-signed) portion.

  • Chain validation order: build path leaf → intermediate(s) → trust anchor; verify each signature, validity period, basicConstraints (CA:TRUE, pathLenConstraint), keyUsage (keyCertSign on CAs), and name chaining (issuer DN = issuer's subject DN).

  • Revocation: CRL (periodic, signed list) vs OCSP (per-cert status). OCSP stapling embeds a signed, time-stamped response in the TLS handshake; must-revocation checks fail closed, soft-fail opens the connection on responder error.

  • KeyUsage vs ExtendedKeyUsage: KeyUsage is a bitmask constraining cryptographic operations (digitalSignature, keyEncipherment, keyCertSign, cRLSign); EKU is a sequence of OIDs constraining purpose (serverAuth 1.3.6.1.5.5.7.3.1, clientAuth .2, codeSigning .3).

  • Name constraints (permitted/excluded subtrees) restrict which subject names a CA may issue for; violation invalidates the chain. Policy constraints and certificatePolicies OIDs express issuance policy.

  • Certificate pinning: compare SPKI hash or full-cert hash against a stored set; pin at least one backup key to survive rotation. HPKP is deprecated; prefer app-level or DNS-based (CAA/DANE) controls.

  • Self-signed vs CA-issued: a self-signed cert is its own issuer and verifies only if explicitly trusted; a root CA cert is self-signed and trusted by distribution, not by chaining to another CA.

  • Signature algorithm agility: SHA-1 in certificates is deprecated; RSA-PSS and ECDSA (P-256/P-384) are current. AlgorithmIdentifier OIDs identify hash+signature; mismatch between outer and inner algorithm is an attack signal.

Quick reference

TLS

  • TLS 1.3 handshake: ClientHello (key_share, supported_versions, signature_algorithms) → ServerHello (key_share, cipher suite) → EncryptedExtensions → Certificate → CertificateVerify → Finished; 1-RTT by default, 0-RTT optional with replay risk.

  • TLS 1.3 cipher suites fix the key exchange (ECDHE) and authenticate the handshake; AEAD only (AES-GCM, ChaCha20-Poly1305). TLS 1.2 suites combine key exchange + auth + cipher + MAC (e.g., ECDHE-RSA-AES128-GCM-SHA256).

  • Key schedule: HKDF-Extract/Expand derives early, handshake, and application traffic secrets from ECDHE shared secret and transcript hash; Finished MAC covers the full handshake transcript, binding identities to keys.

  • Downgrade protection: TLS 1.3 uses the downgrade sentinel in ServerHello.random; TLS_FALLBACK_SCSV in TLS 1.2 prevents version rollback. Disable SSLv3/TLS 1.0/1.1 and RC4/3DES/CBC-only suites.

  • CertificateVerify signs the transcript hash with the certificate's private key using a scheme from signature_algorithms; the client verifies the chain and that the key matches the leaf SPKI.

  • SNI carries the target hostname in ClientHello (plaintext in TLS 1.2, encrypted in ECH); servers may select certificates per SNI. ALPN negotiates application protocol (h2, http/1.1).

  • Session resumption: TLS 1.2 session IDs/tickets; TLS 1.3 PSK resumption with ticket + binder. 0-RTT data is replayable and must be limited to idempotent operations.

  • Common failures: hostname mismatch (SAN vs CN), expired/not-yet-valid, incomplete chain (missing intermediate), untrusted root, weak signature, revoked leaf. Verify with openssl s_client -connect host:443 -servername host -showcerts.

Quick reference

Applied cryptography

  • Symmetric: AES-GCM (AEAD, 96-bit nonce, 128-bit tag) preferred; never reuse a nonce with the same key. ChaCha20-Poly1305 for software-only platforms. Avoid ECB and unauthenticated CBC.

  • Asymmetric: RSA (≥2048-bit, OAEP for encryption, PSS for signatures), ECDSA/EdDSA (Ed25519) for signatures, ECDH/X25519 for key agreement. RSA must not be used for key agreement directly.

  • Hashing: SHA-256/SHA-3 for integrity; HMAC for keyed integrity; password storage uses memory-hard KDFs (Argon2id, scrypt, PBKDF2 with high iterations) with per-user salt. MD5/SHA-1 are broken for collision resistance.

  • Key derivation: HKDF = Extract(salt, IKM) then Expand(info, L); never use a raw shared secret directly as a key. KDF output is domain-separated by info/context strings.

  • Randomness: use a CSPRNG (OS entropy: getrandom, /dev/urandom); nonces, salts, IVs, and keys must come from it. Predictable randomness breaks ECDSA (nonce reuse leaks the private key).

  • Constant-time comparison for MACs and tokens; avoid secret-dependent branches and table lookups in cryptographic code. Encrypt-then-MAC for composed schemes.

  • Forward secrecy requires ephemeral key exchange (ECDHE/DHE); static RSA key transport lacks it. Key rotation and separation of encryption vs signing keys reduce blast radius.

  • Encoding vs encryption: Base64/hex are reversible encodings, not protection. JWT: alg none and HS/RS confusion are classic vulnerabilities; verify alg against an allowlist and validate claims.