Hacker News Reader

Comment by aosaigh | Hacker News Reader

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

View on HN

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

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.

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.

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

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.

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.

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

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.

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?

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

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/

Reply on news.ycombinator.com