Scanners
Comments ▾
Figures ▾
Tables ▾

Decrypting — AES, DES & Motorola ADP on P25 (Scanners) · Volume 2

Decrypting — Vol 2: The Algorithms — DES, Triple-DES, AES-256, and Motorola ADP

The ALGID table, the output-feedback keystream, and why the key is never sent

Figure 1 — The P25 encryption ladder, weakest to strongest: Motorola ADP (RC4, 40-bit) through DES and Triple-DES up to AES-256, with each algorithm's ALGID and status. Original diagram for this site.
Figure 1 — The P25 encryption ladder, weakest to strongest: Motorola ADP (RC4, 40-bit) through DES and Triple-DES up to AES-256, with each algorithm's ALGID and status. Original diagram for this site.

2.1 About this volume

P25 doesn’t have “an encryption” — it has a small menu of ciphers, chosen per system, and the receiver is told which one is in use by a value that rides in the clear on every transmission. Some of those ciphers are genuinely strong. Some are museum pieces that survive only for interoperability with old gear. Knowing which is which is most of what you need to reason about any encrypted system you come across, so this volume walks the whole ladder, from the weakest thing Motorola ships to the AES-256 that the federal government mandates.

The mechanism underneath all of them is the same, and it’s worth getting straight first, because it explains a detail that surprises people: even when a system is encrypted, the ciphers here are used to make a keystream, and the keystream is simply XORed against the voice frames. That’s why the algorithm can change without changing anything about how the radio handles audio — it’s just a different keystream generator feeding the same XOR.

2.2 Output-feedback mode, the Message Indicator, and the Key ID

P25 runs its block ciphers (DES, Triple-DES, AES) in output-feedback mode (OFB). In OFB, the cipher isn’t used to encrypt the voice directly; it’s used as a keystream generator. You seed it, it produces a pseudo-random stream of bytes, and those bytes are XORed against the digitized voice frames. Decryption is the identical operation: regenerate the same keystream, XOR it against the ciphertext, and the voice falls out. Motorola’s ADP is RC4, which is natively a stream cipher, so it does the same job by a slightly different internal route — but from the outside it looks the same: key plus seed in, keystream out, XOR against the voice.

Two clear-text values make that keystream reproducible at the far end:

  • The Message Indicator (MI) is the initialization vector — a 72-bit (9-byte) value, sent in the clear, that seeds the keystream for this transmission. It changes every time somebody keys up, and it is re-transmitted several times a second inside the voice frames. That re-transmission is what lets a receiver that tunes in mid-call recover the current seed and re-synchronize its keystream without ever having heard the start of the call (“late entry”).
  • The Key ID (KID) is a 16-bit value, also in the clear, that names which key to use. It is not the key. It is a pointer — an index into the set of keys the radio has already been given. Both radios in a conversation must already hold the key that the KID refers to; the key material itself is never, ever transmitted over the voice channel.

This is the crux of the whole subject, and the dive keeps returning to it: the algorithm, the key ID, and the seed are all public; the key is private and pre-shared. Knowing the ALGID reveals the cipher. Knowing the KID reveals which key. Neither one yields the key, and without the key there is no keystream and no voice.

2.3 The ALGID table

The algorithm in use is named by the ALGID (Algorithm ID), an 8-bit value defined by the TIA-102.AAAD encryption protocol standard and carried in the clear. Values split roughly into a classified/Type-1 range (low values, used by the military and not something you meet on a public-safety system), a standard TIA-registered range (0x80–0x9F), and a manufacturer/proprietary range (0xA0–0xFF). The ones that matter for anyone reading a public-safety system:

Table 1 — The algorithm in use is named by the ALGID (Algorithm ID), an 8-bit value defined by the TIA-102.AAAD encryption protocol standard and carried in the clear. Values split roughly into a classified/Type-1 range (low values, used by the military and not something you meet on a public-safety system), a standard TIA-registered range (0x80–0x9F), and a manufacturer/proprietary range (0xA0–0xFF). The ones that matter for anyone reading a public-safety system

ALGIDAlgorithmKey lengthStanding
0x80Unencrypted (clear)—The talkgroup is not encrypted at all.
0x81DES-OFB (single DES)56-bitBroken since the 1990s; legacy interoperability only.
0x82Two-key Triple-DES112-bit (~80 effective)Retired by NIST; rare in the field.
0x83Three-key Triple-DES168-bit (~112 effective)Retired by NIST; rare in the field.
0x84AES-256 (AES-OFB)256-bitThe federal P25 standard. No practical break.
0x85AES-128128-bitStrong; less common than AES-256 on P25.
0x9FDES-XL (Motorola)56-bitLegacy Motorola DES variant.
0xAAMotorola ADP40-bit (RC4)Proprietary, export-grade, weakest tier.

