Cryptography
LPIC-3 Security treats cryptography as an operational skill: you must run OpenSSL and GnuPG confidently, manage X.509 certificates through their whole lifecycle, and judge whether a TLS deployment is actually sound.
Core rules
- Symmetric ciphers (AES-GCM, ChaCha20-Poly1305) encrypt bulk data; asymmetric keys (RSA, ECDSA, Ed25519) sign or transport keys. TLS combines both.
- Hashes (SHA-256/SHA-512) give integrity only; HMAC adds a key. MD5 and SHA-1 are unacceptable for signatures.
- An X.509 certificate binds a public key to names in subjectAltName, an issuer, a validity window, keyUsage/EKU, and a CA signature. Clients ignore CN when SAN exists.
- Chains are served leaf first, then intermediates; the root lives in the client trust store, not in the chain file.
- Revocation uses CRL files or OCSP; stale CRLs make some clients fail open.
- GnuPG is a web of trust: validity comes from your signatures and trust levels, not a central CA. Relevant commands:
gpg --verify file.sig file,gpg --recv-keys,gpg --sign-key,gpg --list-packets.
Worked example
openssl req -new -newkey rsa:3072 -nodes -keyout srv.key -out srv.csr -subj '/CN=web.example.com' -addext 'subjectAltName=DNS:web.example.com,DNS:www.example.com'
Reasoning: 3072-bit RSA meets current guidance; -nodes leaves the key unencrypted so the daemon can start unattended, which is only acceptable with chmod 600 and a protected directory; the SAN extension is what clients actually match. Verify with openssl req -in srv.csr -noout -text, have the CA sign it, then test the result with openssl s_client -connect host:443 -servername web.example.com.
Traps
Hostname only in CN; serving an incomplete chain; pasting a private key into a ticket; trusting a gpg key merely because it downloaded from a keyserver (validity is not trust); certificate lifetimes that outlive policy.