DMR & P25 encryption (RC4: “Enhanced Privacy” and ADP)

This page covers the two RC4-based air-interface encryptions GopherTrunk can decrypt in-process with an operator-supplied key: DMR Enhanced Privacy (below) and P25 ADP (P25 ADP, verified on air). Both are configured with the same encryption_keys block.

DMR encryption (ARC4 / RC4 “Enhanced Privacy”)

GopherTrunk can be configured with known decryption keys for DMR systems that protect voice with the DMRA ARC4/RC4 “Enhanced Privacy” algorithm. With a key configured, an encrypted call is descrambled in-process and recorded as clear audio; without one, the call is still captured (ciphertext) and its privacy header is decoded and surfaced so the operator can see which key it needs.

This is known-key support only: the operator supplies a key they are authorized to hold. GopherTrunk performs no key recovery of any kind — it is the same model used by SDRTrunk, DSD-FME and OP25. Only monitor systems you are legally permitted to monitor.

Verification status (issue #1187): the descramble is capture-verified — the reporter’s two known-key discriminator captures (key IDs 11 and 22, colour code 2, TG 582743, a simplex handheld) decode to speech through TestDMREnhancedPrivacyReplay, and the first three superframes of one transmission are pinned as literal on-air vectors in internal/radio/dmr/voice/testdata/ep_issue1187_ptt1.json. What remains is the daemon path on air: a live call with the key configured that records intelligible audio. The replay -key path below runs that same daemon voice path on a recording, with the release binary.

Configuration

Encryption keys are declared per trunking system, under trunking.systems[].encryption_keys:

trunking:
  systems:
    - name: "Example-DMR"
      protocol: dmr
      control_channels: [451_000_000]
      talkgroup_file: "/etc/gophertrunk/talkgroups-dmr.csv"
      encryption_keys:
        - key_id: 1            # matches the key ID in the privacy header
          algorithm: rc4       # only "rc4" / "arc4" is accepted today
          key: "0123456789"    # hex; whitespace and a "0x" prefix are ignored

Each entry has three fields:

Field	Meaning
key_id	The key identifier the radios advertise in the Privacy Indicator header. A system that rotates between several keys resolves to the right one by ID.
algorithm	The cipher. Only rc4 (alias arc4) is accepted. aes / des are rejected at config-load with an explicit “not supported yet” error so the schema can grow later without a config break.
key	The raw key, hex-encoded (Enhanced Privacy keys are 40 bits = 10 hex digits). Surrounding whitespace, internal spaces and an optional 0x/0X prefix are tolerated. 1–32 bytes.

The config is validated when the daemon loads it: an unknown algorithm, malformed hex, an over-length key, or a duplicate key_id within one system is a hard error. At startup the daemon logs in-process decryption keys configured (DMR enhanced privacy) when any system carries a key.

What the pipeline does

A DMR voice call flows through these stages:

1. Control-channel decode — the DMR Tier II / Tier III decoders emit a trunking.Grant. The grant’s Encrypted flag is read from the Full Link Control ServiceOptions bit, so an encrypted call is known as such before voice even starts.
2. Privacy Indicator header (internal/radio/dmr/pi.go, dmr/voice/pi_detector.go) — the data burst an encrypted transmission sends after its Voice LC Header carries the algorithm ID, the key ID and the 32-bit Message Indicator (the per-transmission IV). The voice chain decodes it (slot type → BPTC(196,96) → CRC-CCITT with the PI-header mask) and publishes a call.encryption event, so the call log, the web console and the webhook carry algorithm_id / key_id for DMR exactly as they do for P25. The header is logged with its raw octets (composer: dmr PI header — call is encrypted).
3. Voice superframe decode (internal/radio/dmr/voice) — the composer runs an IQ → DMR receiver → superframe-decoder chain on the granted voice channel, locking onto the A–F voice superframe and extracting its eighteen 72-bit on-air AMBE+2 frames.
4. AMBE+2 forward-error-correction (ambefec.go) — each 72-bit on-air frame is deinterleaved, Golay-corrected and assembled into the 49-bit vocoder payload.
5. Enhanced Privacy descramble (dmr/voice/ep.go, composer/dmr_ep.go) — for a call known to be encrypted, each superframe’s Message Indicator is resolved (below) and, when a configured key matches the header’s key ID, the 18 payloads are XORed with the RC4 keystream. Frames that failed FEC keep their keystream slot so the rest stay aligned; the AMBE+2 silence vector is passed through in clear, as radios transmit it.
6. Vocoder → WAV (internal/voice/ambe2, "ambe2-dmr") — the (now clear) frames are rendered to 8 kHz PCM and written to the call’s .wav; the 49-bit frames also land in the .raw sidecar.

The keystream construction

Two independent open decoders agree on it (SDRTrunk’s header and embedded-parameter parsers; DSD-FME’s on-air-verified decrypt), and GopherTrunk’s implementation is pinned against literal vectors computed from their stated algorithms, not ported code:

• RC4 key = key ‖ Message Indicator (4 bytes, MSB first). The first 256 keystream bytes are discarded — the same warm-up as P25 ADP — then 7 bytes per 49-bit frame, contiguous across the superframe.
• The MI advances once per superframe through a 32-bit LFSR (x³² + x⁴ + x² + 1, 32 shifts). The PI header’s MI is the first superframe’s.
• Every superframe also carries the NEXT superframe’s MI for late entry: each of the 18 frames donates a 4-bit nibble in its unprotected C3 bits, and the 72 bits reassemble into three Golay(24,12) codewords holding the 32-bit MI plus a 4-bit CRC. That it names the next superframe (the P25 Encryption Sync convention) is capture-pinned: on the #1187 radio every embedded IV equals the LFSR advance of the MI before it, the first equals the advance of the PI header’s, and descrambling each superframe with its own embedded IV stays at ciphertext level. It is also the order DSD-FME applies (the LFSR advance in dmr_alg_refresh runs before the late-entry comparison). GopherTrunk verifies the embedded IV on every superframe: it confirms (or, when it decodes perfectly clean, corrects) the prediction for the superframe that follows, and a chain that missed the PI header decrypts the superframe it first verified an IV on by rewinding the LFSR one step (RewindMI).

The counters behind all of this are in the debug-level composer: dmr enhanced privacy line: pi_headers, iv_verified, mi_predicted, mi_mismatches, descrambled_frames, silence_frames, no_key, no_mi.

Checking a key offline with replay

gophertrunk replay runs a recording through the daemon’s own voice path — decode → trunking engine → voice composer → recorder — and -key gives that path a key exactly as encryption_keys gives it to the daemon. No config file and no Go toolchain are needed; the release binary does it:

# A DSD-style discriminator-audio recording (the receiver's raw, unsquelched
# FM discriminator output — mono or stereo WAV, 8/16-bit or float, any rate)
gophertrunk replay -in ep-call.wav -format disc -protocol dmr-tier2 -freq 1 \
  -record-voice -out-dir rec -key rc4:11:4E77AD0B51

# An IQ capture (gophertrunk capture, Signal Lab, SDR# baseband…)
gophertrunk replay -in ep-call.cs16 -format cs16 -sample-rate 2400000 \
  -protocol dmr-tier2 -freq 1 -record-voice -out-dir rec -key rc4:11:4E77AD0B51

• What replay can record. It follows the grants it decodes, on the same carrier. A conventional DMR recording (direct mode or a Tier II repeater) grants from its own Voice LC headers, so it records. A P25 call is granted by the control channel, so -key adp:… only helps when the capture holds that control channel and the voice; a recording of a P25 voice channel on its own produces no grant and no recording. For that case use the TestP25ADPReplay harness (GT_P25_ADP_*, needs a Go toolchain) or a live daemon run with encryption_keys.

• -key is ALG:KEYID:HEXKEY (rc4/arc4 for DMR Enhanced Privacy, adp for P25 ADP) or KEYID:HEXKEY for RC4, and may be repeated — one per key ID. It is validated like a config entry.
• -freq is required with -record-voice (any non-zero value works for a recording).
• The call lands under rec/replay/<talkgroup>/ as a .wav you can listen to, plus the .raw frames and a .json sidecar. Intelligible speech is the confirmation; the log line composer: dmr PI header — call is encrypted … key_id=11 … key_configured=true shows the key was matched.
• -format disc prints a one-line check of the audio first: a real discriminator tap keeps ~90 % of its energy below 3 kHz in its keyed stretches. Decoded or re-recorded audio fails that check and cannot be decoded by any receiver.

Offline analysis: the crypto-frame capture

With recordings.crypto_capture_path set, every encrypted DMR superframe is also appended to the cryptolab JSONL bridge — protocol: "dmr", the superframe’s MI as iv, the 18 packed frames (126 bytes, as on air) as ct, plus algid / keyid — the same artifact the P25 path writes and that gophertrunk cryptolab consumes. Superframes with an FEC-failed frame are skipped rather than padded, so the keystream positions in ct are exact.

Contributing a known-key capture

A green synthetic test is not an on-air verification (this repo’s #764/#771 rule). What verifies the descramble is one clear recording of an Enhanced Privacy transmission from a radio whose key you hold, run through the replay harness. Please attach it to the issue (or link a file drop) rather than sending it by email — the maintainers work from the tracker, and the recipe has to be reproducible.

What to send:

1. An IQ capture of the encrypted call, made with the daemon’s own tool so the rate and format are known:

   gophertrunk capture -freq <Hz> -sample-rate 2400000 -seconds 30 -protocol dmr -format cs16 -out ep-call.cs16
   

   (a Signal Lab wav/flac capture works too). A DSD-FME-style discriminator-audio WAV (16-bit mono) is also accepted.

2. The key (hex, e.g. 0123456789) and the key ID the radios are programmed with, and the radio model / firmware if you know it.
3. Optionally the DSD-FME output for the same file — its DMR PI H- ALG ID / KEY ID / MI lines are the cross-check.

Then, on a build from main:

GT_DMR_EP_IQ=ep-call.cs16 GT_DMR_EP_RATE=2400000 GT_DMR_EP_KEY=0123456789 GT_DMR_EP_OUT=ep-call.wav \
  go test ./cmd/gophertrunk -run TestDMREnhancedPrivacyReplay -v

(GT_DMR_EP_AUDIO=<wav> instead of GT_DMR_EP_IQ for discriminator audio.) The harness prints every PI header it decoded (algorithm, key ID, MI, raw octets), the per-superframe embedded-IV / MI chain, the descrambled frame count and the seconds of the output WAV that carry speech, ending in a one-line VERDICT. GT_DMR_EP_DUMP=<json> writes every header and every superframe’s raw on-air and FEC-decoded frames, embedded IV and MI before descrambling, so a keystream hypothesis can be tested offline without re-running the receiver. The harness slices voice with the cadence-detecting decoder production uses; a simplex handheld sends one burst per 60 ms frame, and the back-to-back single-slot slicer (GT_DMR_EP_SINGLE_SLOT=1) reads bursts B–F out of the gaps — on the #1187 captures that produced frames whose Golay codewords needed the random-word 3 corrections, which looked exactly like post-FEC scrambling and was not. “Discriminator audio” means the receiver’s raw, unsquelched FM discriminator output (what DSD-FME is fed through a virtual cable), not a radio’s speaker or a decoder’s playback: the #1187 DMR files were 96 kHz recordings of the decoded (garbled) audio — white-noise bursts gated at the TDMA slot cadence — from which no receiver can recover a burst, and the harness now says so (“NOT a demodulable 4FSK discriminator tap”) instead of a bare “nothing decoded”. When in doubt, record IQ with gophertrunk capture. Listen to the WAV: intelligible speech is the confirmation; a flat hiss with everything else decoding points at the key / key ID / construction, and the header lines are the evidence to post.

P25 ADP (RC4, ALGID 0xAA)

P25’s ADP (“Advanced Digital Privacy”) is the same cipher keyed the same way — RC4 with the 40-bit key followed by the Message Indicator, the first 256 keystream bytes discarded — and is verified on air (issue #1187: a reporter’s 6.2 s ADP call, NAC 239 / key ID 1, decodes to speech with the configured key). Configure it exactly like a DMR key, under the P25 system:

trunking:
  systems:
    - name: "Example-P25-ADP"
      protocol: p25
      control_channels: [851_000_000]
      encryption_keys:
        - key_id: 1            # the KID the LDU2 Encryption Sync names
          algorithm: adp       # "adp" / "rc4" / "arc4" are one family
          key: "1234567890"    # 40-bit key, hex

What the Phase 1 voice chain does (composer/p25_adp.go, phase1/adp.go):

1. Every LDU2 carries an Encryption Sync (algorithm ID, key ID, 72-bit Message Indicator). The chain already surfaces it as call.encryption; with a configured key for that key ID and algorithm 0xAA it also decrypts.
2. The ES names the MI of the next superframe (LDU1 + LDU2, 360 ms), and successive MIs follow the 64-bit LFSR x⁶⁴+x⁶²+x⁴⁶+x³⁸+x²⁷+x¹⁵+1 (TIA-102.AAAD). The first superframe’s MI is normally carried by the HDU, which the LDU assembler does not deliver — so the chain rewinds the LFSR from the first ES it decodes to recover the current superframe’s MI, holding that superframe’s frames (once per call, at most 360 ms) until the ES arrives. An LDU2 whose ES fails RS advances the chain by the LFSR prediction instead.
3. Per superframe the keystream is applied to the FEC-decoded 88-bit IMBE frames: LDU1’s nine frames from absolute keystream byte 267, LDU2’s from 368, 11 bytes each, with a 2-byte gap before the ninth (the Low Speed Data word) — OP25’s layout. The recorder then vocodes clear frames.

Both the layout and the MI schedule are pinned by the reporter’s capture (internal/radio/p25/phase1/testdata/adp_issue1187_ldus.json): under the production rules the IMBE pitch track goes from ciphertext-random to speech-continuous, every alternative (wrong key, MI applied to the current superframe, no 11-byte skip) stays random, and all fourteen consecutive MIs satisfy the LFSR.

Replay a capture of your own:

GT_P25_ADP_IQ=adp-call.cs16 GT_P25_ADP_RATE=2400000 GT_P25_ADP_KEY=1234567890 GT_P25_ADP_OUT=adp-call.wav \
  go test ./cmd/gophertrunk -run TestP25ADPReplay -v

(GT_P25_ADP_AUDIO=<wav> for discriminator audio.) It prints every LDU2’s ES, the descrambled frame count and a VERDICT based on IMBE pitch continuity — never on loudness (random vocoder parameters are loud).

P25 DES-OFB, TDES and AES (ALGIDs 0x81 / 0x83 / 0x86 / 0x85 / 0x84 / 0x89)

The same Phase 1 voice path descrambles the OFB-family algorithms when a key is configured. The construction is the one OP25 runs on air (op25_crypt_des.cc / op25_crypt_aes.cc), so the frame mapping is ADP’s with a different leading discard — one cipher block instead of RC4’s 256 warm-up bytes:

Algorithm	Key	IV	Discard	LDU1 u0	LDU2 u0
ADP (0xAA)	40-bit	RC4 keyed key‖MI[0:8]	256	267	368
DES-OFB (0x81), TDES (0x83 two-key, 0x86 three-key)	64 / 128 / 192-bit	MI[0:8]	8	19	120
AES-128 (0x85), AES-256 (0x84, 0x89)	128 / 256-bit	MI expanded to 128 bits by the TIA LFSR: MI ‖ LFSR64(MI)	16	27	128

Within an LDU the nine 11-byte IMBE frames are contiguous with a 2-byte Low Speed Data gap before u8; the MI schedule (an LDU2’s ES announces the NEXT superframe, successive MIs follow the 64-bit LFSR) is identical for every algorithm. Configure the key with algorithm: des, tdes or aes — the key LENGTH selects the variant (16 vs 24 bytes for TDES, 16 vs 32 for AES) and the chain refuses a key whose length disagrees with the ALGID on air rather than guessing.

encryption_keys:
  - key_id: 2
    algorithm: aes
    key: "000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f"
  - key_id: 3
    algorithm: des-ofb
    key: "0123456789abcdef"

Verification status (#764/#771): reference-pinned, not capture-pinned. The layout and the AES IV expansion are pinned against OP25’s literal offsets and a transcription of its expand_mi_to_128, and the synthetic chain test proves the daemon applies them end-to-end, but GopherTrunk has no DES/TDES/AES call of its own. TestP25ADPReplay accepts a DES/AES capture with the matching key (GT_P25_ADP_KEY — the ES’s ALGID selects the algorithm); pitch continuity off the chance floor is the confirmation. Not decrypted on P25: DES-XL (0x9F, a different construction) and Phase 2 TDMA (the composer’s Phase 2 chain only publishes the Encryption Sync).

Calls you cannot decrypt: recordings.mute_encrypted

Without a key the vocoder renders the ciphertext as random-parameter “speech” — loud, unintelligible, and easy to mistake for a decode fault. recordings.mute_encrypted: true records and streams silence for an encrypted call no configured key covers (the behaviour of every hardware scanner, SDRTrunk, trunk-recorder and DSD-FME), while the .raw / .imb / .amb sidecars keep the ciphertext frames and the call is logged, shown and uploaded exactly as before. A call whose key id matches an encryption_keys entry is decrypted in-process and never muted; encryption discovered mid-call (a P25 LDU2 Encryption Sync) mutes from that frame on. The call-ended log line carries muted_frames so a silent recording of an encrypted call reads as intended. skip_encrypted remains the stronger option (no file at all).

Decoding the .raw sidecar out-of-band

The .raw file is a flat concatenation of 7-byte frames, each holding one FEC-decoded 49-bit AMBE+2 voice frame (MSB-first, 49 bits + 7 bits of zero padding). This is a standard AMBE+2 frame format and can be fed to an external AMBE decoder (an mbelib-based tool, DSD-FME, or DVSI hardware) to produce audio. For an encrypted call with no configured key it holds the encrypted frames.

What is not implemented

• Hytera Enhanced Privacy (FID 0x68, a 40-bit MI and a vendor key schedule) and Kirisun privacy are recognised in the PI header and logged, but not decrypted.
• DES / AES DMRA algorithms on DMR: the cryptolab keystream generator realises the cores, but the DMR voice path does not apply them (no capture to validate the IV expansion against). On P25 they are applied (section above).
• Motorola Basic Privacy (a 16-bit scrambler, not a cipher).

References

• ETSI TS 102 361-1 (PI header data type, CRC masks §B.3.12).
• SDRTrunk (Apache-2.0): EncryptionParameters, PiHeader, VoiceSuperFrameProcessor, Golay24 — header layout, embedded-IV fragment positions and reassembly, CRC-4.
• DSD-FME (GPL — read for the protocol conventions only, nothing ported): dmr_pi.c (header fields, MI LFSR), dmr_le.c (late-entry MI), dsd_mbe.c / crypt-rc4.c (key‖MI, 256-byte drop, 7 bytes per frame, silence passthrough).
• The AMBE+2 FEC is ported, with bit layouts preserved 1:1, from mbelib and szechyjs/dsd (ISC) — attribution in THIRD_PARTY_LICENSES.md.

See also docs/vocoders.md for the IMBE / AMBE+2 licensing landscape and the vocoder plugin model.