Cryptographic Security Fundamentals
Why procedure, not math, decides most real-world crypto failures
Where this fits: This lesson covers CRYPTOSEC at the level every operator should know. A full course dedicated to cryptographic security in depth — COM-09, Cryptographic Security (CRYPTOSEC) — covers this domain the way COM-06 covers Authentication and COM-07 covers One-Time Pads: as a dedicated deep dive on a domain this course only introduces.
Lesson Objectives
- State the core principles of cryptographic security (CRYPTOSEC)
- Explain the Enigma case as a lesson in procedural failure, not mathematical failure
- Describe modern voice encryption standards at a conceptual level
- Identify where One-Time Pads, book ciphers, and steganography fit — and where to go for depth
- Evaluate common commercial messaging apps and cellular PTT radios honestly against the four COMSEC domains
Cryptanalysis exploits people as often as math
Cryptanalysis — the practice of breaking codes — exploits mathematical weaknesses in an algorithm, but far more often it exploits human and procedural failures around that algorithm. Three principles cover most of what goes wrong in the field:
- The longer a key is used, the more vulnerable it becomes. Every use gives an analyst another data point. Keys are meant to be rotated, not adopted permanently.
- Poor implementation defeats strong algorithms. A mathematically unbreakable cipher used incorrectly is not unbreakable in practice. The algorithm is only as strong as the discipline applied around it.
- Reuse is catastrophic in manual systems. Manual ciphers such as one-time pads depend entirely on never reusing key material. Reuse does not weaken the system a little — it can break it completely.
A historical case study in procedural collapse
German Enigma machines changed their keys daily and were, mathematically, an extremely difficult system to break through pure cryptanalysis alone in the time available. What actually enabled sustained Allied exploitation was not a mathematical shortcut against the algorithm — it was a series of human and procedural failures in how the machine was actually used. Two specific failures are worth knowing in detail, because they are exactly the kind of thing this course exists to prevent.
Predictable message keys: the “Cillies”
Each Enigma message opened with a three-letter message key that was supposed to be chosen at random by the operator. In practice, many operators took shortcuts under time pressure — typing keyboard patterns, or personal initials, instead of genuinely random letters. Codebreakers at Bletchley Park came to call these predictable keys “cillies,” reportedly after one operator was found repeatedly using his girlfriend’s initials instead of a random letter group. Once analysts noticed an operator’s habit, that operator’s daily key setting was no longer a secret at all — it was a guess with a very high chance of being correct, and it gave codebreakers a foothold into that day’s traffic.
Predictable content: cribs from weather reports and sign-offs
The second failure was on the content side, not the key side. German message traffic was formulaic enough that Bletchley Park could often guess a fragment of the plaintext in advance — a technique called a “crib.” Routine weather reports used standardized wording and were transmitted at predictable times, so the word for “weather” could often be expected near the start of a message. Many messages also closed with the same sign-off, “Heil Hitler.” Neither of these facts broke the Enigma algorithm itself — but knowing that a specific word almost certainly appeared somewhere in a specific message let codebreakers work backward from a known plaintext-ciphertext pairing, dramatically narrowing the machine settings the Bombe had to search.
This history is dramatized in the 2014 film The Imitation Game. The film takes real dramatic license with several plot details, but the underlying cryptographic facts — predictable operator habits creating “cillies,” and predictable message content creating cribs — are genuine, documented weaknesses that Bletchley Park exploited.
Further reading: For the fuller institutional history behind Bletchley Park — how the Government Code & Cypher School fit into the founding of MI5 and MI6, the Special Operations Executive, and the wartime spy network that later seeded the American intelligence community — see MI5, MI6, Bletchley Park & Camp X, Part 1 of the Architecture of Intelligence series.
Physical capture of code material and captured machines mattered too, but neither of the failures above required capturing anything. Both were purely procedural: an operator taking a shortcut under pressure, and a communications culture predictable enough to write down in advance. Once those procedural habits were understood, the cryptographic advantage collapsed, regardless of how sound the underlying machine was.
Lesson: Crypto is only as strong as its procedures. A message key is only random if it is actually random — not convenient, not memorable, not personal. This is the single most important idea in this lesson, and it applies as directly to a preparedness group’s radio net as it did to a wartime cipher machine. If your group ever adopts a keyed cryptosystem, the operator who picks “easy to remember” keys is doing exactly what the Enigma operator did with his girlfriend’s initials.
What “secure” typically means today
Modern secure voice systems generally rely on the Advanced Encryption Standard (AES). AES is described in Federal Information Processing Standard (FIPS) 197, and FIPS 140-2 governs how AES is actually applied to cryptographic modules in radio systems — the algorithm and its implementation are governed by two separate standards. AES became effective as a federal government standard on May 26, 2002, after NIST found it compliant with FIPS security requirements and the Secretary of Commerce approved it.
AES replaced the older Data Encryption Standard (DES), and the timeline matters: DES, developed in 1977, was first cracked by the Electronic Frontier Foundation in 1997 in 84 days, then cracked again faster in 1998 and twice more in 1999. NIST withdrew its endorsement of DES for secure federal communications after May 2005, and AES became required for all federal agency communications systems beyond May 2007. FIPS 140-2 requires all federal agencies to use AES encryption, and under the Cybersecurity Enhancement Act of 2014, any state or local agency that wants to interoperate on a federal Land Mobile Radio (LMR) system must also have AES on their subscriber units.
Many agencies and organizations have transitioned from DES-based to P25 AES-based systems, which has left a surplus of older encrypted radios and key-loading devices on secondary markets, including legacy platforms and certain key loader device series. These older systems typically require dedicated encryption modules, licensing, and programming software, and remain line-of-sight limited without repeater infrastructure — and improper key handling or a programming error can silently break interoperability without any obvious warning.
Key rotation in practice
The baseline agency policy across most government users is to rotate encryption keys every 30 days, with some agencies rotating more frequently depending on their own risk posture — this is the same “assume lost equals compromised” and rotation-schedule discipline from Lesson 2, applied to a specific cadence. Historically, the practical obstacle to frequent rotation was physical: every radio in a fleet had to be connected to a key loader by hand. Modern radio systems remove that obstacle with Over-The-Air Rekeying (OTAR), which pushes new keys to every subscriber radio remotely through the network itself, and Over-The-Air Programming (OTAP), which does the same for full radio reprogramming. Between them, an agency can now rotate keys on schedule — or immediately after a loss — without physically touching every radio in the field.
Further reading — CISA/SAFECOM encryption guidance: the Cybersecurity and Infrastructure Security Agency (CISA), through the Federal Partnership for Interoperable Communications (FPIC) and SAFECOM/NCSWIC, publishes the standing reference set on LMR encryption for public safety. Organized by function:
- Foundational/overview: The Who, What, When, Where, How, and Why of Encryption in P25 Public Safety Land Mobile Radio Systems (May 2023) — the current comprehensive guide, consolidating three earlier 2016 documents into one; Considerations for Encryption in Public Safety Radio Systems and its companion fact sheet, Determining the Need for Encryption in Public Safety Radios; Guidelines for Encryption in Land Mobile Radio Systems: Determining What Encryption Method to Use for Public Safety Radios.
- Key management specifics: Operational Best Practices for Encryption Key Management (Aug 2020), the detailed how-to on obtaining, distributing, and managing crypto keys, referencing FIPS PUB-197 and the TIA-102.AAAD-B Block Encryption Protocol; the Encryption Key Management Fact Sheet (2020), the shorter version covering the National Law Enforcement Communications Center’s role and the AES-256 recommendation.
- Algorithm transition: The Transition to Advanced Encryption Standard White Paper, covering DES vulnerabilities, the AES transition, and CJIS Policy and PCII Program context.
- Link-layer security: Link Layer Authentication (LLA) and Link Layer Encryption (LLE): Are You Really Secure? (2022), distinguishing LLA from LLE, plus companion short explainer videos.
- Cybersecurity/risk context: Cyber Risks to Land Mobile Radio — First Edition (2022); Communications Security — Protecting Critical Information, Personnel, and Operations.
Nick Meacher, the author of this course, was directly involved in drafting two of the documents referenced above: Considerations for Encryption in Public Safety Radio Systems and Guidelines for Encryption in Land Mobile Radio Systems: Determining What Encryption Method to Use for Public Safety Radios.
A preview, not the full course
Three additional methods deserve a brief mention here, each with its own dedicated depth elsewhere in the curriculum or worth knowing conceptually:
| Method | Core idea | Where it fits |
|---|---|---|
| One-Time Pad (OTP) | When used correctly — truly random keys, key length at least equal to message length, never reused, destroyed immediately after use — OTP encryption is provably unbreakable. Violating any single rule collapses the security entirely. | Full course: COM-07, One-Time Pads |
| Book ciphers | Rely on two identical books and pre-agreed indexing rules. Offer plausible deniability and require no obvious crypto material, but are vulnerable to modern computational analysis and known-plaintext attacks, and produce a large amount of ciphertext for a small message. | Covered conceptually here; useful mainly in low-threat, covert-in-plain-sight scenarios |
| Steganography | Hiding a message inside an ordinary-looking media file rather than encrypting it. Not encryption by itself — best used after encryption, as a way to conceal that a protected message exists at all. | Covered conceptually here; a covert digital delivery tool, not a standalone protection method |
The rule that ties all three together is the same one from Part A: whatever the method, it is only as strong as the discipline applied around it.
Field reference: the same Brevity Cards for OTP set used for brevity codes in Lesson 4 also includes a bonus checkerboard, encryption/decryption instructions, and an OTP conversion grid for pairing with the full One-Time Pad course, COM-07.
What your phone already does, evaluated honestly
Most groups already use a phone-based app for day-to-day coordination alongside radio. Every one of these tools sits entirely on the CRYPTOSEC side of the four domains from Lesson 1 — none of them provide TRANSEC, EMSEC, or continuity when cellular and internet infrastructure are down. Evaluate each honestly rather than trusting a marketing claim of “encrypted.”
| Platform | Content encryption | Metadata / context exposure | COMSEC notes |
|---|---|---|---|
| Signal | True end-to-end by default (Signal Protocol, open-source, independently audited) for all messages, calls, and groups | Minimal — Sealed Sender hides sender identity from Signal’s own servers; subpoena history shows almost nothing is retained | Best-in-class CRYPTOSEC of this group. Requires a phone number to register, and both parties must be on Signal |
| Session | True end-to-end (Signal-derived protocol) | Best of this group — no phone number or email, onion-routed through a decentralized node network, no central log of who talks to whom | Public “Communities” are not end-to-end. Smaller audit history and user base than Signal |
| Telegram | Not end-to-end by default. Ordinary “Cloud Chats” are encrypted only client-to-server; true end-to-end exists solely in opt-in “Secret Chats” (one-on-one only, unavailable on desktop) | Weak — retains IP address, device details, and phone number | Treat default Telegram chats as readable by the provider. Custom protocol has drawn cryptographer criticism for lacking Signal’s audit history |
| True end-to-end for message content (runs the Signal Protocol) by default | Weak — owned by Meta, which collects contact, timing, and frequency metadata explicitly outside the encryption guarantee | Protects what is said, not who is talking to whom or how often. Cloud backups require a separate opt-in for full encryption | |
| Zello | Depends entirely on tier. Free “Friends & Family” open/public channels are not encrypted at all; paid “Zello Work” channels are encrypted (RSA key exchange plus AES) | Weak on open channels, which are public by design | A free-tier open channel is functionally a public broadcast. Know which tier and which setting you are actually using before treating it as private |
| PoC radios (cellular push-to-talk, e.g. Motorola WAVE, ESChat, Kodiak) | AES-256 is common on modern devices, sometimes referencing FIPS validation | Weak — many devices ship with built-in GPS/location tracking as a core feature, plus vendor-retained cloud server logs | Encryption is hop-to-hop through the vendor’s cloud server, not end-to-end — the provider has a technical decryption point in the middle. Most platforms are proprietary and do not interoperate with each other without a dedicated gateway |
What “PoC” means: Push-to-Talk over Cellular turns a smartphone or purpose-built device into a walkie-talkie using cellular data instead of RF spectrum. Some are carrier-based (tied to one cellular provider, such as AT&T Enhanced PTT or Verizon PTT Plus); others are carrier-agnostic “over-the-top” services that run on any carrier’s data network (such as Motorola WAVE PTX or ESChat). Both flavors depend entirely on commercial cellular coverage — if the towers are down, a PoC radio is no more useful than a phone with no signal. The basic path every transmission takes is Radio → Cellular Network → PoC Server → Cellular Network → Radio — that PoC Server in the middle is exactly the point where a vendor’s cloud infrastructure has a technical opportunity to decrypt and process the call, discussed further below.
The recurring pattern: content encryption is common; metadata protection is rare; infrastructure independence is nearly nonexistent. Signal and Session are the only two in this table with strong metadata protection, and none of the six provide any communications capability at all without cellular or internet service. In a PACE plan, every tool on this table belongs in the Primary or Alternate tier — never Contingency or Emergency.
Further reading on how PoC radios actually work, their range, and where they fit in a layered communications plan: Radio over LTE (cellular), Book of Knowledge.
Related courses: COM-04 EMCON • COM-06 Authentication & Challenge/Reply • COM-07 One-Time Pads • COM-08 Dead Drop & Courier Protocols • COM-09 Cryptographic Security • SEC-02 OPSEC • INT-02 RTSA • INT-03 SALUTE & SPOT Reporting • PLN-04 PREP-CON • PLN-05 COMCON
| ← Lesson 2 |