Cryptography Fundamentals: The Building Blocks of Secure Communication

Article 1 of 6: Understanding TLS Security Series

Before diving into TLS protocols, you need to understand the cryptographic primitives that make secure communication possible. Cryptography is the science of securing information through mathematical techniques: transforming readable data into unreadable ciphertext, verifying data integrity, and proving identity.

This article covers each cryptographic concept from three perspectives: Theory (how it works), Practical (real-world implementation with tools and commands), and Reality (security risks, attacks, and what can go wrong).

What TLS Secures

TLS (Transport Layer Security) protects numerous protocols:

Protocol	Port	Purpose
HTTPS	443	Secure web browsing
MQTTS	8883	Secure IoT messaging (MQTT over TLS)
SMTPS	465	Secure email submission
IMAPS	993	Secure email retrieval (IMAP)
POP3S	995	Secure email retrieval (POP3)
LDAPS	636	Secure directory services
FTPS	990	Secure file transfer

What TLS Does NOT Protect

Critical: TLS only protects data in transit. Transport security is NOT application security.

Threat	Why TLS Cannot Help
XSS Attacks	Scripts execute in browser after TLS decryption
SQL Injection	Malicious queries travel encrypted but still execute
Server Vulnerabilities	Encrypted traffic to compromised server is still compromised
Phishing	Phishing sites can have valid TLS certificates
Malware	Malware is delivered over HTTPS connections

TLS/SSL Version History

Version	Status	Introduced	Deprecated
SSL 2.0	BROKEN	1995 (Netscape)	RFC 6176 (2011)
SSL 3.0	BROKEN	1996	RFC 7568 (2015)
TLS 1.0	DEPRECATED	RFC 2246 (1999)	RFC 8996 (2021)
TLS 1.1	DEPRECATED	RFC 4346 (2006)	RFC 8996 (2021)
TLS 1.2	SUPPORTED	RFC 5246 (2008)	Legacy fallback only
TLS 1.3	CURRENT	RFC 8446 (2018)	~90% adoption (2026)

1. Symmetric Encryption

Theory: How It Works

Symmetric encryption uses the same secret key for both encryption and decryption. Think of it like a physical lock where both parties have copies of the same key.

How It Works:

1. Alice and Bob pre-share a secret key (e.g., 256-bit random value)
2. Alice encrypts: Ciphertext = Encrypt(Plaintext, Key)
3. Alice sends ciphertext over insecure channel
4. Bob decrypts: Plaintext = Decrypt(Ciphertext, Key)

Key Properties:

• Fast, ~1000x faster than asymmetric encryption
• Efficient for large data volumes (bulk encryption)
• Key must remain secret. If compromised, all encrypted data is exposed.
• Key distribution problem: how do you securely share the key initially?

Practical: Real-World Implementation

Algorithms Used in TLS:

Algorithm	Key Size	Status
AES-256-GCM	256 bits	RECOMMENDED - TLS 1.2/1.3, disk encryption, VPNs
AES-128-GCM	128 bits	RECOMMENDED - Good balance of speed and security
ChaCha20-Poly1305	256 bits	RECOMMENDED - Fast on mobile/ARM, TLS 1.3
AES-CBC	128/256 bits	LEGACY - Removed in TLS 1.3, padding oracle risk
3DES	168 bits	DEPRECATED - Sweet32 attack, avoid
RC4	Variable	BROKEN - Prohibited in TLS, never use

Block Cipher Modes:

Mode	Description	Status
GCM	Galois/Counter Mode, encryption + authentication (AEAD)	RECOMMENDED
CCM	Counter with CBC-MAC, AEAD for constrained IoT devices	OK for IoT
CBC	Cipher Block Chaining, requires separate MAC, padding vulnerable	AVOID
ECB	Electronic Codebook, identical blocks produce identical ciphertext	NEVER USE

OpenSSL Commands:

# Generate a random 256-bit key
openssl rand -hex 32

# Encrypt a file with AES-256-GCM
openssl enc -aes-256-gcm -in plain.txt -out encrypted.bin -pass pass:secretkey

# Decrypt
openssl enc -aes-256-gcm -d -in encrypted.bin -out decrypted.txt -pass pass:secretkey

Reality: Security Risks & Attacks

Attack/Risk	How It Works	Mitigation
Brute Force	Try all possible keys (DES 56-bit cracked in hours)	Use AES-128 minimum, prefer AES-256
IV/Nonce Reuse	Reusing IV with same key in GCM breaks authentication	Always use unique IV per encryption
Padding Oracle	POODLE, Lucky13. Decrypt by observing error responses	Use AEAD modes (GCM), not CBC
Sweet32	Birthday attack on 64-bit block ciphers (3DES)	Use AES (128-bit blocks), disable 3DES
ECB Pattern Leak	Identical plaintext blocks = identical ciphertext	Never use ECB mode
Key Distribution	How to share key securely over insecure channel?	Use asymmetric crypto for key exchange

