0

I'm the author of software that, among other things, records audio. I got the requirement that the audio should be encrypted or at least obfuscated before saving to disk, so that someone using conventional audio software can't just listen to the output files and hear potentially sensitive information.

So I developed an algorithm to map any byte to a different byte, using a pseudo-random mapping, and then I can unmap by mapping in reverse. The byte mapping isn't totally random, but the correlation between input bytes and output bytes is very low, around 0.1.

Visualized as numbers, this really scrambles the bytes and produces a real mess of the data. And when you apply this to an audio file and listen to the result, it sounds like garbage, which was the goal.

But, to my astonishment, during testing someone did a recording of himself speaking, and in the scrambled file, you can still hear the original audio. It's distorted a bit and there's a lot of noise, but the audio is audible.

I took the waveforms of the two audio files and superimposed them like this:

enter image description here

Despite the lack of correlation of individual bytes, there does seem to be some correlation between the original audio (the inner, lighter color) and the scrambled audio (the dark green).

What could explain this?

Improve this question

1 Answer 1

Reset to default
2

The process you are using is not going to work, as you have a one-to-one mapping of input to output. Any time you do that, patterns exist that relate to the original.

This type of algorithm has been attempted many times in various fields, and it never works to protect/obfuscate. This is why we tell security/crypto/dev folks to never roll their own crypto.

What you need to look at is the consumr level encryption built in to all operating systems these days. It will do the job way better than you can, keeping your files safe from tampering, either protected at user account level (meaning only you can access them), group level (so a group of accounts can access them) or password based (so anyone with the password can access them)

Improve this answer
2
  • I understand that you shouldn't roll your own crypto and why. But I thought the reason you don't want patterns is that a sophisticated attacker can use those patterns to reverse the encryption, which I wasn't worried about in this case. What surprises me here is that not that there are patterns, but that the plain audio remains comprehensible even under the encipherment. IOW, I get that it's bad for "one" to always map to "qzp", because someone could see that pattern. But here it's as if the bytes for "one" are mapped to "one", as measured by my ears. That's the thing I don't understand.
    – Joshua Frank
    Commented Jan 7, 2021 at 18:06
  • It's not the exact bytes in this instance, but if you think about what makes the sound, in a very simplified sense it is the transitions that are key. Your algorithm introduces a lot of noise, as you have found, but you are creating similar transitions for every input set of numbers, so the overall sound still follows the same pattern.]
    – Rory Alsop ♦
    Commented Jan 7, 2021 at 18:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.