Applied Cryptography: Algorithms, TLS, Key Management, and Common Pitfalls
Part of the Cybersecurity Skills Guide — This article is one deep-dive in our complete guide series.
By HADESS Team | February 28, 2026 | Updated: February 28, 2026 | 5 min read
Cryptography protects data at rest, in transit, and in use. You do not need to be a mathematician to apply it correctly, but you do need to understand which algorithms to use, how TLS actually works, and where implementations commonly fail. Most cryptographic vulnerabilities are not algorithm breaks — they are implementation mistakes.
Symmetric vs. Asymmetric Encryption
Symmetric encryption uses the same key for encryption and decryption. AES-256-GCM is the standard choice. GCM provides both confidentiality and integrity (authenticated encryption). AES-CBC without a MAC is vulnerable to padding oracle attacks — always use authenticated encryption modes.
“ AES-256-GCM → preferred for data at rest and bulk encryption ChaCha20-Poly1305 → preferred when AES hardware acceleration is unavailable `
Asymmetric encryption uses key pairs. RSA with OAEP padding for encryption, RSA-PSS or ECDSA for signatures. Minimum RSA key size is 2048 bits; prefer 4096 for long-term keys. For elliptic curves, P-256 (secp256r1) and Ed25519 are standard choices.
Asymmetric encryption is slow — it is used to exchange symmetric keys, not to encrypt bulk data. Hybrid encryption combines both: asymmetric encryption protects a randomly generated symmetric key, and the symmetric key encrypts the actual data.
Hashing
Hashing produces a fixed-size digest from arbitrary input. SHA-256 and SHA-3 are current standards. MD5 and SHA-1 are broken for collision resistance — do not use them for integrity verification or digital signatures.
Password hashing requires purpose-built algorithms. bcrypt, scrypt, and Argon2id are designed to be slow and memory-intensive, making brute-force attacks expensive. Never hash passwords with SHA-256 alone — it is too fast.
`
Argon2id → best choice for new implementations
bcrypt → widely supported, well-understood
scrypt → good when hardware resistance matters
HMAC (Hash-based Message Authentication Code) provides message integrity and authenticity. Use HMAC-SHA256 for API authentication, webhook verification, and data integrity checks.
TLS
TLS 1.3 is the current standard. It reduces the handshake to one round trip, removes insecure cipher suites, and mandates forward secrecy. TLS 1.2 is acceptable with proper cipher suite configuration, but disable older versions entirely.
Configure TLS properly:
- Disable TLS 1.0 and 1.1
- Prefer ECDHE key exchange (forward secrecy)
- Use AES-GCM or ChaCha20-Poly1305 cipher suites
- Enable HSTS with a long max-age
- Use certificate pinning for mobile apps and critical API clients
Test your TLS configuration with tools like testssl.sh, ssllabs.com, or openssl s_client. Check for expired certificates, weak key sizes, and cipher suite ordering issues.
Certificate management failures cause more outages than crypto breaks. Monitor certificate expiration dates, automate renewal with ACME/Let's Encrypt, and maintain an inventory of all certificates in your environment.
Key Management
Key management is where cryptography implementations most often fail. The algorithm might be strong, but the key might be stored in plaintext in a config file.
Key storage: Use a KMS (AWS KMS, Azure Key Vault, GCP Cloud KMS, HashiCorp Vault). Store encryption keys in HSMs for high-security requirements. Never store keys in source code, environment variables (if possible), or alongside the encrypted data.
Key rotation: Define rotation schedules — annual for master keys, more frequently for data encryption keys. Use envelope encryption: a master key encrypts data encryption keys (DEKs), and DEKs encrypt data. Rotating the master key means re-encrypting DEKs, not re-encrypting all data.
Key destruction: When keys are retired, ensure they are securely deleted from all locations — primary storage, backups, caches, and replicas.
Common Pitfalls
- Using ECB mode — it leaks patterns in data
- Reusing nonces/IVs with the same key — breaks GCM and CTR mode security
- Rolling your own crypto — use vetted libraries (libsodium, OpenSSL, BoringSSL)
- Hardcoding keys in source code
- Comparing MACs with ==` instead of constant-time comparison — enables timing attacks
Related Career Paths
Applied cryptography maps to Security Engineer and Cloud Security Engineer career paths. Both roles configure TLS, manage keys, and evaluate cryptographic implementations.
Next Steps
- Assess your cryptography knowledge with the skills assessment
- Browse the skills library for TLS, PKI, and key management topics
- Plan your certifications with the certificate roadmap
Related Guides in This Series
- Blockchain Security: Smart Contract Auditing, DeFi Exploits, and Wallet Safety — HADESS | 2026
- eBPF Security: Kernel-Level Monitoring, Network Filtering, and Runtime Protection
- Smart Contract Security: Solidity Vulnerabilities, Reentrancy, and Auditing
Take the Next Step
Browse 80+ skills on HADESS. Go to the browse 80+ skills on hadess on HADESS.
See your certification roadmap. Check out the see your certification roadmap.
Get started free — Create your HADESS account and access all career tools.
Frequently Asked Questions
How long does it take to learn this skill?
Most practitioners build working proficiency in 4-8 weeks of dedicated study with hands-on practice. Mastery takes longer and comes primarily through on-the-job experience.
Do I need certifications for this skill?
Certifications validate your knowledge to employers but are not strictly required. Hands-on experience and portfolio projects often carry more weight in technical interviews. Check the certification roadmap for relevant options.
What career paths use this skill?
Explore the career path explorer to see which roles require this skill and how it fits into different cybersecurity specializations.
—
HADESS Team consists of cybersecurity practitioners, hiring managers, and career strategists who have collectively spent 50+ years in the field.
