
Ask HN: Good Resources on Voice Encryption? - quotz
Any textbooks, very technical stuff is recommended. Both, VoIP and Cellular networks.
======
pjc50
GSM is this:
[https://en.wikipedia.org/wiki/A5/1](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.

~~~
daneel_w
Is it wise to recommend GSM's encryption today, given that it has been
completely and definitively broken?

------
cfstras
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...](http://mumble-
protocol.readthedocs.io/en/latest/voice_data.html)

------
femto
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](https://www.etsi.org/technologies/mobile-radio)

------
aosaigh
What exactly are the challenges of voice encryption over say text encryption?
Just the bandwidth of data, or establishing trust?

~~~
corty
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".

~~~
t-writescode
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.

~~~
corty
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.

~~~
beagle3
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.

~~~
corty
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.

------
bhaavan
[https://www.gstatic.com/duo/papers/duo_e2ee.pdf](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.

------
withinboredom
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/](https://bestcellular.com/dial-
codes/)

~~~
izacus
> 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.

~~~
withinboredom
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.

~~~
bladegash
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.

~~~
hnanon1
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.

~~~
bladegash
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.

------
giantg2
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.

~~~
kawfey
This is the opposite of what they should do. Encryption is verboten on amateur
radio.

~~~
giantg2
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-
intention-thats-not/)

~~~
jrockway
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.

~~~
JohnStrangeII
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.)

~~~
giantg2
Yep. There are some manufacturers that offer AES 256 encryption capable
encryption too. I think that's still generally secure.

~~~
giantg2
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.

~~~
JshWright
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.

~~~
giantg2
Yeah, I guess the algorithm is secure but how it's implemented may not be. I
think the NSA was involved with at least some radio manufacturers
implementation, so there could be a backdoor.

------
daneel_w
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.

------
tenebrisalietum
If you want to start at the very beginning, look into SIGSALY.

[https://en.wikipedia.org/wiki/SIGSALY](https://en.wikipedia.org/wiki/SIGSALY)