A caution on that table: the endpoints — clear 0x80, DES 0x81, AES-256 0x84, ADP 0xAA — are solid across every source checked (the SDRTrunk decoder’s algorithm enum, a Codan P25 training manual, and OP25 all agree). The middle Triple-DES rows are where sources occasionally disagree by a value or two, and at least one community table has them wrong, so the table follows the SDRTrunk/Codan values. The proprietary 0xA0–0xFF band also holds older Motorola schemes — DVP, DVI-XL, DES-XL — that are rarely met today. For an exact value on something obscure, the decoder source is a better authority than any prose table, this one included.

2.4 DES — broken, and everyone knows it

The Data Encryption Standard was the U.S. federal cipher from the 1970s. Its problem is the key: a 56-bit effective key, which was a deliberate compromise even at the time and became indefensible as computers got faster. In 1998 the Electronic Frontier Foundation built a purpose-made machine called Deep Crack for about $250,000 that brute-forced a DES key in roughly 56 hours, and by January 1999 a distributed effort with EFF did it in about 22 hours. NIST withdrew the DES standard in 2005 with the plain statement that it “no longer provides the security … needed.” A 56-bit keyspace is trivially searchable now.

DES survives on some P25 systems (0x81, and Motorola’s 0x9F DES-XL variant) purely as a legacy interoperability option, so old radios that only speak DES can still talk. DES on a system reads like a deadbolt from 1975 still on a government door: it’s there, it technically latches, and nobody serious considers it security. That it is “breakable in theory” is not the same as a hobbyist pulling live audio off the air, a distinction drawn carefully in Vol 4.

2.5 Triple-DES — a bridge that mostly isn’t used

Triple-DES runs DES three times to stretch the key. Two-key Triple-DES (0x82) has about 80 bits of effective strength; three-key (0x83) about 112. It was the sanctioned bridge between DES and AES, but NIST has since retired it — two-key was disallowed years ago, three-key was deprecated and then disallowed for encryption, and the specification was formally withdrawn on January 1, 2024. On P25 it exists in the standard but is genuinely rare compared with DES on the old end and AES on the new end. It appears here mostly so the ALGID table is complete; in practice, a public-safety system is almost always either clear, DES (legacy), ADP (cheap), or AES.

2.6 AES-256 — the standard, and the wall

AES (the Advanced Encryption Standard, FIPS-197, the Rijndael cipher) is what a modern encrypted P25 system uses, and P25 uses the 256-bit key length, ALGID 0x84, in OFB mode. A 256-bit key means a keyspace of 2²⁵⁶ — about 1.16 × 10⁷⁷ possible keys. That number is not “very large” in the way a lottery is very large; it is large past the point where brute force means anything, even against every computer that will ever be built. The best known cryptanalytic attack on full AES-256, the 2011 “biclique” result, shaves the work factor to roughly 2²⁵⁴·⁴ — about four times better than brute force, which against a 2²⁵⁶ space is a rounding error and, importantly, is not a practical attack. There is no exploitable break of AES-256. The U.S. Department of Homeland Security’s P25 encryption guidance mandates AES-256 for federal interoperability precisely because DES and the proprietary schemes are not acceptable.

This is the wall that the whole “can you decode it?” question runs into. When a system is running AES-256, the answer is not “it’s hard” — it’s “no, and not within any foreseeable timeframe by attacking the cipher.” Everything that has ever actually defeated an encrypted P25 system in the real world went around AES, not through it. That is the subject of Vol 4.

2.7 Motorola ADP — RC4, forty bits, and the honest label

At the bottom of the ladder is Motorola’s ADP — “Advanced Digital Privacy” — ALGID 0xAA. Despite the name, it is the weakest option here, and it is worth understanding why, because ADP is common on business and some public-safety systems that wanted “keep the casual scanner out” without paying for the AES-capable gear.

ADP is RC4 with a 40-bit key. Two separate weaknesses stack on top of each other. First, the key: 40 bits is 2⁴⁰ ≈ 1.1 × 10¹² possibilities, which is small enough that a single modern GPU can search it — this is old “export-grade” cryptography, deliberately weakened key lengths from the era when strong crypto was export-controlled. Second, the algorithm: RC4 itself is broken. It has the Fluhrer-Mantin-Shamir key-scheduling weakness that famously destroyed WEP Wi-Fi security, and strong statistical biases in its early keystream bytes; RC4 was prohibited in TLS by the IETF in 2015. On top of that, because P25 runs ADP as an OFB-style keystream seeded by the MI, a repeated Message Indicator means a repeated keystream — the classic two-time-pad exposure, where XORing two messages encrypted with the same keystream cancels the keystream out. ADP is weaker even than the old 56-bit DES-XL on key length alone.

The honest label for ADP is the one the community uses: obscurity against casual scanning, not security. It keeps someone with a stock scanner from hearing the traffic — because the scanner shows ENC and mutes, exactly as it would for AES — but it does not stand up to someone who has actually decided to break it. Whether anyone has published a clean, reproducible tool that recovers an unknown ADP key live off the air is a more careful question than the forums admit, and Vol 4 takes it up. The distinction between “weak in theory” and “here is a working tool” matters, and it’s easy to blur.

Sources

Comments (0)

  1. Loading…

Comments are held for moderation — nothing appears until approved.