Is there any way to prevent Deconvolution?

[nelsona]

Hello,

Assuming you were only provided a dry signal:



...and wet signal (with reverb applied to it via convolution reverb):



..is there anything I could to the dry signal and/or the impulse response (IR), to prevent someone from deriving the IR via Deconvolution?

Note: If there is something that could be done, it must be done the dry signal and/or IR before performing any convolution, not after.

Thank you,
Nelson

[nonnaci]

Transform dry signal by something unknown (and hopefully time-varying) to the user before convolving with IR. i.e. it depends on how much you can accept mangling the output.

Lets suppose dry was a unit pulse and wet would give the FIR itself. What types of transformations can be introduced to a unit pulse? Maybe variable delay / all-pass will mess with the phase but the output may be still acceptable.

[Miles1981]

In all fairness, if this is a simple convolution and you accept any input, there is nothing you can do to prevent deconvolution. It's math that allows you to do so :/

[Zaphod (giancarlo)]

Little time warp. Even a single sample could damage things

[nelsona]

Hello Miles1981,

I was under the impression that there was nothing I could do as well (as mathematically, it should be trivial to deduce the IR if you're given the dry signal and wet signal).

That said, I was hoping that maybe through the use of a specific IR, there'd be some phase cancellation in the convolution process which would make it harder to derive the IR.

But in all honesty, I have no idea.

Thank you,
Nelson

[nelsona]

Hello Giancarlo,

Keep in mind that I could only perform a time warp before performing my convolution.

That being said, I'd assume a time warp (or simply a sample adjustment), would just result in a different dry signal.

If that's the case, I don't believe a time warp would work.

Thank you for the suggestion,
Nelson

[nelsona]

Transform dry signal by something unknown (and hopefully time-varying) to the user before convolving with IR. i.e. it depends on how much you can accept mangling the output.

Lets suppose dry was a unit pulse and wet would give the FIR itself. What types of transformations can be introduced to a unit pulse? Maybe variable delay / all-pass will mess with the phase but the output may be still acceptable.

Hello Nonnaci,

I'm not certain if that would work.

For example, let's say I ran my dry signal through a saturation plugin (which would greatly mangle my audio). All it would do (in my opinion) is simply result in a new dry signal.

If we then ran our new dry signal through our IR, it would simply result in a different waveform, which I'd assume mathematically you could still derive the IR from (if you were given the new/mangled dry signal, and wet signal).

That being said, I may not be fully understanding your response.

Thank you,
Nelson

[nonnaci]

Hello Nonnaci,

I'm not certain if that would work.

For example, let's say I ran my dry signal through a saturation plugin (which would greatly mangle my audio). All it would do (in my opinion) is simply result in a new dry signal.

If we then ran our new dry signal through our IR, it would simply result in a different waveform, which I'd assume mathematically you could still derive the IR from (if you were given the new/mangled dry signal, and wet signal).

That being said, I may not be fully understanding your response.

Thank you,
Nelson

Yes. The point is that you don't expose the mangled dry signal to the end user by hiding the mangling process within a piece of code. That way, all the user sees is original dry and result of conv(mangled(dry), IR) of which mangle is difficult to reverse-engineer (e.g. all-pass filter with time-varying psuedorandom delayline).

[nelsona]

Hello Nonnaci,

I'm not certain if that would work.

For example, let's say I ran my dry signal through a saturation plugin (which would greatly mangle my audio). All it would do (in my opinion) is simply result in a new dry signal.

If we then ran our new dry signal through our IR, it would simply result in a different waveform, which I'd assume mathematically you could still derive the IR from (if you were given the new/mangled dry signal, and wet signal).

That being said, I may not be fully understanding your response.

Thank you,
Nelson

Yes. The point is that you don't expose the mangled dry signal to the end user by hiding the mangling process within a piece of code. That way, all the user sees is original dry and result of conv(mangled(dry), IR) of which mangle is difficult to reverse-engineer (e.g. all-pass filter with time-varying psuedorandom delayline).

Hello Nonnaci,

I see what you mean.

Unfortunately, that won't work in my situation as it's mandatory that both users have access to both the dry and wet signal.

So in other words, let's say there are two parties: Alice and Eve.

Whatever Alice does to her dry signal (to mangle the signal), she must provide both the mangled signal (pre-convolution) and the convolved signal to Eve.

So with the dry / mangled signal and the wet signal, can Eve figure out Alice's IR?

Currently the answer seems to be yes, but I'm hoping there's some way of making it at the very least very difficult for Eve.

Thank you,
Nelson

[nelsona]

Little time warp. Even a single sample could damage things

Hello Giancarlo,

Keep in mind that I could only perform a time warp before performing my convolution.

That being said, I'd assume a time warp (or simply a sample adjustment), would just result in a different dry signal.

If that's the case, I don't believe a time warp would work.

Thank you for the suggestion,
Nelson

[nonnaci]

Hello Nonnaci,

I see what you mean.

Unfortunately, that won't work in my situation as it's mandatory that both users have access to both the dry and wet signal.

So in other words, let's say there are two parties: Alice and Eve.

Whatever Alice does to her dry signal (to mangle the signal), she must provide both the mangled signal (pre-convolution) and the convolved signal to Eve.

So with the dry / mangled signal and the wet signal, can Eve figure out Alice's IR?

Currently the answer seems to be yes, but I'm hoping there's some way of making it at the very least very difficult for Eve.

Thank you,
Nelson

Another idea. If you're using block-convolution type algorithms, you can mangle the phase of later blocks over time that correspond with parts of the late reverb tail.

[nelsona]

In all fairness, if this is a simple convolution and you accept any input, there is nothing you can do to prevent deconvolution. It's math that allows you to do so :/

Hello Miles1981,

I was under the impression that there was nothing I could do as well (as mathematically, it should be trivial to deduce the IR if you're given the dry signal and wet signal).

That said, I was hoping that maybe through the use of a specific IR, there'd be some phase cancellation in the convolution process which would make it harder to derive the IR.

But in all honesty, I have no idea.

Thank you,
Nelson

[nelsona]

Hello Nonnaci,

I see what you mean.

Unfortunately, that won't work in my situation as it's mandatory that both users have access to both the dry and wet signal.

So in other words, let's say there are two parties: Alice and Eve.

Whatever Alice does to her dry signal (to mangle the signal), she must provide both the mangled signal (pre-convolution) and the convolved signal to Eve.

So with the dry / mangled signal and the wet signal, can Eve figure out Alice's IR?

Currently the answer seems to be yes, but I'm hoping there's some way of making it at the very least very difficult for Eve.

Thank you,
Nelson

Another idea. If you're using block-convolution type algorithms, you can mangle the phase of later blocks over time that correspond with parts of the late reverb tail.

Hello Nonnaci,

Thank you for the suggestion.

Though I'm not familiar with Block Convolution, though I've heard about it, can I assume that Block Convolution (aka Overlap-Add method of convolution) is simply a faster way at performing convolution?

If so, the mangling (or phase cancellation), would need to occur as part of the convolution itself (not afterwards).

In other words (at least for my purposes), I'd need to:

1. Start with some dry signal.
2. Perform some sort of convolution (could be linear, periodic, block etc) on my dry signal, using some IR.
3. Provide the dry signal and wet signal (ex. convolved using block convolution) to a third party, but not the IR.

And then the question becomes, would the use of block convolution (even if we were mangling the reverb tail through phase cancellation), result in a wet signal which our third party would be unable to derive our IR from?

I still think the answer is that our third party would be able to figure out our IR, but I could be wrong.

Important Question: Can I assume that by "mangling" you're referring to something like a phase cancellation? The reason I ask is that I could've sworn that phase cancellation was a by-product of convolution. If that's not the case (i.e. that convolution introduces a natural phase cancellation), that could be a very important piece of information.

Thank you,
Nelson

[nonnaci]

Hello Nonnaci,

I see what you mean.

Unfortunately, that won't work in my situation as it's mandatory that both users have access to both the dry and wet signal.

So in other words, let's say there are two parties: Alice and Eve.

Whatever Alice does to her dry signal (to mangle the signal), she must provide both the mangled signal (pre-convolution) and the convolved signal to Eve.

So with the dry / mangled signal and the wet signal, can Eve figure out Alice's IR?

Currently the answer seems to be yes, but I'm hoping there's some way of making it at the very least very difficult for Eve.

Thank you,
Nelson

Another idea. If you're using block-convolution type algorithms, you can mangle the phase of later blocks over time that correspond with parts of the late reverb tail.

Hello Nonnaci,

Thank you for the suggestion.

Though I'm not familiar with Block Convolution, though I've heard about it, can I assume that Block Convolution (aka Overlap-Add method of convolution) is simply a faster way at performing convolution?

If so, the mangling (or phase cancellation), would need to occur as part of the convolution itself (not afterwards).

In other words (at least for my purposes), I'd need to:

1. Start with some dry signal.
2. Perform some sort of convolution (could be linear, periodic, block etc) on my dry signal, using some IR.
3. Provide the dry signal and wet signal (ex. convolved using block convolution) to a third party, but not the IR.

And then the question becomes, would the use of block convolution (even if we were mangling the reverb tail through phase cancellation), result in a wet signal which our third party would be unable to derive our IR from?

I still think the answer is that our third party would be able to figure out our IR, but I could be wrong.

Important Question: Can I assume that by "mangling" you're referring to something like a phase cancellation? The reason I ask is that I could've sworn that phase cancellation was a by-product of convolution. If that's not the case (i.e. that convolution introduces a natural phase cancellation), that could be a very important piece of information.

Thank you,
Nelson

No you don't want phase cancellation as you would lose content in the output signal. The point is to degrade parts of the IR where it is perceptually indistinguishable.

[camsr]

Convolution is Linear Time Invariant. You could add non-linearity to the output (not the input), and some kind of timing irregularity. The idea is somewhat futile, whatever needs protection is, in reality, a very simple product. But you can change the results of the convolution with the two ideas above and change the product. Then you only worry about code/data protection.