The first P25 standards came out in 1989, so encrypted police radios were certainly starting to be deployed in the early 90s. Obviously, adoption rate depended on the department budget, with many rural departments taking until the 2010s to finally switch.
If the user can fallback to not using encryption and that solves a problem they think they have, enough annoyance will make them do so. It's the entire reason HSTS exists.
afaik military and likely police radios dont talk to a central server or anything like in the world of internet. hence some things logical on the internet ate very impractical if not impossible or too risky (single points of failure).
its an interesting domain but hard to get solid info on unless you are working on these types of projects or for some MoD somewhere. most info out there on the net is about old tech.
as far as i know preshared keys are common. hard to rekey ofc in case of compromise so likely they have some tricks up their sleeves to make sure if for instance a unit is overtaken by enemy not all coms are compromised by this key in the device. (guesswork here ofc..) dont think much of this stuff uses priv/pub keys and https or vpn like auth schemes etc.
Pre-shared, static keys are unfortunately quite common. However, the P25 standard does provide for re-keying over they air through a process known as OTAR (Over The Air Re-keying).
To put it very simply, radios communicate with a central Key Management Facility (KMF) using a special key (UKEK, Unique Key Encryption Key) to securely transport the new key material. There's more to it than that, of course, but these features are heavily used by the feds and also by larger state and local systems -- because manually re-keying each radio is a huge pain.
First you need to make darn triple check extra sure that when you deploy it, you won't change it. It is a one-shot switch and whoever gets to your site is stuck with the configuration for days, weeeks, months. And you cannot tell them "my bad, try again".
Then if you have a sensible setup, you would redirect immediately to HTTPS anyway.
Sure, it protects you from some marginal risks (such as you not setting your cookies to secure mode) but then you have other problems and HSTS will bite you when you prod the security settings without a good plan.
Allow me to speculate massively. Hiss sounds more like weak signal acquisition. Perhaps in this case, Mitnick was interfering but not defeating encryption.
A bit more from the book (which is a great read, and available in it's entirety on archive.org):
"To enable its agents to communicate over greater distances, the government had installed “repeaters” at high elevations to relay the signals.
The agents’ radios transmitted on one frequency and received on another; the repeaters had an input frequency to receive the agents’
transmissions, and an output frequency that the agents listened on. When I wanted to know if an agent was nearby, I simply monitored the signal
strength on the repeater’s input frequency.
That setup enabled me to play a little game. Whenever I heard any hiss of communication..."
Properly encrypted data is indistinguishable from random noise - aka ‘hiss’. If really good encrytion, it will be white noise (generally). Albeit will have more power.
If there is a clear pattern to it, then that’s either unencrypted framing, or bad encryption. (Think 90’s cable TV ‘scrambling’).
Not really true on modern digital radio systems. They are AES-256, but the voice frames are encrypted right after the vocoder does its thing, then the voice data is dropped into the stream just as if it were clear voice. It's all wrapped in the same same digital protocol (like P25 or numerous others), so the signal is very distinct in that encrypted and clear communications both sound the same to someone listening to the raw audio.
Yes, but the interference was exactly the point. He didn't have to break the encryption in the sense of cryptanalysis or finding the key, he just had to make them think it was malfunctioning so they'd switch it off and he could listen at will
