Encryption and Voice Privacy on Public-Safety Radio: DES, AES, ADP, and Scrambling

Independence notice: RunBoard is an independent operations platform and is not affiliated with, endorsed by, or sponsored by any company, product, network, or agency named in this article. Names are used only for identification and education.

From scramblers to ciphers: a short history

Public-safety radio has wanted privacy for about as long as it has existed, and the tools for getting it have changed dramatically. In the analog era, the only practical way to keep a conversation off a bystander's scanner was to distort the audio itself. Early devices flipped or shifted the voice signal so it came out garbled to anyone without a matching unit. It sounded secret, and for a while it kept the neighbor's police scanner from making sense of a traffic stop. But it was never really securing information. It was rearranging sound.

As radios went digital, so did the privacy tools. Instead of distorting audio, digital systems could take the stream of ones and zeros that represent the voice and run it through a mathematical cipher, turning it into output that means nothing without the correct key. This was a genuine step change. A properly implemented digital cipher does not just make the audio hard to follow, it makes the content computationally impractical to recover. The history of radio privacy is essentially the story of that migration, from obscuring the sound to actually protecting the data, and understanding where a given feature sits on that timeline tells you most of what you need to know about whether it can be trusted.

The catch is that marketing language did not always keep up with technical reality. Words like "privacy," "secure," and "encryption" get applied loosely, and some of what is sold today as a privacy feature is closer in spirit to the old analog scramblers than to a modern cipher. That is why you cannot simply trust the label on the datasheet. You have to know what is underneath it.

Why scrambling is not encryption

The single most important distinction in this entire subject is the difference between scrambling and encryption, because they are sold with similar words and deliver wildly different protection. Analog voice scrambling, including voice inversion and its relatives, does not encrypt anything. It obscures the audio. It takes the sound and mangles it so a casual listener hears noise instead of speech. There is no cryptographic key protecting the meaning of the words in any serious sense. The transformation is fixed or nearly so, and it is well understood, which means anyone motivated to reverse it can do so without much trouble.

This matters because scrambling gives a false sense of security that is arguably worse than no security at all. A crew that believes a channel is protected will speak freely on it. If the protection is only voice inversion, they are broadcasting sensitive information in the belief that it is shielded when it is not. Think of scrambling as a privacy fence, not a vault. It keeps the idly curious from stumbling onto your traffic. It does not stop anyone who actually wants in.

Scrambling has not entirely disappeared from digital systems, either. Some modern digital radios offer a scrambling feature as a low-tier privacy option, and it should not be confused with real encryption just because it lives inside a digital radio. If a specification describes a privacy feature using the language of scrambling rather than a named cipher and key length, treat it as obscurity, not protection.

DES and why it is obsolete

When digital encryption first arrived in public-safety radio, DES was the standard of the day. It was a real cipher, a genuine improvement over analog scrambling, and for a time it did the job. The problem is time itself. DES uses a short key, 56 bits, and that key length was already looking thin decades ago. In the late 1990s, DES was publicly brute-forced. Researchers demonstrated that the key space was small enough to search through with dedicated effort, and that demonstration effectively ended DES's life as a serious security tool. What was once state of the art became a cautionary tale about picking a key length that cannot age.

DES is no longer considered secure. That is not a controversial or fringe opinion, it is the settled consensus, and it is the reason the standards moved on. In the P25 world specifically, DES was historically an available option, but it is deprecated in favor of AES. If you are evaluating an older system, or a used one, or a quote that still lists DES as its encryption, that is a signal to stop and ask why. A system whose strongest protection is DES is a system protecting your traffic with a lock that was publicly picked a generation ago.

The lesson from DES is not just "DES is old." It is that key length has a shelf life, and that a cipher which looked bulletproof at purchase can become a liability without a single line of it changing. That lesson shapes the right answer today.

AES: the modern secure standard

AES is the modern accepted standard for encryption in public-safety radio and far beyond it. It replaced DES as the algorithm that serious systems are built around, and unlike its predecessor it has held up. AES has no known practical break. When an algorithm has been studied this intensely, by this many people, for this long, and still has no practical weakness, that track record is worth more than any single technical claim, and it is a large part of why AES is the right default.

