Cryptography for Network Engineers: The Working Set

By Taylor Thomas · 2026-08-31

Cryptography intimidates by volume: hundreds of algorithm names, modes, and acronyms. The working set for a network engineer is smaller — five recurring jobs, each done by a small family of primitives, drawn on in different combinations by most secure protocols you will configure. Learn the jobs and TLS and IPsec stop being incantations and become arrangements of familiar parts.

Integrity: Hashing and Its Sharp Edge

A cryptographic hash — SHA-256 is today’s workhorse — reduces any input to a fixed-size digest, such that finding two inputs with the same digest is computationally infeasible. That gives you integrity against accident: a changed input produces a different digest with overwhelming probability, so comparison against a digest obtained through a trustworthy path detects corruption. The sharp edge is what a bare hash does not give you: protection against an adversary, who can alter the message and recompute the hash. Authenticity requires a key in the construction. HMAC mixes a shared secret into the hashing so that a party without the key cannot feasibly forge a valid tag — one common construction among several (AEAD authentication tags and other MACs do the same job) that protocols use for keyed integrity. The line between “checksummed” and “authenticated” is among the most practically important in the field.

Confidentiality in Bulk: Symmetric Encryption

Symmetric ciphers — AES above all — encrypt and decrypt with the same key, at speeds fit for line-rate traffic, with hardware acceleration in most modern CPUs. Modern practice favors authenticated-encryption modes such as AES-GCM, which fuse confidentiality and integrity into one operation so tampered ciphertext is detected. Symmetric encryption has one structural weakness, and it is not the math: both ends need the same key before the first protected byte flows. In network sessions, that bootstrap is the problem much of the asymmetric machinery below is there to solve.

Key Establishment and Authentication: The Asymmetric Jobs

Asymmetric cryptography splits the key in two and buys two distinct capabilities. The first is key establishment: Diffie-Hellman, in its elliptic-curve form ECDH, lets two parties who share nothing derive a common secret over a channel an eavesdropper watches. Done with fresh ephemeral keys, it also buys forward secrecy — later compromise of the long-term authentication key alone does not yield past session keys, so traffic recorded today stays out of reach of next year’s key theft. The limit is worth naming: this protects against later key compromise, not against a future quantum computer attacking the recorded key exchange itself — that is the harvest-now-decrypt-later problem, answered by post-quantum key establishment rather than by ephemerality.

The second is authentication: a digital signature made with a private key, verifiable by anyone holding the public key. Signatures raise the question of why you should trust a public key in the first place; in certificate-based systems the usual answer is PKI — certificates binding identities to keys, validated by the verifier through a chain to a trust anchor it already accepts (pinning and explicit configuration serve closed systems). Key exchange without authentication is a private conversation with someone unverified; authentication is what pins the far end down.

Certificates are not the only way to authenticate a peer. Preshared keys — the same secret configured on both ends — remain common for site-to-site IPsec between devices under one administration, where distributing a secret to two routers is easy. The trade is the usual one for shared secrets: a group key proves only that the peer is some holder of it (a unique per-peer key does better, at more configuration cost), and rotating one means touching every device that holds it. Certificate-based authentication scales where preshared keys strain, which is why it anchors remote access and most large, many-peer deployments.

How TLS and IPsec Assemble the Parts

The dominant pattern across modern secure transport composes these primitives the same way: asymmetric key exchange establishes fresh session keys, authentication rides on certificates and signatures — or on preshared keys — and the session then runs on symmetric authenticated encryption. (Variants exist — preshared-key modes, session resumption — but this is the shape to learn first.) In a typical certificate-authenticated TLS 1.3 handshake, the server — and optionally the client — proves its identity with a certificate and signature while ephemeral key exchange establishes fresh keys, then the record layer runs on AES-GCM or its peers. In IPsec, IKE plays the handshake role — authenticating peers and negotiating security associations — and ESP carries the protected traffic; the IPsec vs SSL VPN comparison is largely about where in the stack this same pattern sits. Once you see the hybrid pattern, new protocols read as variations, not new theory.

The Quantum Footnote That Is Now a Chapter

The asymmetric jobs are the quantum-exposed ones: a sufficiently capable quantum computer running Shor’s algorithm breaks the factoring and discrete-log problems under RSA and ECC, while symmetric ciphers and hashes survive with adequate sizes. NIST’s primary replacements are standardized — ML-KEM (FIPS 203) for key establishment, ML-DSA (FIPS 204) foremost among its signature standards — and migration is underway — hybrid key exchange in protocols, signing infrastructure, crypto inventories — as post-quantum cryptography covers in depth. On the SCOR 350-701 v2.0 blueprint this whole working set is objective 1.5, from hashing through post-quantum, at describe level; the SCOR course then spends the VPN units proving the theory on live tunnels.

Frequently Asked Questions

Why do protocols bother with symmetric encryption if asymmetric can encrypt too?

Cost and key handling. Asymmetric operations are generally far more expensive than symmetric ciphers like AES and are unsuited to encrypting gigabits of traffic. But symmetric encryption has a bootstrap problem — both sides need the same key first. The hybrid pattern solves both: asymmetric key exchange establishes a shared secret, the peers authenticate with certificates or preshared keys, and the session then runs on fast symmetric encryption with keys derived from that secret. Certificate-authenticated TLS and most IKE/IPsec deployments work this way; preshared-key variants exist, but the hybrid shape is the one to internalize.

What is the difference between a hash, an HMAC, and a digital signature?

A hash is a fingerprint anyone can compute — it detects accidental corruption but not tampering, because an attacker who changes the data can recompute the hash. An HMAC mixes a shared secret key into the hash, so a party without the key cannot feasibly forge a valid tag; it proves integrity and authenticity between parties who share the key — though any holder of that key could have produced it. A digital signature uses a private key to sign, letting anyone with the public key verify — it adds authenticity that third parties can check, and it can support non-repudiation when key control and identity validation hold up.

How deep does the SCOR 350-701 exam go on cryptography?

Describe-level breadth. Objective 1.5 of the v2.0 blueprint covers cryptography security components — hashing, encryption, PKI, SSL/TLS, QUIC, MASQUE, IPsec, NAT-T IPv4 for IPsec, preshared keys, certificate-based authorization, and post-quantum cryptography. The expectation is that you can explain what each component does and where it is used; the deep configuration work lands in the VPN and secure-communications portions of the exam and course.