Encryption Fundamentals

Mental model

Cryptography in networking solves three problems:

1. Confidentiality — no one in the middle can read the data.
2. Integrity — no one in the middle can change the data without being detected.
3. Authentication — the other party is who they claim to be.

Each problem maps to a different cryptographic primitive:

Problem	Primitive	Example
Confidentiality	Symmetric encryption	AES
Integrity	Hashing	SHA-256
Integrity + Authentication	HMAC, Digital signature	HMAC-SHA256, RSA-PSS
Authentication at scale	Public key + PKI	TLS certificate

You won’t implement these as a network engineer, but you’ll configure them constantly — IPsec, TLS, SSH, 802.1X, MACsec, SNMPv3 — and you’ll be the person debugging why they fail.

Symmetric encryption

One shared secret key. Same key encrypts and decrypts.

Alice + Key = Ciphertext      (encrypt)
Ciphertext + Key = Alice      (decrypt)

Properties:

• Fast. AES on modern CPUs is gigabits-per-second per core.
• Compact. Output ≈ input size (plus a small IV/nonce).
• Problem: how do both sides get the same key without an eavesdropper learning it?

Algorithms you’ll see:

Algorithm	Key sizes	Status
AES (Advanced Encryption Standard)	128, 192, 256 bit	Default in 2026
3DES	168 bit (effective 112)	Legacy — avoid
DES	56 bit	Broken — never use
ChaCha20	256 bit	Modern alternative (TLS 1.3, mobile)

For CCNA: AES-256 is the answer to “which symmetric algorithm” in 2026.

Asymmetric (public-key) encryption

Two mathematically linked keys. What one encrypts, only the other decrypts. Each user has:

• Public key — given to anyone. Used to encrypt to you, or verify your signatures.
• Private key — kept secret. Used to decrypt to you, or sign on your behalf.

Alice's plaintext + Bob's public key = ciphertext     (Bob is the only one who can decrypt)
ciphertext + Bob's private key = Alice's plaintext

Properties:

• Slow. Roughly 1000× slower than symmetric per byte.
• Big keys / signatures. RSA-2048 = 256-byte signatures vs HMAC-SHA256 = 32 bytes.
• Solves the key-exchange problem. No shared secret needed up front.

Algorithms:

Algorithm	Typical key size	Use
RSA	2048-4096 bit	Most widely deployed
ECDSA (Elliptic Curve DSA)	256-384 bit	Smaller / faster than RSA, same security
Ed25519	256 bit	Modern, very fast, used in SSH/WireGuard
DH / ECDH	2048+ / 256+	Key exchange (not encryption)

The hybrid pattern — used by every protocol

Asymmetric is too slow for bulk data. Symmetric needs a shared key. The compromise:

1. Asymmetric is used to agree on a fresh symmetric key (DH key exchange, or RSA wrap).
2. Symmetric (AES) is used for the actual data transfer.

TLS, IPsec IKE, SSH — all do this. First handshake = asymmetric. Then everything = symmetric. That’s why TLS is fast: only the first few packets pay the asymmetric cost.

Diffie-Hellman — key exchange without trust

Two parties agree on a shared secret over an insecure channel without ever transmitting it.

Conceptually:

1. Public parameters: g, p (big prime).
2. Alice picks secret a. Sends g^a mod p to Bob.
3. Bob picks secret b. Sends g^b mod p to Alice.
4. Alice computes (g^b)^a mod p. Bob computes (g^a)^b mod p. Both arrive at g^(ab) mod p — the shared secret.

An eavesdropper sees g, p, g^a, g^b — but computing a or b from these requires solving the discrete-log problem, which is computationally hard for large enough p.

ECDH does the same thing with elliptic curves — same idea, smaller keys.

DH groups in IPsec — bigger group number = bigger prime = stronger:

• Group 2 (1024-bit) — legacy, weak
• Group 14 (2048-bit) — minimum acceptable in 2026
• Group 19/20/21 — elliptic curve, modern
• Group 24 (2048-bit MODP) — fine

Hashing — integrity

A hash maps any input to a fixed-size output deterministically and one-way:

SHA-256("the quick brown fox") = 9ECB36561341D18EB65484E833EFEA61EDC74B84CF5E6AE1B81C63533E25FC8F
SHA-256("the quick brown fix") = E83F62C8...                 (totally different)

Properties:

• Deterministic — same input always produces same hash.
• One-way — can’t reverse to recover input.
• Collision-resistant — extremely hard to find two inputs with the same hash.
• Avalanche effect — change one bit of input, ~half the output bits change.

Hashes you’ll see:

Hash	Output size	Status
MD5	128 bit	Broken — only use for non-security checksums
SHA-1	160 bit	Deprecated since 2017
SHA-256	256 bit	Default in 2026
SHA-384 / SHA-512	384 / 512 bit	Higher-security variants

HMAC (Hash-based Message Authentication Code) combines a hash with a secret key — HMAC-SHA256(key, message). Used for message integrity + authentication in IPsec, TLS, and pretty much every modern protocol.

Digital signatures

A signature proves you wrote this, by combining a hash with your private key:

