Considering how much progress that has been made in encrypting internet traffic radio seems painfully slow in evolving to be more secure.
Edit: specifically radio protocols not carrying internet traffic
Edit: specifically radio protocols not carrying internet traffic
An important reason that I see is because (at least in Germany, I guess worldwide) ham radio operators are not allowed to encrypt their traffic. Commercial companies are a lot more conservative concerning encryption than "hacker people".
I guess it's because it would eliminate the possibility of collaboration and also enable using it for commercial purposes without anyone being able to check.
There's an exception for command and control systems like satellite control.
As we all learned in WWII, a code is better than encryption when you need complex PKI to achieve encryption. It’s more flexible, and can even convey nuances not intended. Ah, sorry I mean a language, not a code. But still, code words and phrases are still a thing.
>As we all learned in WWII, a code is better than encryption when you need complex PKI to achieve encryption
I was never in WWII and I'm not sure what you mean by code as typically that's just encryption but less formalized.
Radio is like being able to packet sniff (and modify) packets from anywhere.
Edit to add: yes, there are CA's to sign the bits on a network. There is no CA for the radio, only proprietary ones. These can be reverse engineered, subpoenaed, or bought by state actors. Chances are, if you're broadcasting loud enough to be heard by them, they're going to start listening.
This is because the MITM will not have a valid certificate to provide authenticity for the public key returned.
The reason why middle boxes in corp networks can MITM is because the the corp owns the device and has installed their own domain trust to the device. This means the MITM can return a cert and public key that your device will trust. This is because the cert returned will be signed by the installed domain trust.
Another way to think about why HTTPS is secure over radio: HTTPS is at the highest level of the OSI networking model. You could do HTTPS with pen and paper and the mail if you wanted. Think about starlink! The internet today is literally going over radio waves.
This is likely why there isn't progress on encrypting old fashion radios! There is no need to encrypt old fashioned radios -- you'll just use internet over radio instead if you wanted encryption.
You bring a good point through. Since it's radio, anyone can jam your transmissions, but, they won't be able to spoof your intended friend if you are using https via radio.
There is absolutely nothing inherently secure about HTTPS without a secure CA.
This could be done with radio too but we don’t because a typical website transfers hundreds of megabytes and the traffic involved in negotiating an encrypted connection is a drop in the bucket, whereas with most radio traffic, it would comprise a much higher percentage of all your radio traffic.
Plus your average radio equipment has a tiny CPU (although this is changing) whereas your phone or desktop computer has hundreds of gigaflops to do all the encryption and decryption math that you want and then still draw a gif.
Https (or IP for that matter) does not use the physical card to authenticate. That wouldn't make sense, except for very local networks. And since IP relies on ARP for the physical network addreess, even local IP networks can suffer MITM, by way of ARP spoofing.
At the beginning of the connection, you must establish some sort of "trust" between your radio and the other radio (if you want to use encryption). Your wifi does this with a Pre-Shared Secret (PSK). Your https connection does this with CA certificates.
This 'baseline trust' allows you to know the other end is who you expect it to be. With traditional radios, there's not much of that. There's just:
- something you have (the radio characteristics)
- something shared (past experiences/conversations)
- something you are (your voice)
If you don't squint that hard, that's the basis of any kind of authentication. Thus we have that covered. So, I can "authorize" myself as my person. Then I can send my keys over the air so we can have a private conversation.
Here's the issue, as soon as I broadcast my keys, someone with a "louder" (technically, brighter) radio broadcasts my voice with different keys. Next, they do the same thing when you broadcast your keys. Bam, we've been MITM'd without even realizing it.
So, ok, you say. Maybe we'll snail mail our keys to each other. Sure, that'll work. Yet still, even then, we'd only be able to talk to each other. At that point, why not just pick up a phone or start up a telegram chat?
The weakest link in any kind of encryption is always during the key exchange. Always. Mostly because we are human... we click through warnings, get our mail stolen, misstype things, and all kinds of dumb things.
My other point about code: we can agree on a dictionary. It's virtually uncrackable and fluent to have a coded conversation. For example, there's 0% chance you'd have any idea what this actual phrase from Afganistan means:
"the dust is blowing in, so we'll need about 5 mins to pick up my sister and head home"
spoiler:
"the americans are here, so we'll need about 5 mins to set up the guns and be the rendezvous."
Code is always better than encryption. Always. The issue is the "dictionary" and the fact that it can be leaked. Encryption gives better guarantees in that regard. But when you already have 'authentication and authorization' via the things I mentioned above, code does quite well...
Basically you are taking a subset of encryption using only substitution and calling that a code.
Cipher: exchanging letters to hide a message.
Code: exchanging words/phrases to hide a message.
Encryption: combining math + ciphers (sometimes code too!) to hide a message.
Codes are great for real people having fluent conversations, not so great for computers. We actually use "codes" all the time, but when they're used in large groups (and not a 'secret'), we call it "jargon."
"Push it to main, and I'll pull it in to my buggy branch to see if that works" will make almost no sense to anyone but a programmer who works with git and even then, only someone who's used git since everyone renamed the 'master' branch to 'main.'
So they developed a vocabulary of 411 Navajo words to stand for common military terms. E.g., BESH-LO, which is Navajo for "iron fish", meant "submarine".
The vocabulary included a phonetic alphabet to represent the 26 English letters. E.g., the three Navajo words MOASI, TLA-GIN, and BA-GOSHI all represent English words beginning with C (cat, coal, cow). So, they could spell out arbitrary English words not in their vocabulary.
It was secure against an enemy that lacked Navajos and probably didn't even know what language was being spoken or if they were intercepting some weird form of audio scrambling. But, if the Japanese had been able to translate the messages to English, the code would probably not have survived cryptanalysis for long.
https://www.cia.gov/stories/story/navajo-code-talkers-and-th...
However it sounds like they were mainly used in heavy combat conditions where the enemy didn't have recording equipment for later analysis. So in that scenario specifically (but in that alone) it was pretty secure.
If you've ever gone to a foreign country, you know you will have zero idea what anyone is saying for quite a long time. They knew as long as they kept the messages short enough, nobody was going to learn it from immersion.
There are still ancient languages that nobody have deciphered, despite having copious samples to choose from. I don't think it's as simple as you're making it out to be.
Not since 1976.
Ultimately it boils down to you needing to bootstrap your web/chain of trust somehow. In a military it might be easier; radios would be distributed to field troops with the needed trusted keys already present.
But more "public" radio? We don't have a sort of "radio CA", and there are no radios that know how to deal with such a thing. I suppose we could reuse the TLS CAs, though, and build SDRs to use it, which wouldn't rely on any particular hardware. But the point is that this just isn't set up at all.
https://www.history.navy.mil/content/dam/museums/nmas/educat...
It's very easy to look these things up.
We switched to Disney+ at the start of the year, otherwise I'd have been able to confirm the show.
Modern radios sync their keys when they are within range of wifi at HQ.
Also, see: https://www.cbc.ca/news/canada/toronto/toronto-police-tow-tr...
I do think that encryption is firmly outside of the amateur culture in most cases, but legality is well covered here: https://www.n5dux.com/ham/files/pdf/Data%20Encryption%20is%2...
I mean, in a sense it was - you're trying to make thing with long runs of patterns look as much like noise as possible, which is the goal of encryption - but in order for it to work as a modem both ends have to have the same "key" which was a very short LFSR that would pull into sync during the training burst.
In practice, at least in the UK, you can more-or-less do what you like as long as you're not making a nuisance of yourself. You literally cannot pay Ofcom to investigate anything on the amateur bands, although you might get a lot of grumbling from daft old bastards.
Also, do bear in mind that most people don't need to care what the FCC says, or stick to their rules. I'm currently operating equipment that quite thoroughly violates FCC rules, and there's not a thing anyone can do about it :-D