Well, you can, it’s just a stupendously bad idea; but it also depends on the encryption used.
To take an example from my own expertise, WEP, or “wired equivalent protection” (ironic name), was based on a temporal cipher. Which means every transmission would rotate the encryption to avoid any kind of eavesdropping. WEP specifically had a lot of flaws that were found and it’s now basically useless due to the design of how it initialized the exception (also know as initialization vectors or IV’s), but the idea behind doing that was sound.
Modern SSL, or more specifically TLS scription frequently uses AES keys. It’s all well defined by PKI, so I’m really not going to say anything new here, but it uses a large (usually 2048-4096 bit) static, but asymmetric key pair, where one side can decrypt the information encrypted by the other key, and vice versa. In secured HTTP, this is used to generate a session key, which is usually much shorter, commonly AES-256 (256bit) which can both encrypt and decrypt the same data, aka a symmetric key. The client downloads one of the keys from the key pair from the target site, known as the “public key”, which is used to encrypt the seed for the AES symmetric cipher, and send it to the site, which uses the other key, known as the “private” key, to decrypt it and start the symmetrical encryption session.
The key is thrown away after a timeout, or at the end of the season, whichever comes first. It’s done this way with computers because the asymmetric keys are generally very computationally intensive, while symmetrical keys are far less computationally intensive. They’re also less secure due to the relatively short length of the key.
Asymmetrical keys usually have a validity of a year, and symmetrical keys generally have a validity measured in hours (actual length may change from connection to connection).
When it comes to the radios I’ve worked with, AES is a valid option for encryption. And using an AES key with the radio, both sides generally get the same key (a symmetric key), so you can subscribe as many radios to the same channel as you need. Again, symmetrical keys are generally fairly short, so swapping them out regularly is required.
If a bad actor gets ahold of the AES key in use, or can otherwise guess/brute force the key, they can eavesdrop.
Bearing on mind that my understanding of this encryption is based on my experience with commercially available civilian radios. Radio units used for encrypted military or government likely has superior encryption types and methodologies compared to what I have access to, and using temporally bound ciphers would not be an impossibility. When the cipher is regularly changing automatically, in the case of a temporal cipher, breaking it becomes far more unlikely and may prove impossible with current technology since you wouldn’t be able to collect enough information during a keys lifetime to reliably predict what the next cipher will be (unless that information is encrypted using the in-use cipher).
To me, it’s conceivable to use a rotating cipher based on a temporally changing seed which only the radios which have been programmed with the temporal seed would be able to determine, similar to how TOTP works (the six digit codes from apps like authy or Google authenticator), which would be used to generate the next key based on the current time and the temporal seed. No over the air transmission of the ciphers would occur. You could break each key individually by brute force, but doing so would consume an insane amount of computing power and time, making such an effort extremely impractical.
I’m not fully up to date on what ciphers are in common use in commercial/military radios, since I am not a professional radio operator, nevermind one that would require such elaborate encryption.
The fact remains that while extremely impractical, to the point of being insane to try, almost all digital encryption can be brute forced. WEP was broken by a handful of fundamental issues in the original design. Modern WiFi encryption is usually vulnerable to someone basically using a table of guesses to find the passphrase (also known as a rainbow table). Even without all that, deciphering any encrypted bitstream only requires an understanding of the cipher in use, and enough time and effort to try every permutation possible of the cipher key.
Given that cipher keys are quite long, at least 256 bits, even with a very powerful computer, or cluster of powerful computers, it would still take a very long time to brute force the code. Nevertheless it is possible.
Well, you can, it’s just a stupendously bad idea; but it also depends on the encryption used.
To take an example from my own expertise, WEP, or “wired equivalent protection” (ironic name), was based on a temporal cipher. Which means every transmission would rotate the encryption to avoid any kind of eavesdropping. WEP specifically had a lot of flaws that were found and it’s now basically useless due to the design of how it initialized the exception (also know as initialization vectors or IV’s), but the idea behind doing that was sound.
Modern SSL, or more specifically TLS scription frequently uses AES keys. It’s all well defined by PKI, so I’m really not going to say anything new here, but it uses a large (usually 2048-4096 bit) static, but asymmetric key pair, where one side can decrypt the information encrypted by the other key, and vice versa. In secured HTTP, this is used to generate a session key, which is usually much shorter, commonly AES-256 (256bit) which can both encrypt and decrypt the same data, aka a symmetric key. The client downloads one of the keys from the key pair from the target site, known as the “public key”, which is used to encrypt the seed for the AES symmetric cipher, and send it to the site, which uses the other key, known as the “private” key, to decrypt it and start the symmetrical encryption session.
The key is thrown away after a timeout, or at the end of the season, whichever comes first. It’s done this way with computers because the asymmetric keys are generally very computationally intensive, while symmetrical keys are far less computationally intensive. They’re also less secure due to the relatively short length of the key.
Asymmetrical keys usually have a validity of a year, and symmetrical keys generally have a validity measured in hours (actual length may change from connection to connection).
When it comes to the radios I’ve worked with, AES is a valid option for encryption. And using an AES key with the radio, both sides generally get the same key (a symmetric key), so you can subscribe as many radios to the same channel as you need. Again, symmetrical keys are generally fairly short, so swapping them out regularly is required.
If a bad actor gets ahold of the AES key in use, or can otherwise guess/brute force the key, they can eavesdrop.
Bearing on mind that my understanding of this encryption is based on my experience with commercially available civilian radios. Radio units used for encrypted military or government likely has superior encryption types and methodologies compared to what I have access to, and using temporally bound ciphers would not be an impossibility. When the cipher is regularly changing automatically, in the case of a temporal cipher, breaking it becomes far more unlikely and may prove impossible with current technology since you wouldn’t be able to collect enough information during a keys lifetime to reliably predict what the next cipher will be (unless that information is encrypted using the in-use cipher).
To me, it’s conceivable to use a rotating cipher based on a temporally changing seed which only the radios which have been programmed with the temporal seed would be able to determine, similar to how TOTP works (the six digit codes from apps like authy or Google authenticator), which would be used to generate the next key based on the current time and the temporal seed. No over the air transmission of the ciphers would occur. You could break each key individually by brute force, but doing so would consume an insane amount of computing power and time, making such an effort extremely impractical.
I’m not fully up to date on what ciphers are in common use in commercial/military radios, since I am not a professional radio operator, nevermind one that would require such elaborate encryption.
The fact remains that while extremely impractical, to the point of being insane to try, almost all digital encryption can be brute forced. WEP was broken by a handful of fundamental issues in the original design. Modern WiFi encryption is usually vulnerable to someone basically using a table of guesses to find the passphrase (also known as a rainbow table). Even without all that, deciphering any encrypted bitstream only requires an understanding of the cipher in use, and enough time and effort to try every permutation possible of the cipher key.
Given that cipher keys are quite long, at least 256 bits, even with a very powerful computer, or cluster of powerful computers, it would still take a very long time to brute force the code. Nevertheless it is possible.
It’s insane to try, but it’s still possible.