You say, I XORed the sound data with 0xB4, and got this: doorxor.wav ???

How about not using a constant (B4) but using the result of the previous
encoding, instead?  Something like a CRC scheme...

Initialize Temp=0xA5
Do while (true) {
  Sample = GetSample();
  Output = Sample x-ored with Temp;
  Temp = (Output, circular shifted left or right by 3);
  PutSample(Output);
}

That should be not many more PIC cycles than just the xor, and be a
little better at messing up the signal.

For lots better "encryption", you could change the shift amount
dynamically on the fly, and perhaps add a changing number into Temp, to
make the "key" even more randomized.  Also, what about using only the
lowest 8 bits of a 32-bit number for Temp, that should change things
somewhat...

  Mark

Keelan Lightfoot wrote:
>
> Don Holtz wrote:
>
> >Just a thought about your XOR encryption:
> >
> >Are you trying the render the encrypted channel unintelligable?
> >
> >My gut feeling is that by using a simple byte-by-byte XOR method, the
> >encrypted sound will still be very easy to undertand.  XOR does not alter
> >the overall cadence, or frequency content of the sound very much.
> >
> >To do it properly it is best to distribute the sound energy in both time
> >and frequency.
> >
> >You might want to test a quick implementation of your scheme on a PC
> >first... to see how it works.... I would like to hear the results!
>
> ----------
>
> I tried it, and you're right, Don, the sound is stull understandable.... You
> can see the results of my 'efforts' at:
> http://www.bzzzzzz.com/beehive/keelanl/xortest/
>
> - Keelan Lightfoot

--
I re-ship for small US & overseas businesses, world-wide.
(For private individuals at cost; ask.)