2. Asymmetric Encryption (Public Key Cryptography)

Theory: How It Works

Asymmetric encryption uses a mathematically linked key pair: a public key (shareable) and a private key (secret). Data encrypted with one key can only be decrypted with the other.

Two Primary Uses:

• Encryption: Encrypt with recipient’s public key, and only they can decrypt with their private key
• Digital Signatures: Sign with your private key, and anyone can verify with your public key

Key Properties:

• Solves key distribution because the public key can be shared openly
• Slow, ~1000x slower than symmetric encryption
• TLS hybrid approach: asymmetric for key exchange, symmetric for bulk data

Practical: Real-World Implementation

RSA vs ECC Key Size Equivalence:

RSA Key	ECC Key	Security Level
2048 bits	224 bits	112-bit security
3072 bits	256 bits	128-bit security - RECOMMENDED
4096 bits	384 bits	192-bit security

OpenSSL Commands:

# Generate RSA 4096-bit private key
openssl genrsa -out private.pem 4096

# Extract public key from private key
openssl rsa -in private.pem -pubout -out public.pem

# Generate ECDSA key (P-256 curve) - PREFERRED
openssl ecparam -genkey -name prime256v1 -out ec_private.pem

# Sign a file with private key
openssl dgst -sha256 -sign private.pem -out sig.bin document.txt

# Verify signature with public key
openssl dgst -sha256 -verify public.pem -signature sig.bin document.txt

Reality: Security Risks & Attacks

Attack/Risk	How It Works	Mitigation
Weak Key Size	RSA-1024 factorable, RSA-512 trivial to break	Use RSA-2048 minimum, prefer 3072+
Key Compromise	Stolen private key decrypts all past messages	Use ephemeral keys (ECDHE) for forward secrecy
Bleichenbacher	Padding oracle on RSA PKCS#1 v1.5 encryption	Use RSA-OAEP or avoid RSA encryption
ROBOT (2017)	Return Of Bleichenbacher, affected major sites	Disable RSA key exchange in TLS entirely
No Forward Secrecy	Static RSA key exchange, past traffic decryptable	Use ECDHE (ephemeral) key exchange only
Quantum Threat	Shor’s algorithm will break RSA/ECC	Prepare for post-quantum crypto (see section 5)

3. Cryptographic Hashing

Theory: How It Works

A cryptographic hash function takes any input and produces a fixed-size output (digest). It is a one-way function: you cannot reverse the hash to recover the original input.

Required Properties:

• Deterministic: Same input always produces same output
• One-way: Cannot reverse hash to find input
• Collision-resistant: Infeasible to find two inputs with same hash
• Avalanche effect: Small input change = completely different hash

Uses in TLS:

• Message authentication (HMAC)
• Key derivation (HKDF in TLS 1.3)
• Certificate fingerprints
• Digital signature creation

Practical: Real-World Implementation

Algorithm	Output	Status
SHA-256	256 bits	RECOMMENDED - TLS 1.2/1.3, certificates
SHA-384	384 bits	RECOMMENDED - Higher security requirements
SHA-512	512 bits	SECURE - Faster than SHA-256 on 64-bit systems
SHA-1	160 bits	BROKEN - Collision found (SHAttered 2017), avoid
MD5	128 bits	BROKEN - Trivial collisions, never use for security

# Calculate SHA-256 hash of a file
openssl dgst -sha256 document.txt

# Create HMAC with secret key
openssl dgst -sha256 -hmac "secretkey" document.txt

# View certificate fingerprint
openssl x509 -in cert.pem -fingerprint -sha256 -noout

Reality: Security Risks & Attacks

Attack/Risk	How It Works	Mitigation
Collision Attack	Find two inputs with same hash (MD5, SHA-1)	Use SHA-256 or higher
Length Extension	Append data to message without knowing secret	Use HMAC, not Hash(key||message)
Rainbow Tables	Precomputed hash lookup for passwords	Use salted hashes (bcrypt, Argon2)
SHAttered (2017)	First practical SHA-1 collision demonstrated	Migrate all SHA-1 usage to SHA-256
Flame Malware	Used MD5 collision to forge Windows Update	Never use MD5 for certificates/signatures

4. Key Exchange (ECDHE)

Theory: How It Works

Key exchange protocols allow two parties to establish a shared secret over an insecure channel. An eavesdropper observing all messages cannot determine the secret.

Elliptic Curve Diffie-Hellman Ephemeral (ECDHE):

1. Alice generates ephemeral key pair (a, aG) and sends aG
2. Bob generates ephemeral key pair (b, bG) and sends bG
3. Alice computes: shared_secret = a × bG
4. Bob computes: shared_secret = b × aG
5. Both arrive at same value: abG (used to derive session keys)

Why ‘Ephemeral’ Matters (Forward Secrecy):

