okay this is way over my head - but this would have to be steganography hiding in the audio file that could only be run by someone like OP, detecting; downloading; etc the udp data, right?
Today (but perhaps slightly less in 2016, not sure) you could easily imagine a microcontroller (or FPGA) with a microphone that bugs you, but encodes that audio (using steganography) onto a canned audio file of elevator music, and then sends the result over the network "in the open".
To a casual observer snooping the relevant network, it would probably (as here) look as elevator music, but to the intended recipient who can decode the steganography, it would be a covert listening device.
Even better than a canned audio file would be machine generated music. Otherwise you could detect that the “same” song is being transmitted with slightly different bits.
Or you could have an extremely long audio file so the repeat situation doesn’t occur.
There's a very simple way around this. Grab any encoding that uses a dictionary, like, I think zip does. Sent tiny zip files with an excerpt of a .wav file or something that needs to be compressed.
The decompressed data is always the same, but the data in the dictionary used is where you store your sneaky bits.
Sure, that's still mildly suspicious. But way less than the actual music data changing all the time.
You could also hide the bits in eg timing of package transmission or omiting an expected package every once in a while, it'll just look like udp dropped a package.
You can use a channel with lots of noise, because you can use error correcting codes to to restore the intended message.
(To elaborate with an example: sometimes a package might already drop randomly, or timings might be slightly delayed anyway.)
If you have a legacy music system and encode it over the network, the data will vary— time bases wont line up, there will be noise, etc, even if it repeats.
Yeah, that's the problem. If the song is known either because its a previously published song or because it repeats then the bits should be the same every time the song is played. If you are adding extra data with steganography then you don't want it easy to detect because someone could make a steganography detector by testing if the same song's data seems to vary for no reason.
I guess you could also build an auto-auto-tune or auto-remix solution so the songs always have justifiable variation without needing fully generated music.
I know next to nothing about steganography, beyond the general concept, so please excuse my ignorance if I'm way off base, but couldn't you design the encoding system such that you could encode the same amount of data within the time frame of each loop, with only some portion of the new data containing real data (audio recording)?
This would work if the elevator music was a never-repeating stream. With most elevator music, it's a few minutes of a "song" playing on repeat 24/7, so if you recorded a few repetitions of the "song", you'd probably see also repeated packets on the network.
If the music was repeating but the stream was different all the time, then steganography could be the reason :)
Basically, you'd use steganography to hide that you send a message. And that message would be encrypted. You can use almost any standard encryption scheme, as long as you remove headers etc. Any ciphertext of a crypto-system worth its salt will be indistinguishable from random noise without the key.