AES comes in three key lengths: 128, 192, and 256 bits. All three are considered secure against current threats. It is worth stating plainly that there is no such thing as AES-512, despite the occasional appearance of that phrase in loose conversation or dubious marketing. If you see AES-512 on a datasheet, treat it as a red flag about the vendor's rigor, not as a stronger product. The real menu is 128, 192, and 256, and for public-safety purposes the practical decision is usually between 128 and 256.

For most agencies the guidance is simple: if you are going to encrypt, encrypt with AES, and lean toward AES-256 unless you have a specific reason not to. AES-128 is not weak. But 256 costs little extra in practice and buys a meaningful margin, and the reason that margin matters comes down to how these systems age and what is coming.

• AES-128 is secure against current threats and is a legitimate choice.
• AES-192 exists as a middle option and is rarely the deciding factor in a procurement.
• AES-256 is the prudent default for a system you expect to keep for many years, for reasons covered in the next section.

The quantum question and why 256-bit is the prudent hedge

You will hear quantum computing raised in encryption discussions, sometimes with an alarming tone that does not match the near-term reality. Here is the pragmatic version, stripped of hype. The relevant future threat from large-scale quantum computing is that it effectively halves the strength of a symmetric cipher like AES. That is not the same as breaking it. It means a given key length behaves, against that future threat, roughly as if it were half its size.

Apply that to the AES key lengths and the picture is reassuring rather than frightening. AES-256, halved in effective strength, would still retain about 128-bit-equivalent security, which is an enormous margin and is considered safe for the foreseeable future. In other words, AES-256 is expected to remain strong even against the quantum threat that people worry about. This is precisely why 256-bit is the prudent hedge. You are not buying it because 128 is broken today. You are buying it because a radio system is a long-lived asset, and 256 gives you headroom that outlasts the equipment.

What you should not do is overstate the near-term danger. There is no practical quantum attack on AES today, and the sky is not falling. The correct response is not panic, it is a quiet, sensible default: when you encrypt something you expect to live for a long time on a radio you expect to keep for a long time, choose AES-256 and stop worrying about it.

ADP and short-key proprietary options

Between real AES encryption and analog scrambling sits a middle tier of proprietary, short-key privacy options, and this is where the most confusion, and the most disappointment, tends to happen. The best-known example is ADP, Motorola's Advanced Digital Privacy. ADP is a proprietary cipher built on RC4 with a short 40-bit key. That small key space, combined with known weaknesses in this class of cipher, makes ADP defeatable relatively quickly by someone with the right tools, and software-defined radios have made those tools far more accessible than they used to be.

None of that means ADP is worthless. It has a real and honest use: keeping casual scanner listeners out of your traffic. If the goal is to stop the hobbyist with a scanner app from following routine chatter, ADP does that, and it is frequently available cheaply or at no cost, which makes it attractive for agencies that want a light privacy layer without a licensing bill. The problem is only when ADP is mistaken for genuine security. Experts do not consider a 40-bit proprietary cipher sufficient to protect sensitive information, and you should not treat it as such.

Two more points belong on the record. First, ADP is not part of the P25 standard. It is a manufacturer feature layered onto P25 gear, not an element of the open standard, and that distinction has real consequences for compliance, discussed below. Second, ADP is representative of a broader category. Any proprietary privacy option with a short key or an RC4-class design should be filed under casual privacy, not real security, regardless of the brand name on the box.

• Fine for: keeping casual scanner listeners and the idly curious out of routine traffic, at low or no cost.
• Not sufficient for: genuinely sensitive information you need protected against a motivated party.
• Remember: ADP is proprietary and not part of the P25 standard, which matters for compliance.

How offerings differ across P25, DMR, and NXDN

The digital mode your system uses shapes what encryption is realistically on the table, and at the decision level the differences are easier to reason about than the underlying technology suggests. The key idea is that "encrypted" means different things in different modes and from different vendors, so you cannot evaluate encryption in the abstract. You have to ask what a specific product in a specific mode is offering.

P25 is the mode most closely associated with formal public-safety interoperability, and within it AES is the recognized strong option while DES is the deprecated legacy one. Proprietary additions like ADP can be layered onto P25 gear, but as noted they are not part of the standard, and choosing them instead of AES has knock-on effects. When someone says a P25 system is encrypted, the follow-up question is always: encrypted with what, AES or something proprietary?