Sign:    signature = encrypt(hash(message), private_key)
Verify:  decrypted_hash = decrypt(signature, public_key)
         if decrypted_hash == hash(message) → valid

Anyone with your public key can verify. Only you (with the private key) can sign.

This is how SSH host keys, TLS server certs, and code signing work.

PKI and certificates — trust at scale

If everyone has a public key, how do you know whose public key is whose? You can’t ship them all by hand to every device.

Public Key Infrastructure (PKI) solves this with a trust chain:

1. A Certificate Authority (CA) has its own keypair. Its public key is built into operating systems and browsers (the root trust store).
2. When you generate a keypair, you ask the CA to sign a certificate that says: “This public key belongs to packetmentor.com.”
3. Anyone with the CA’s public key can verify the signature → trust the binding.

A certificate (X.509) contains:

• Subject name (e.g., CN=packetmentor.com)
• Public key
• Issuer (the CA that signed it)
• Validity dates
• Extensions (allowed uses, SAN names, etc.)
• The CA’s signature over all of the above

Chain of trust:

Root CA  →  Intermediate CA  →  packetmentor.com cert
(your OS trusts root → root signed intermediate → intermediate signed leaf)

If any link is missing, invalid, or expired, the browser/device throws a certificate error.

Where it shows up in networking

Protocol	What’s used
SSH	Asymmetric for auth + key exchange → AES for session
TLS / HTTPS	Cert (asymmetric + CA signature) → ECDHE → AES-GCM
IPsec (IKEv2)	DH/ECDH key exchange → AES-256 for ESP payload, HMAC-SHA256 for ESP integrity
WPA2/3 (Enterprise)	EAP-TLS uses certs; 4-way handshake derives session keys
SNMPv3	HMAC-SHA for auth, AES for privacy
OSPFv2 auth	HMAC-SHA
BGP TCP-AO / MD5	HMAC over TCP session
MACsec	AES-128-GCM at Layer 2

For CCNA you don’t need to implement these — but you should recognize each acronym and know what it provides.

Common mistakes

1. Calling encryption “secure” without thinking about authentication. Encrypted but unauthenticated channels are vulnerable to MITM. You always need both (TLS gives you both; vanilla AES alone does not).

2. Mixing MD5 / SHA-1 with security in 2026. Both are deprecated. Use SHA-256 minimum. MD5 is fine as a non-security checksum (image integrity vs published Cisco MD5 is OK — but for crypto, no).

3. Self-signed cert == “encrypted but not trusted”. Encryption works; identity is unverifiable. Browsers warn for a reason.

4. Confusing key length with security level. RSA-2048 ≈ ECDSA-256 ≈ AES-128 in actual security. Asymmetric needs bigger keys than symmetric to achieve the same level.

5. Weak DH groups in IPsec. Group 2 (1024-bit) is breakable by nation-state actors. Use Group 14 (2048) at minimum, or ECDH Group 19+ (modern).

6. Encrypting then signing vs signing then encrypting — there are subtle replay/identity attacks if you do it wrong. Stick with audited protocols (TLS, IPsec) and don’t roll your own.

7. Storing private keys in plain text. Network device private keys (SSH host key, TLS cert) live on flash. If someone gets copy flash: tftp:, they get the keys. Use encrypted storage and access controls.

Lab to try tonight

1. Generate an RSA keypair on your laptop: ssh-keygen -t rsa -b 4096. Look at the public/private key files — note the size difference.
2. On a Cisco router: crypto key generate rsa modulus 2048. Verify with show crypto key mypubkey rsa.
3. SSH to the router. Note the key fingerprint warning the first time. Investigate where SSH stores the host-key fingerprint (~/.ssh/known_hosts).
4. On your laptop: openssl s_client -connect google.com:443 -showcerts. Walk the cert chain (leaf → intermediate → root) and find each issuer.
5. openssl dgst -sha256 some-file — compute a hash. Change one byte of the file, hash again, observe avalanche effect.
6. Bonus: configure IPsec site-to-site between two routers using both pre-shared key and certificate-based authentication. Compare configs.
7. Bonus: try nmap --script ssl-enum-ciphers -p 443 example.com to see what crypto a real server negotiates.

Cheat strip

Concept	Plain English
Confidentiality	No one can read = encryption (AES)
Integrity	No one can tamper undetected = hashing (SHA-256) + HMAC
Authentication	Other side is who they claim = signatures / certs / PSK
Symmetric	One shared key. Fast. Bulk data. AES
Asymmetric	Public + private keypair. Slow. Bootstrap trust. RSA, ECDSA
DH / ECDH	Key exchange — derive shared secret over an open channel
HMAC	Hash + secret key = authenticated integrity
Digital signature	Hash + private key. Verify with public key
Certificate	Public key + identity, signed by a CA
PKI	The whole trust infrastructure: CAs, certs, revocation, validation
AES-256	Default in 2026 for symmetric
SHA-256	Default in 2026 for hashing
MD5 / SHA-1	Legacy. Avoid for security.
TLS / IPsec / SSH	All use the hybrid pattern — asymmetric to bootstrap, symmetric to bulk