Cryptography in practice

Key takeaways The cryptography you learned isn’t abstract — it’s running right now behind TLS / SSH / disk / E2EE. These all lean on the same building blocks from symmetric & asymmetric encryption: almost every real system is a hybrid of a public-key exchange to agree on a key, then fast symmetric encryption for the data. And in every one of them, key management is the hard part — the algorithms are strong; keeping the keys safe is where security is won or lost.

You’ve seen how symmetric and asymmetric encryption work. Now the payoff: those same ideas are protecting nearly everything you touch online and off, usually without announcing themselves. Learn to spot the pattern and the whole landscape gets simpler — it’s the same two tools, combined the same way, over and over.

Encryption in transit

In transit means protecting data while it moves across a network, where anyone in the path could otherwise read or alter it.

TLS/HTTPS is what puts the padlock in your browser. Every login, message, and payment on the modern web rides inside it — see TLS & HTTPS. It’s a textbook hybrid: a public-key handshake agrees on a session key, then symmetric encryption carries the page.
SSH protects remote logins and file transfers to servers, so your commands and credentials don’t cross the network in the clear — see SSH & remote access.
VPNs wrap your entire connection in an encrypted tunnel, so a hostile network sees only ciphertext instead of which sites you reach — see VPNs.

Different tools, same job: make the data unreadable to anyone who isn’t the intended endpoint while it’s on the wire.

Encryption at rest

At rest means protecting data while it’s sitting on a disk, phone, or backup drive — the risk being a device that’s lost or stolen rather than intercepted.

Full-disk encryption scrambles everything on a laptop or phone so that, without your passphrase, a thief who pockets the hardware gets a brick full of noise instead of your files. Encrypted files and backups do the same for individual documents or archive copies, so a leaked backup is useless to whoever finds it.

Here the workhorse is usually symmetric encryption — fast, and there’s only one party involved, so there’s no stranger to exchange keys with. The catch moves entirely to the key: the encryption is only as good as the passphrase or key protecting it, and a device with the key left unlocked isn’t protected at all.

End-to-end encryption

End-to-end encryption (E2EE) means only the two endpoints — the people in the conversation — hold the keys. The service carrying the messages can move the ciphertext around but can’t read it, because it never has the key. This is how private messaging apps promise that not even the company can see your chats.

The building blocks are familiar: public-key methods let two devices agree on keys without a shared secret up front, and symmetric encryption protects each message. The important honesty here is the tradeoff: E2EE hides content, but metadata still leaks — who you talked to, when, how often, and how much. Encryption of the message body doesn’t hide the envelope, and that pattern of contacts and timing can reveal a great deal on its own.

Encrypted radio

The same ideas leave the internet and go onto the airwaves. Trunked and digital radio systems can encrypt voice so that only radios holding the right key hear the conversation — everyone else hears noise. The key is symmetric (all the radios in a talkgroup share it), and the hard problem is getting that key to every radio and changing it safely, which is handled by a key-management process — often OTAR, over-the-air rekeying, so keys can be updated without collecting every radio. See encryption & authentication, OTAR & key management, and the radio-side view in encryption.

For a monitoring tool the boundary is sharp: a scanner can detect that a transmission is encrypted and tell you which system it belongs to, but it cannot recover the content without the key. That’s not a limitation to work around — it’s the encryption doing exactly its job, by design.

Key management is where crypto lives or dies

Notice what every section above had in common: the algorithm was never the weak point. Strong algorithms don’t help if the keys are mishandled. A perfect cipher around a key that’s emailed in plaintext, reused for years, or left on a stolen laptop protects nothing.

So the real work of applied cryptography is key management:

Protect keys — store them where attackers can’t reach them, and never send them over the channel they’re meant to secure.
Rotate keys — change them periodically and after any suspected exposure, so one leaked key doesn’t unlock everything forever. (You’ll go deeper in secrets management later in the path.)
Retire weak protocols — keep software up to date so old, broken versions of TLS and other schemes are turned off before someone exploits them.

Get the keys right and ordinary, well-tested algorithms are more than enough. Get the keys wrong and the strongest cipher in the world won’t save you.

Quick check: what do HTTPS, SSH, and encrypted radio fundamentally share?

Recap

The cryptography you learned is everywhere: TLS for the web, SSH for remote access, VPNs, disk encryption, E2EE messaging, and encrypted radio.
Nearly all of it is a hybrid — a public-key exchange to agree on a key, then fast symmetric encryption for the data.
In transit protects data crossing a network; at rest protects data on a device that could be lost or stolen.
End-to-end encryption keeps content readable only to the endpoints, but metadata still leaks.
Encrypted radio uses shared symmetric keys distributed by key management or OTAR; a scanner can see that traffic is encrypted but can’t read it.
Key management — protecting, rotating, and retiring keys — is the part that decides whether any of it actually holds.

Next up: Module 3 turns to identity and access — authentication basics