Also known as: KID, ALGID, Key ID, Algorithm ID
The Key ID (KID) and Algorithm ID (ALGID) are the small
P25 header fields that tell a radio which stored
encryption key and which cipher a secure
transmission uses — and, crucially, they travel in the clear even when the voice
is fully encrypted.1 The ALGID is an 8-bit number naming the algorithm (for
example 0x84 for AES-256, 0x81 for
DES-OFB, 0xAA for the ADP stream cipher,
and 0x80 for unencrypted/clear), and the Key ID is a 16-bit label that selects
one specific key out of the many a radio may hold.
How it works
Encryption on P25 needs three things agreed between transmitter and receiver: the algorithm, the key, and the per-transmission starting state. The ALGID and Key ID handle the first two by reference rather than by value. A radio provisioned via a key loader or OTAR stores keys in numbered slots; when it transmits, it advertises the ALGID and Key ID in the frame header so every receiving radio knows to look up the matching key in its own store and select the matching decryption algorithm. The actual key bits are never sent — only the label that names them.
The third element, the starting state, is the Message Indicator (MI) — the
initialization vector / keystream seed for that transmission. It too is sent in the
clear (it must be, so a late-joining receiver can synchronize the keystream) and is
carried and re-sent periodically through the call so a radio that keys up mid-
transmission can lock on. Together {ALGID, KID, MI} are the complete public
“envelope” of a secure P25 call: enough to reproduce the cipher’s setup, useless
without the secret key the KID points to.
Relevance to SDR
For a monitoring receiver these clear fields are the single most useful artifact of an encrypted call. GopherTrunk cannot decrypt keyed P25 voice, but it can read the ALGID and Key ID and therefore report exactly which cipher and which key slot a talkgroup is using — distinguishing, say, AES-256 from legacy DES or ADP, and telling apart two talkgroups that use different keys. That is genuinely actionable metadata: it identifies encrypted-versus-clear talkgroups, exposes when a system migrates algorithms, and (via changing Key IDs) reveals keyset rotations driven by OTAR. The honest boundary is firm — reading the label that names a key is not the same as possessing the key, and no amount of header parsing recovers the audio.
In practice
Because the ALGID space is standardized by the TIA, published algorithm-ID tables
let tools decode the number into a human-readable cipher name; a scanner display
that shows “ENC AES-256, KID 0x2A11” is simply rendering these two clear fields. A
common field fault is an ALGID/KID mismatch: a radio holding the right key in
the wrong slot, or the wrong keyset after a missed rekey, hears the header, fails to
find a matching key, and mutes — audible to the user as encryption failure even
though the signal decodes cleanly. Note that clear traffic is itself just
ALGID = 0x80, so the same field that flags encryption also positively confirms an
unencrypted call.
Sources
-
Project 25 — Wikipedia, for the P25 encryption model in which the algorithm and key identifiers and message indicator are transmitted alongside the encrypted payload. ↩