Ask HN: Good Resources on Voice Encryption?
Any textbooks, very technical stuff is recommended. Both, VoIP and Cellular networks.
57 comments
GSM is this: https://en.wikipedia.org/wiki/A5/1 (over the AMR codec). The 3GPP docs are generally available if you want to get very, very technical about the mobile network.
Generally any combination of a constant-bitrate low-latency voice codec with a cipher in XOR stream mode should work. If the codec does "comfort noise" you should disable that to keep the bitrate constant during silence.
Generally any combination of a constant-bitrate low-latency voice codec with a cipher in XOR stream mode should work. If the codec does "comfort noise" you should disable that to keep the bitrate constant during silence.
Is it wise to recommend GSM's encryption today, given that it has been completely and definitively broken?
Do you mean stream mode per packet or per connection? When dealing with voice encoding you need to ensure each packet is self contained and you can drop seconds of traffic without issues. They means the naive application of steam ciphers won't work.
The mumble protocol
is a nicely documented example for using encrypted Opus (OCB-AES128) over UDP:
http://mumble-protocol.readthedocs.io/en/latest/voice_data.h...
Look at some of the narrow band radio standards. P25 standards are not freely available, but DMR standards can be freely downloaded from ETSI [1]. P25 with 56-bit DES is well and truly broken, but I gather 256-bit AES is still okay. Also look at the signal protocol?
[1] https://www.etsi.org/technologies/mobile-radio
[1] https://www.etsi.org/technologies/mobile-radio
What exactly are the challenges of voice encryption over say text encryption? Just the bandwidth of data, or establishing trust?
Voice compression interacts unfavourably with general-purpose encryption because one can still infer periods of silence and distinguish low-complexity sounds from high-compexity ones. A rolling "r" compresses badly, a long featureless vowel compresses well. That way you can infer all kinds of information about whats being said, who is saying it, language, reaction, pauses, etc.
So for voice encryption, you need to obscure all that through artificial jitter and noise, and lack of compression in strategic places. It is a complex topic and I'm not sure the science is settled beyond "skipping compression helps".
So for voice encryption, you need to obscure all that through artificial jitter and noise, and lack of compression in strategic places. It is a complex topic and I'm not sure the science is settled beyond "skipping compression helps".
With good encryption, a file full of zeros should be indistinguishable from a file full of data.
There is something to be said about the volume of data being sent during silence; but, uncompressed audio shouldn't have that problem; and, for audio that does, there could be filler data to maintain a given bitrate across the line.
There is something to be said about the volume of data being sent during silence; but, uncompressed audio shouldn't have that problem; and, for audio that does, there could be filler data to maintain a given bitrate across the line.
But the point of compression is, you wouldn't transmit a bunch of zeroes. You would transmit "here go 285 zeroes" or "here go 403ms silence". Which is far less data than the equivalent time in non-silence.
Really transmitting the zeroes as they are is just transmitting uncompressed PCM, which is the trivial solution. Adding filler is undoing most of the compression. The hard part is to add just enough filler, jitter and confusion for an attacker to be sufficiently blinded while maintaining an acceptable compression ratio.
Really transmitting the zeroes as they are is just transmitting uncompressed PCM, which is the trivial solution. Adding filler is undoing most of the compression. The hard part is to add just enough filler, jitter and confusion for an attacker to be sufficiently blinded while maintaining an acceptable compression ratio.
Basically all audio codecs meant for real time communication are built to maintain constant but rate — because even though it is nice to save a few bits occasionally when you can, you can’t use present silence to encode future speech (you haven’t heard it yet...);
So, no. The filler is part of the protocol and is not undoing any of the PCM compression; silence would let you compress the stream more than the plain voice codec would - and THAT would interact with encryption. But that’s quite unusual for real time systems.
So, no. The filler is part of the protocol and is not undoing any of the PCM compression; silence would let you compress the stream more than the plain voice codec would - and THAT would interact with encryption. But that’s quite unusual for real time systems.
Not really. Silence is encoded with silence frames containing just a length of silence marker in most VoIP protocols. On the receiving end, silence frames are then filled with "comfort noise". If you pay attention and have a crappy phone you can hear this, because the comfort noise generator will produce noticably different "silence".
Yes, one often does CBR, but even there, variable difficulty of compression often produces variable jitter, which can then be used to infer information about the plaintext stream. There are constant runtime CBR codecs, but one has to take care to use them.
Yes, one often does CBR, but even there, variable difficulty of compression often produces variable jitter, which can then be used to infer information about the plaintext stream. There are constant runtime CBR codecs, but one has to take care to use them.
> Adding filler is undoing most of the compression.
Really? Would I not just get a not quite constant stream of (unencrypted) data that‘s small enough to send at a low bandwidth? And when that data arrives at less than the maximum bandwidth of the channel that I actually use, I just add some filler. And then I encrypt that now really constant stream of data.
Really? Would I not just get a not quite constant stream of (unencrypted) data that‘s small enough to send at a low bandwidth? And when that data arrives at less than the maximum bandwidth of the channel that I actually use, I just add some filler. And then I encrypt that now really constant stream of data.
I’ve seen a similar narrative to that, I believe the story was that you have to packetize and normalize the audio on entropy before encrypting it.
Says if you don’t and simply XOR an audio with PRNG output, the resultant entropy will not be constant and transmission sounds like a noisy radio. Something like that.
Says if you don’t and simply XOR an audio with PRNG output, the resultant entropy will not be constant and transmission sounds like a noisy radio. Something like that.
[deleted]
[citation needed] on these techniques, versus just using constant-bitrate mode?
Some codecs also offer an "Adaptive" bitrate mode. In that mode the codec can vary the bitrate but never in response to audio input.
So e.g. maybe you're doing 48kbps, the codec would still consume 48000 bits per second for silence. However if a radio link layer indicates it's struggling to move 48000 bits per second that "adaptive mode" audio codec could shift down to 36kbps instead. This is likely to be a much better user experience than throwing away 25% of your compressed audio due to packet loss and then trying to reconstruct it.
For something like Opus you can gracefully degrade this way from 48kbps (transparent for voice) to 8kbps (non-transparent but easily understandable) without an eavesdropper learning anything about the content, they only get insight into whether you've got link trouble.
So e.g. maybe you're doing 48kbps, the codec would still consume 48000 bits per second for silence. However if a radio link layer indicates it's struggling to move 48000 bits per second that "adaptive mode" audio codec could shift down to 36kbps instead. This is likely to be a much better user experience than throwing away 25% of your compressed audio due to packet loss and then trying to reconstruct it.
For something like Opus you can gracefully degrade this way from 48kbps (transparent for voice) to 8kbps (non-transparent but easily understandable) without an eavesdropper learning anything about the content, they only get insight into whether you've got link trouble.
So wouldn't you just go with a constant bit rate compression algorithm like what's done for video? It's not like audio can't be lossy outside of fax over VoIP.
Managing latency is a problem, as you can only encrypt fairly short packets at a time and send each one out, rather than the whole message, and the structure of the data being different can lead to information leakage
Interesting.
I haven't tried, but I'd think encrypting and decrypting a packet would take less than 0.1ms, no?
What's the variation in the structure of the data? Wouldn't you just encrypt and send a fixed-length interval of audio each period?
I haven't tried, but I'd think encrypting and decrypting a packet would take less than 0.1ms, no?
What's the variation in the structure of the data? Wouldn't you just encrypt and send a fixed-length interval of audio each period?
From a modern point of view it's not a challenge.
Historically voice encryption was politically only meant for state use, with strict controls, and us plebs not getting any voice encryption or very weak encryption only. Compared to encryption on the internet, this state has persisted for longer in communications. Even in new communication standards the options for encryption generally offer weak/irrelevant security for modern standards (end-to-end encryption).
Historically voice encryption was politically only meant for state use, with strict controls, and us plebs not getting any voice encryption or very weak encryption only. Compared to encryption on the internet, this state has persisted for longer in communications. Even in new communication standards the options for encryption generally offer weak/irrelevant security for modern standards (end-to-end encryption).
Also with telephony applications, you should encrypt your signaling layer even before any media codecs get involved so there is that to consider.
I haven't tried, but I'd think encrypting and decrypting a packet would take less than 0.1ms, no?
What's the variation in the structure of the data? Wouldn't you just encrypt and send a fixed-length interval of audio each period?
check out this article https://apkwind.com/netflix-mod-apk/
What's the variation in the structure of the data? Wouldn't you just encrypt and send a fixed-length interval of audio each period?
check out this article https://apkwind.com/netflix-mod-apk/
[deleted]
https://www.gstatic.com/duo/papers/duo_e2ee.pdf is a paper on video encryption by duo. It is pretty good. I assume the audio encryption problem is only a subset of this problem.
I remember being on the old Sprint CDMA network, you could dial ##VPON# and it would encrypt your connection to the tower[1] but was disabled by default. Dunno if that still works (I no longer live in the US, and EVDO isn't a thing anymore).
I'm fairly certain Cell networks are not encrypted at all, by default. Or at least it's disabled completely by the towers in Afghanistan. :whistling:
[1] https://bestcellular.com/dial-codes/
I'm fairly certain Cell networks are not encrypted at all, by default. Or at least it's disabled completely by the towers in Afghanistan. :whistling:
[1] https://bestcellular.com/dial-codes/
> I'm fairly certain Cell networks are not encrypted at all, by default. Or at least it's disabled completely by the towers in Afghanistan. :whistling:
This is patently false, while some networks did allow no encryption (A0 on GSM for example), pretty much everything on UMTS/LTE is encrypted at least to the tower.
This is patently false, while some networks did allow no encryption (A0 on GSM for example), pretty much everything on UMTS/LTE is encrypted at least to the tower.
Yeah, not sure how we flew around and listened to cell conversations in realtime. Dunno if we just had the keys, encryption was disabled or the device was operating as a MITM tower.
GSM encryption is also pretty broken, e.g.
> In 2006 Elad Barkan, Eli Biham and Nathan Keller demonstrated attacks against A5/1, A5/3, or even GPRS that allow attackers to tap GSM mobile phone conversations and decrypt them either in real-time, or at any later time
https://en.wikipedia.org/wiki/A5/1
> In 2006 Elad Barkan, Eli Biham and Nathan Keller demonstrated attacks against A5/1, A5/3, or even GPRS that allow attackers to tap GSM mobile phone conversations and decrypt them either in real-time, or at any later time
https://en.wikipedia.org/wiki/A5/1
I assume, depending on your aircraft, it was your dirtbox putting out a stronger signal operating as a MITM.
Not to be a jerk, but this seems like a really inappropriate venue to discuss operational details like this. Especially capabilities/vulnerabilities that, if they do exist, would be classified and concerning a location where the US still conducts military operations.
None of the above is classified, to my knowledge. A quick google search of this capability returns https://en.wikipedia.org/wiki/Stingray_phone_tracker
The techniques are not classified, although LE fought tooth and nails to keep details out of court cases for years. IMO, the state doesn't have the right to even keep it non-public.
I recommend looking up Executive Order 13526 and the differences between a state’s ability to classify information vs. the Federal government’s. Also recommend taking a look at the elements for doing so. Lastly, I would also take a look at SF-312 and the commitment those with access to classified information make. Outside of that, I’m not going to go into this further.
I don't have anything specific.
You could look for resources that cover digital HAM radio operation. They should have some stuff about the basics of voice encryption. Most of it is not secure until you get to high-end stuff like Motorola AES 256. Some of this 'encryption' is just privacy codes (cell networks are not encrypted but use digital privacy codes I think).
Once you digitize the voice, then it should be pretty much regular encryption.
You could look for resources that cover digital HAM radio operation. They should have some stuff about the basics of voice encryption. Most of it is not secure until you get to high-end stuff like Motorola AES 256. Some of this 'encryption' is just privacy codes (cell networks are not encrypted but use digital privacy codes I think).
Once you digitize the voice, then it should be pretty much regular encryption.
This is the opposite of what they should do. Encryption is verboten on amateur radio.
Like I said, most of it is not true encryption but privacy codes or digital talk group settings. Encryption does happen on amatuer radio even though it's supposed to be illegal. I'm not recommending they use encryption in this fashion, but that there are some resources out there which describes how it works.
https://www.amateurradio.com/encryption-is-already-legal-its...
https://www.amateurradio.com/encryption-is-already-legal-its...
The author of this article does not know what encryption is. He's mad that proprietary audio codecs can be used on amateur radio bands, but the codecs are documented in the patent applications (since expired) so no encryption is occurring. It's like not knowing that you need an MP3 player to listen to MP3s. That's not encryption, that's not having an MP3 player.
In the context of HAM radio transmissions, encryption includes voice scrambling methods that we wouldn't nowadays consider secure encryption. There used to be a lot of analogue voice scramblers and voice inversion tools. I think you can still buy them. Generally, there is a prohibition against obscuring transmissions on HAM radio. (Or at least I think so, I'm not a HAM operator myself.)
Yep. There are some manufacturers that offer AES 256 encryption capable encryption too. I think that's still generally secure.
Why is this downvoted? Kenwood is one of the manufactures that has AES 256 radios capable of transmitting in the ham bands. NIST still considers AES 256 secure.
Not sure why it was being downvoted, but saying "AES 256" is secure is both true and meaningless. It's a low level building block of cryptosystems, and there are countless examples of AES based systems being compromised because the system built around it had flaws.
Random pedantry... Ham is not an acronym, so it isn't capitalized.
How would you define encryption? I would say it's encoding of information so that unauthorized people are less likely to have access to the information .
Like I said in my original post, you can look into encryption in the amatuer bands. This article is one example. If you've taken encryption courses then you know that XOR can be a cipher, it's just not secure. The same way a lock on your shed is only going to keep curious people out and not real criminals, the same can be said for lesser forms of encryption.
Please look into Kenwood AES/DES models that operate in the VHF/UHF amatuer bands if you still have any doubts about the use of encryption. There are various 40, 56, etc bit encryption schemes as well.
Like I said in my original post, you can look into encryption in the amatuer bands. This article is one example. If you've taken encryption courses then you know that XOR can be a cipher, it's just not secure. The same way a lock on your shed is only going to keep curious people out and not real criminals, the same can be said for lesser forms of encryption.
Please look into Kenwood AES/DES models that operate in the VHF/UHF amatuer bands if you still have any doubts about the use of encryption. There are various 40, 56, etc bit encryption schemes as well.
Encrypted communication is communication that is indecipherable if you know the encryption algorithm but don't have the key material. Not knowing the algorithm is a separate thing. In the case of D-STAR, the algorithm is well known, it's just not analog FM. People with FM receivers would be just as upset to hear two people talking with SSB or CW, both perfectly legal on VHF.
Over on HF, digital modes like FT8 are quite popular. You will never be able to decode that without a computer, but that doesn't make it illegal (or encrypted). The algorithm is well defined and it's ~100x more bandwidth efficient than SSB voice.
Kenwood sells AES radios for non-amateur communications. It's perfectly legal for non-amateur licensees to encrypt their radio links. Your cell phone is doing it right now!
Yes, you can use those on the amateur bands if you want. It's against the rules. The reason amateur radio exists is because we follow the rules. It can all disappear overnight if you violate them. There are a few well-known bad apples that make it harder for all of us. It's not to be encouraged.
Over on HF, digital modes like FT8 are quite popular. You will never be able to decode that without a computer, but that doesn't make it illegal (or encrypted). The algorithm is well defined and it's ~100x more bandwidth efficient than SSB voice.
Kenwood sells AES radios for non-amateur communications. It's perfectly legal for non-amateur licensees to encrypt their radio links. Your cell phone is doing it right now!
Yes, you can use those on the amateur bands if you want. It's against the rules. The reason amateur radio exists is because we follow the rules. It can all disappear overnight if you violate them. There are a few well-known bad apples that make it harder for all of us. It's not to be encouraged.
> In the case of D-STAR, the algorithm is well known, it's just not analog FM
For a long time the audio codec was only available in a chip (technically a readout protected microcontroller). There are patents on the audio codec, but they didn't disclose enough of it to decode it, only enough to make it unlawful for other people to publish compatible implementations (which, of course, kept the resources available for reverse engineering low).
For a while I contemplated selling bespoke custom versions of Opus as a bit of performance art under licensing where the first copy cost $500 and all further copies cost $1,000,000 with some marketing copy about keeping lids off your repeaters. ... just to see how the FCC would react.
Considering that they let AMBE use get away with it, as the old joke goes: We've already established what kind of licensing regime they'll permit-- pay to access encrypted audio-- my performance art differed only by the price.
:)
> The reason amateur radio exists is because we follow the rules. It can all disappear overnight if you violate them. There are a few well-known bad apples that make it harder for all of us. It's not to be encouraged.
Personally, particularly on bands above 70cm, I think the prohibition against encryption is killing amateur radio. The lack of encryption for signals that would be naturally point to point anyway and disturb no one inhibits a lot community use, and the relative non-usage of these allocations risks use losing them.
I'd much rather see a rule that allowed encryption on 33cm+ subject to the constraint that stations have to be identified, non-profit in nature, cooperate with local coordination, and act as secondary users to non-encrypted uses.
For a long time the audio codec was only available in a chip (technically a readout protected microcontroller). There are patents on the audio codec, but they didn't disclose enough of it to decode it, only enough to make it unlawful for other people to publish compatible implementations (which, of course, kept the resources available for reverse engineering low).
For a while I contemplated selling bespoke custom versions of Opus as a bit of performance art under licensing where the first copy cost $500 and all further copies cost $1,000,000 with some marketing copy about keeping lids off your repeaters. ... just to see how the FCC would react.
Considering that they let AMBE use get away with it, as the old joke goes: We've already established what kind of licensing regime they'll permit-- pay to access encrypted audio-- my performance art differed only by the price.
:)
> The reason amateur radio exists is because we follow the rules. It can all disappear overnight if you violate them. There are a few well-known bad apples that make it harder for all of us. It's not to be encouraged.
Personally, particularly on bands above 70cm, I think the prohibition against encryption is killing amateur radio. The lack of encryption for signals that would be naturally point to point anyway and disturb no one inhibits a lot community use, and the relative non-usage of these allocations risks use losing them.
I'd much rather see a rule that allowed encryption on 33cm+ subject to the constraint that stations have to be identified, non-profit in nature, cooperate with local coordination, and act as secondary users to non-encrypted uses.
> I'd much rather see a rule that allowed encryption on 33cm+ subject to the constraint that stations have to be identified, non-profit in nature, cooperate with local coordination, and act as secondary users to non-encrypted uses.
Yes, I think it is reasonable, although I don't know what bands to have that on, and of course it should not be interfering with non-encrypted uses.
(And perhaps the same rule should be applied to proprietary codecs, too, so that they don't overload the radio with proprietary codes that you cannot figure out how to decode.)
Yes, I think it is reasonable, although I don't know what bands to have that on, and of course it should not be interfering with non-encrypted uses.
(And perhaps the same rule should be applied to proprietary codecs, too, so that they don't overload the radio with proprietary codes that you cannot figure out how to decode.)
> The reason amateur radio exists is because we follow the rules. It can all disappear overnight if you violate them.
As an American this sort of sentiment is absolutely depressing to see. It seems to be incredibly common in a number of areas - radio, flight, and chemistry, to list just a few. I can only hope access to unencumbered computers doesn't fall victim to the same.
WTF happened to our supposed ideal of freedom?
As an American this sort of sentiment is absolutely depressing to see. It seems to be incredibly common in a number of areas - radio, flight, and chemistry, to list just a few. I can only hope access to unencumbered computers doesn't fall victim to the same.
WTF happened to our supposed ideal of freedom?
Standard cell phones do not use encryption. You can intercept calls if you have receivers on the right frequency and using the right tech (believe they are trunked).
I'm not advocating that they use true encryption in the ham bands, but it does exist. As I said before, there is information out there about how voice is digitized, how psuedo or weak encryption works (DMR, 40 bit, 56 bit), and then you can use standard encryption practices to encrypt it.
The OPs question was about where he can find technical info on encrypting voice communications and I said this would be a good starting point. This is a valid contribution to his question. I am sorry if you do not believe that weak encryption (where you know all possible keys, or the keys are small) is not encryption.
I'm not advocating that they use true encryption in the ham bands, but it does exist. As I said before, there is information out there about how voice is digitized, how psuedo or weak encryption works (DMR, 40 bit, 56 bit), and then you can use standard encryption practices to encrypt it.
The OPs question was about where he can find technical info on encrypting voice communications and I said this would be a good starting point. This is a valid contribution to his question. I am sorry if you do not believe that weak encryption (where you know all possible keys, or the keys are small) is not encryption.
> Standard cell phones do not use encryption.
Yes they do. Decades ago they didn't. Today there are devices that use active attacks to downgrade the encryption by impersonating a base station.
It's also possible to crack the encryption used by GSM, but I believe the base station impersonation attacks are much more common.
Yes they do. Decades ago they didn't. Today there are devices that use active attacks to downgrade the encryption by impersonating a base station.
It's also possible to crack the encryption used by GSM, but I believe the base station impersonation attacks are much more common.
I would suggest a basic how-to on setting up SRTP/SIPS for e.g. an Asterisk setup - it's not overly complicated, based on my own experience running a community PBX many years ago.
If you want to start at the very beginning, look into SIGSALY.
https://en.wikipedia.org/wiki/SIGSALY
https://en.wikipedia.org/wiki/SIGSALY