Compressed VoIP Calls Vulnerable To Bugging
holy_calamity writes "Security researchers at Johns Hopkins report that a variable bit-rate compression scheme being rolled out on VoIP systems leaves encrypted calls vulnerable to bugging. Simpler syllables are squeezed into smaller data packets, with more complex ones taking up more space; the researchers built software that uses this to spot phrases of interest in encrypted calls simply by measuring packet size."
Anyone wanting to avoid detection could just follow what my German-speaking grandparents do when they don't want us kids listening into the conversation: randomly switch languages on different topics (though I think that this is sometimes also because some concepts are also easier to portray in a given language).
:-)
Random switches between languages would probably confuse the heck out of filters guessing compressed data. That or you could just learn Russian... I don't think they *have* any simple-syllable words in Russian
Just st-st-stuh-stutter when you talk. And use a lot of, uh, you know, um, non-word sounds between, uh, like, your phrases. And don't use any complexificated words without Bushifying them first. Better yet, only speak in Klingon.
Or maybe you shouldn't say anything on VoIP that you don't want anyone else to hear.
steampunk web design
Voice data just CAN'T be securely encrypted. That's because the spacetime information HAS to be there because we inherently interpret voice data according to these characteristics. Either you reveal this information in the stream, or you must increase the latency to the point that communication is impossible. If you want security, don't speak, WRITE, and use a cryptosystem that isn't a piece of shit.
I disagree. The problem pointed at in this article can be easily solved on many SIP endpoints. I spend all day working on VoIP phones from vendors such as Linksys, Polycom, Aastra, Cisco, and if I really have to snom. Most of these have an option where it'll just send blank full bitrate audio rather than the usual "put silence here" instructions on G.711 calls. In fact that is the default behavior on some, since it makes the latency a bit more predictable to have a constant-rate data stream. If you want to use a VBR codec, of course this is a problem, but don't act like it's impossible or even hard to solve. If you are concerned enough to encrypt your conversations, use a CBR codec. 64 kbit/sec is not hard to free up.I used to get high on life, but I developed a tolerance. Now I need something stronger.
I bet you that phone is not packet based, not compressed, and runs over a physically secure line. BIG fucking difference.
---The people suggesting that we should just inject noise or background patterns are being ridiculous. Why sacrifice communication quality when there are BETTER ways to fix it? DO IT RIGHT.
Injecting "noise" makes sense for me. Why so?
We use a salt for our hashes, dont we? The "noise" would be the same thing. Consider this: during negotiation, we have chaotic noise formulas in which we propagate the variables so that each side knows the noise transform. We then add the noise after digitalization but before encryption. Then the other side knows the inverse formula, decrypts it, and subtracts the noise.
Given pseudo-random numbers for the chaotic noise formula, it would give different encrypted data for the same exact voice (if we used a mp3 to exactly play something). Effectively, a voice salt.
Send fixed size packets, splitting longer syllables into more packets and packing multiple short syllables into single packets.