DMR is where the variation is widest, because DMR encryption depends heavily on the vendor. Basic and enhanced privacy options in DMR are generally weak, using short keys or RC4-class designs in the same family as the casual-privacy tier described above. But some DMR implementations offer AES, which is strong. So two DMR radios can both claim encryption and be worlds apart, one offering casual obscurity and the other offering genuine protection. With DMR more than any other mode, read the specific privacy feature carefully and confirm whether AES is actually available and enabled.

NXDN has its own privacy landscape, and it is one of the modes where scrambling shows up as an offered feature. That circles back to the first principle of this guide: a scrambling option inside a digital mode is still scrambling, not encryption, and should be understood as obscurity. Across all three modes the decision-level rule is the same. Do not accept the word "encrypted" as an answer. Insist on the specific algorithm and key length, and judge it by that.

The interoperability cost of encryption

Encryption is not free, and the most important cost is not the licensing fee. It is interoperability. Encryption only works when both radios share the algorithm and the key. Two radios that do not agree on both cannot understand each other's encrypted traffic, which means a mismatch in encryption breaks the ability to talk during exactly the moment that ability matters most: a multi-agency response.

This is the defensive heart of the whole subject. If your agency encrypts a channel and a mutual-aid partner does not share your algorithm and key, they cannot hear you on that channel, and you cannot hear them. It does not matter how strong your AES-256 is if the arriving unit from the next jurisdiction is locked out of the conversation. Encryption that protects a channel from outsiders protects it from your own partners just the same, because to the radio there is no difference between an eavesdropper and a friend who lacks the key.

The practical answer is not to avoid encryption. It is to be deliberate about where you apply it and to keep interoperability channels usable. Designate and maintain unencrypted or commonly-keyed interoperability talkgroups so that mutual-aid partners can always reach you, and reserve encryption for the traffic that genuinely needs it. Agencies that encrypt everything by default often discover the problem the hard way, on a large incident, when a neighboring crew keys up and hears silence. Plan the encrypted and the interoperable sides of your system together, not separately.

• Encrypted traffic is only intelligible to radios that share both the algorithm and the key.
• A key or algorithm mismatch silently breaks communication with mutual-aid partners.
• Keep designated interoperability channels usable so partners can always reach you.
• Encrypt selectively, matching protection to the sensitivity of the traffic.

Standards, grants, and buying with your eyes open

There is a compliance dimension to this decision that can outlast the equipment, and it deserves careful framing. Historically, federal interoperability grant guidance has required AES, commonly AES-256, for encrypted P25 to be considered standards-compliant. Under that historical guidance, choosing a proprietary encryption option like ADP instead of AES could render a P25 system non-compliant and jeopardize grant eligibility. In other words, a short-key proprietary scheme could cost an agency far more than it saved, if it disqualified the purchase from grant funding or triggered a problem in a later review.

The essential caveat is that grant rules and standards guidance change, and this article cannot tell you what is required in your funding cycle today. Treat the point above as historical context and a prompt to verify, not as a confirmed current-year fact. Before you buy, confirm the current grant guidance and standards requirements that apply to your funding and your mode. The consequence of getting this wrong is not merely technical, it is financial and administrative, and it is the kind of thing that surfaces during an audit long after the person who signed the order has moved on.

Pulling the whole picture together, the pragmatic guidance is straightforward. Encrypt what genuinely needs it, and when you do, use AES, leaning to AES-256 for its longevity margin. Do not mistake analog scrambling or short-key proprietary schemes like ADP for real security; they have a place as casual privacy, but they are not a vault. Keep your interoperability channels usable so encryption never costs you a mutual-aid partner at the worst possible moment. And confirm the current standards and grant requirements before you buy, because the rules that govern compliance and funding change over time and the burden of checking is on you. Do those four things and you will have made a decision you can defend years later, on both the radio and the paperwork.

Independence notice: RunBoard is an independent operations platform and is not affiliated with, endorsed by, or sponsored by any company, product, network, or agency named in this article. Names are used only for identification and education.