New key pair for every session. Even if the server’s private key is compromised later, past sessions remain secure.

Static vs Ephemeral:

• Static DH: Same keys reused, NO forward secrecy (compromise exposes past sessions)
• Ephemeral (DHE/ECDHE): New keys each session, forward secrecy (mandatory in TLS 1.3)

Practical: Real-World Implementation

Method	Forward Secrecy	Status
ECDHE (X25519)	YES	PREFERRED - TLS 1.3 default, fastest, safest
ECDHE (P-256)	YES	RECOMMENDED - Widely supported
ECDHE (P-384)	YES	High security applications
DHE (2048-bit)	YES	OK - Slower than ECDHE, use 2048+ bits
RSA Key Exchange	NO	REMOVED in TLS 1.3, avoid entirely

# Generate X25519 private key
openssl genpkey -algorithm X25519 -out x25519_priv.pem

# Extract public key
openssl pkey -in x25519_priv.pem -pubout -out x25519_pub.pem

# Check what key exchange a server supports
openssl s_client -connect example.com:443 -curves X25519

Reality: Security Risks & Attacks

Attack/Risk	How It Works	Mitigation
Logjam (2015)	Downgrade to 512-bit export DH, precompute discrete log	Disable DHE_EXPORT, use 2048-bit DH minimum
Weak DH Params	Many servers use same 1024-bit DH primes	Use ECDHE (no shared params) or unique DH groups
FREAK (2015)	Downgrade to 512-bit RSA export keys	Disable all EXPORT cipher suites
No Forward Secrecy	RSA key exchange, past traffic decryptable if key stolen	Use only ECDHE key exchange
MITM Attack	Attacker intercepts key exchange (no authentication)	DH must be signed by server certificate

5. Post-Quantum Cryptography (PQC)

Theory: How It Works

Quantum computers threaten current public-key cryptography. Shor’s algorithm can break RSA and ECC in polynomial time. Post-quantum cryptography uses algorithms believed resistant to quantum attacks.

NIST PQC Standards (Finalized 2024):

Algorithm	Type	Use Case
ML-KEM (Kyber)	Lattice-based	Key Encapsulation (replaces ECDHE)
ML-DSA (Dilithium)	Lattice-based	Digital Signatures (replaces ECDSA)
SLH-DSA (SPHINCS+)	Hash-based	Stateless signatures (backup)

Practical: Real-World Implementation

Hybrid Key Exchange (X25519 + ML-KEM):

Best practice combines classical and post-quantum algorithms. If either is broken, the connection remains secure.

# Check if server supports hybrid PQ key exchange
openssl s_client -connect example.com:443 -groups X25519MLKEM768

# Chrome/Edge: Check connection security in DevTools
# Look for 'X25519Kyber768' in key exchange

Reality: 2026 Adoption Status

Platform	PQC Status
Chrome/Edge	Hybrid ML-KEM enabled by default since 2024
Firefox	Hybrid ML-KEM available, enabled by default 2025
Cloudflare	~60% of connections use hybrid PQ (2025)
AWS/Azure/GCP	Hybrid PQ supported on major services

Timeline: Quantum threat estimated at 2030–2035. Migrate now.

How TLS Combines These Primitives

Primitive	Role in TLS
ECDHE (X25519)	Key Exchange: establishes shared secret with forward secrecy
RSA / ECDSA	Authentication: server signs handshake to prove identity
SHA-256 / SHA-384	Integrity: key derivation (HKDF), handshake verification
AES-256-GCM	Bulk Encryption: encrypts application data with authentication

Understanding Cipher Suite Notation

TLS 1.2 Format:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

• ECDHE = Key exchange (Elliptic Curve Diffie-Hellman Ephemeral)
• RSA = Authentication/signature algorithm
• AES_256_GCM = Symmetric encryption (256-bit AES in GCM mode)
• SHA384 = Hash function for PRF and HMAC

TLS 1.3 Format (Simplified):

TLS_AES_256_GCM_SHA384

Key exchange is always ECDHE. Authentication is in the certificate. Only cipher and hash are specified.

Key Takeaways

• Use AES-GCM or ChaCha20-Poly1305 for symmetric encryption (AEAD)
• Prefer ECDSA (P-256) over RSA for certificates
• Use SHA-256 or SHA-384 for hashing, never MD5/SHA-1
• X25519 preferred for key exchange (forward secrecy)
• Prepare for post-quantum: X25519 + ML-KEM hybrid
• TLS 1.3 mandates all modern choices by default
• TLS protects data in transit only, not application vulnerabilities

---

Next: Article 2: TLS 1.2 Deep Dive

This is part of our 6-article series on Understanding TLS Security.

TLS misconfigurations are among the most common findings in our penetration tests. We test TLS implementation as part of our Web Application Pentest and IoT Pentest engagements. Get a free external security snapshot to check your TLS configuration, or view our pricing.