Post by thread:ADC and voice sampling

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! Cheers, Don At 05:26 PM 1/6/00 +1100, you wrote: {Quote hidden}>Hello all, >I am interested in making a PIC based project in which I need to encrypt >voice. The voice is encrypted for transmission using a UHF radio. >Basically the person speaks into the microphone normally, the PIC samples >the analog data from the microphone at a minimum rate of 8kHz, XOR's it >with a preset 'key' and converts it back to analog for transmission. At >the other end the opposite is done. My question is does you run of the >mill ADC0831 8-bit ADC have what it takes to sample a voice signal? > >Wesley > >___________________________________________ >Wesley Moore >RMIT - BEng/BApp.Sc. 2nd Year > >.....wmooreKILLspam@spam@cs.rmit.edu.au >http://wmoore.tsx.org/ >

> I am interested in making a PIC based project in which I need to encrypt > voice. The voice is encrypted for transmission using a UHF radio. > Basically the person speaks into the microphone normally, the PIC samples > the analog data from the microphone at a minimum rate of 8kHz, XOR's it > with a preset 'key' and converts it back to analog for transmission. At > the other end the opposite is done. My question is does you run of the > mill ADC0831 8-bit ADC have what it takes to sample a voice signal? The various responses you've received have all missed the most fundamental problem: the individual bits coming out of the receiver's ADC are going to bear only a vague resemblance to the bits going into the transmitter's DAC, due to signal strength variation, quantization error, etc. Therefore, no bit-based encryption has any chance of being decrypted by the receiver, as long as you're using an analog signal. Things would be different if you transmitted the signal in digital form (using frequency-shift keying, perhaps), but then you'd hardly need to use any encryption to keep people from listening in... My understanding is that analog voice scramblers work by splitting up the signal into four or so frequency bands, then shifting them so that they end up at a different set of non-overlapping frequencies. Doing this in the digital domain would require FFTs or similar techniques: I'm not experienced enough with PICs yet to say whether this is practical to do in real time. Jason Harper

Ken Webster wrote: > Oh .. actually I just thought about it .. I suppose that XORing with a > pseudorandom sequence would probably just add a lot of noise but still > allow the voice to be heard if it was loud enough I don't think so. XORing with a PR sequence should be pretty effective - at scrambling. You see, the PR sequence *fills* the bandwidth with noise - the desired signal cannot be louder than this, in effect the signal modulates the noise rather than the other way around, and modulated noise is - still noise! > Unfortunately the window size would have to be substantial (enough > for 1/100 second or so) to garble the lower frequencies in human voice The general problem with performing scrambling is that to mask the cadence, or envelope, of the speech, you have to generate something (noise) to fill in the gaps. This results in much heavier use of the bandwidth (in fact, it is completely occupied) than normal speech and ipso facto, defeats compression. In fact, compression would tend to defeat the scrambling (by preventing unscrambling). Not the same situation as temporal compression (as in a .WAV file) by the way, where the compressed version can be effectively scrambled (if necessary - compression is already a form of scrambling in itself). > ... I guess a better way would be to group the samples into windows > and shuffle the samples within each window by the pseudorandom > function. The problem with scrambling in general, especially compression, is that data loss (noise) in the transmission tends to "break" the scrambled version so it can't be decoded at all. Simply feeding the encoded data into anohter DAC and vice versa at the other end is really "asking" for corruption. In the case of the PRBNG sequences used to hash data, there is a trick to resynchronise the register, but I haven't figured it out yet. Anyone seen a good explanation of this? -- Cheers, Paul B.

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: {Quote hidden}> > 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.)

One thing to watch for is that the hardware MUST cutoff above 4khz to avoid aliasing. Or else you sample at, say, 128KHz and filter with an IIR, but this may not be achievable with a PIC. I would be very interested to know if your XOR encoding trick really works, I'm no wavehead but it seems like you are pushing information out-of-band, for example one sample XOR's into 00 and the next into FF, but the radio won't go from 00 to FF in 125 uS (call it slew rate, call it bandpass). Not to mention the problem of syncing the receive with the send. You might try posing the question to usenet comp.dsp and see what those guys have to say (for me, it's usually something like "What are you, insane?" followed by a bunch of really excellent ideas and comments which you must then downconvert into embedded reality :). Rich On Thu, 6 Jan 2000, Wesley Moore wrote: {Quote hidden}> Date: Thu, 6 Jan 2000 17:26:10 +1100 > From: Wesley Moore <wmooreKILLspamCS.RMIT.EDU.AU> > Reply-To: pic microcontroller discussion list <.....PICLISTKILLspam.....MITVMA.MIT.EDU> > To: EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.MIT.EDU > Subject: ADC and voice sampling > > Hello all, > I am interested in making a PIC based project in which I need to encrypt > voice. The voice is encrypted for transmission using a UHF radio. > Basically the person speaks into the microphone normally, the PIC samples > the analog data from the microphone at a minimum rate of 8kHz, XOR's it > with a preset 'key' and converts it back to analog for transmission. At > the other end the opposite is done. My question is does you run of the > mill ADC0831 8-bit ADC have what it takes to sample a voice signal?

The basic scheme of digitizing voice, scrambling the bits, then sending the bits is the most straightforward voice encryption scheme. You can't, of course, accomplish much by just XOR'ing with a constant, you need to XOR with a pseudo-random sequence, then descramble using the same sequence at the receiving end. Several problems occur: 1) Any simple scheme for modulating the radio (FSK, ASK, PSK, etc.) to carry the bits will have much greater bandwidth than the original voice. 4kHz bandwidth * 2 for Nyquist, * 8 bits = 64Kb/second. If you have the bandwidth to burn, that makes the problem a whole lot easier. Simply modulating the carrier with the scrambled bits amounts to 256-level amplitude- (or frequency-) shift keying, which would be extraordinarily difficult to demodulate with any accuracy. Your receiver would have to correctly pick out very small differences from one byte to the next -- differences that are probably much smaller than the noise. 2) You need some way to synchronize the receiver's sequence with the transmitter's. This is most easily achieved by sending the data in fixed-length blocks with synchronizing sequences of some kind between them. That adds yet more to the bandwidth, but that's part of the cost of sending the voice digitally anyway. 3) For real security, you need to use a cryptographic pseudo-random sequence generator, such as DES. (You can make any block cypher algorithm into a pseudo-random sequence generator by feeding the output from one round into the next round.) Real systems (like military ones) usually deal with the bandwidth problem by compressing the audio up front, which reduces the number of bits, and then using complex and sophisticated modulation techniques to the point that the data stream can be sent in about the same bandwidth as the original voice. This takes more number-crunching horsepower than a PIC can muster, but is within the capability of relatively cheap DSP chips. SO if you can use more than 64kHz to send your 4kHz voice signals, you can probably do it with a PIC. The most difficult thing to build will be the demodulator that picks the bits out of the stuff arriving at the receiver end. There are a number of techniques like Manchester encoding that will make this easier, but most of them will increase your bandwidth some more again (double, as I recall, for Manchester). You might note that digital cell phones arrived long after analog ones, but that when they arrived, they were encrypted (sort of, but it was politics not technical difficulty that made it very weak encryption). Encrypting a digitized voice stream is a much easier problem than getting the bits from one end of the radio to the other. {Original Message removed}

Paul B. Webster wrote: >Ken Webster wrote: > >> Oh .. actually I just thought about it .. I suppose that XORing with a >> pseudorandom sequence would probably just add a lot of noise but still >> allow the voice to be heard if it was loud enough > > I don't think so. XORing with a PR sequence should be pretty >effective - at scrambling. You see, the PR sequence *fills* the >bandwidth with noise - the desired signal cannot be louder than this, in >effect the signal modulates the noise rather than the other way around, >and modulated noise is - still noise! Well, if this is true (and it does sound reasonable to me after thinking about it), then wouldn't this do the trick? Simply XOR with a pseudorandom sequence on the transmitting end and then XOR with the same sequence on the receiving end to cancel most of the noise. Sampling errors would merely add a little noise (or perhaps a lot of noise .. I just realized that some small errors could cause the result of the XOR on the receiver to wrap around from near zero to near 0xff or vice-versa .. depending on how frequently this happens the recovered signal could be quite noisy). What about limiting the amplitude of the voice signal to a signed 7-bit value and likewise limiting the amplitude of the PRN to 7-bits and adding the two (rather than XORing) so that the noise is superposed and never causes low values to wrap around to high values or vice-versa? Then on the receiver you subtract the PRN and end up with a somewhat noisier version of the signal you started with. If large errors are introduced by the bandwidth limits of the channel (limits on slew-rate, etc.) then couldn't you run the PRN through a lowpass filter and still get good results? > ... (snip) > In the case of the PRBNG sequences used to hash data, there is a trick >to resynchronise the register, but I haven't figured it out yet. Anyone >seen a good explanation of this? If you did the above (adding PRN at transmitter and subtracting it at receiver) then the signal amplitude should be continuously very high unless you are synchronized. As long as your original data has some silent or quiet parts then you should be able to slew the phase of the PRN at the receiver until the average amplitude drops .. when your recovered signal has a low amplitude (even for just a brief interval) then you must be in phase. If you can't guarantee that your signal has quiet intervals but you have some bandwidth to spare then you could group data into packets consisting of signal sent at a higher sample rate with a period of silence inserted. Then when you get your PRN generator in phase on the receiving end you should see near-silence at regular intervals. The only "tricks" I am aware of are to try many phases of the PRN sequence simultaneously, processor time permitting, by keeping a window of the PRN sequence and trying multiple indexes within the window simultaneously. Otherwise it could take a long time to find the correct phase if the PRN sequence is long. This sounds fun to try! I'd be interested in hearing about the results if anyone tries this. Cheers, Ken

Hi, I made toughts also about this topic. My main problem is the following: how do you synchronise the receiving and the transmitting stations? I. e.: you take a sample, convert to digital, XOR with a key, send it. Then, take the next sample, convert it to digital, and XOR WITH THE NEXT BYTE OF THE KEY. Thus, it is necessary to use multibyte key, otherwise the enemy could decrypt with brute force bcus he need only try 256 different decrypting key. I suppose, if you use a multibyte key (e. g. 2048 byte or so, or - better yet - you use two parallel running pseudo-random generator), then the result would be like noise and the otherwise good remarks of Mr. Holtz could be also eliminated. I would interesting also on this project... Regards, Imre On Wed, 5 Jan 2000, Don Holtz wrote: {Quote hidden}> 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! > > Cheers, > Don > > At 05:26 PM 1/6/00 +1100, you wrote: > >Hello all, > >I am interested in making a PIC based project in which I need to encrypt > >voice. The voice is encrypted for transmission using a UHF radio. > >Basically the person speaks into the microphone normally, the PIC samples > >the analog data from the microphone at a minimum rate of 8kHz, XOR's it > >with a preset 'key' and converts it back to analog for transmission. At > >the other end the opposite is done. My question is does you run of the > >mill ADC0831 8-bit ADC have what it takes to sample a voice signal? > > > >Wesley > > > >___________________________________________ > >Wesley Moore > >RMIT - BEng/BApp.Sc. 2nd Year > > > >wmoorespam_OUTcs.rmit.edu.au > >http://wmoore.tsx.org/ > > > >

Ken Webster wrote: > Well, if this is true (and it does sound reasonable to me after > thinking about it), then wouldn't this do the trick? Simply XOR with > a pseudorandom sequence on the transmitting end and then XOR with the > same sequence on the receiving end to cancel most of the noise. It will indeed "do the trick", but is impractical for the reasons I and others have mentioned; it introduces a large high-frequency (wide bandwidth) component, and necessitates a more reliable link than a DAC to transmit and ADC to receive. > Sampling errors would merely add a little noise (or perhaps a lot of > noise .. I just realized that some small errors could cause the result > of the XOR on the receiver to wrap around from near zero to near 0xff > or vice-versa .. depending on how frequently this happens the > recovered signal could be quite noisy). That's right. > What about limiting the amplitude of the voice signal to a signed > 7-bit value and likewise limiting the amplitude of the PRN to 7-bits > and adding the two (rather than XORing) so that the noise is > superposed and never causes low values to wrap around to high values > or vice-versa? If you think about it, adding and XOR-ing are almost the same. But the real problem is still that it is the PRBS *itself* that contains these "wrap-arounds" (rapid change of MSB) already. > If large errors are introduced by the bandwidth limits of the channel > (limits on slew-rate, etc.) then couldn't you run the PRN through a > lowpass filter and still get good results? If you low-pass it and combine with the signal, it will no longer fully mask the signal. :) > If you did the above (adding PRN at transmitter and subtracting it at > receiver) then the signal amplitude should be continuously very high > unless you are synchronized. As long as your original data has some > silent or quiet parts then you should be able to slew the phase of the > PRN at the receiver until the average amplitude drops That's close to the method. I think there's something sneaky in the maths; if you XOR (auto-correlate) the PRBS with itself out-of-phase, the resultant has, I suspect, some interesting properties. > This sounds fun to try! I'd be interested in hearing about the > results if anyone tries this. The theory has as I say, already been nutted out. I'd just like to see a good article... -- Cheers, Paul B.

Paul B. Webster wrote: >Ken Webster wrote: > >> Well, if this is true (and it does sound reasonable to me after >> thinking about it), then wouldn't this do the trick? Simply XOR with >> a pseudorandom sequence on the transmitting end and then XOR with the >> same sequence on the receiving end to cancel most of the noise. > > It will indeed "do the trick", but is impractical for the reasons I >and others have mentioned; it introduces a large high-frequency (wide >bandwidth) component, and necessitates a more reliable link than a DAC >to transmit and ADC to receive. I must disagree with you here. 1). The bandwidth needn't excede the Nyquist frequency .. if your sample rate is 8kHz then a full-scale transition can be represented by a 4kHz sinusoidal component of maximum amplitude. True that the output of the DAC will transition rapidly and thus have much higher frequency components, but, by limiting the bandwidth to 4kHz (by passing the DAC output through a lowpass filter or a bandwidth-limited channel) you are not loosing any information .. the signal will still swing from one voltage to the other within one sampling interval (125 microseconds for an 8kHz sample rate) and be correctly sampled by the A/D on the other end. 2). Link reliability (noise and imperfect frequency response) will merely result in some of the introduced pseudo-random noise not being completely cancelled at the receive end. If you cancel most of it, however, you should still be able to recover an intelligable version of the original signal. Digitally filtering the PRN on the recieve end to match the transfer function of the channel would definitely help if the channel doesn't have a flat response. A small amount of imperfection should not prove disastorous, though ... it should merely result in a small amount of added noise. {Quote hidden}>> Sampling errors would merely add a little noise (or perhaps a lot of >> noise .. I just realized that some small errors could cause the result >> of the XOR on the receiver to wrap around from near zero to near 0xff >> or vice-versa .. depending on how frequently this happens the >> recovered signal could be quite noisy). > > That's right. > >> What about limiting the amplitude of the voice signal to a signed >> 7-bit value and likewise limiting the amplitude of the PRN to 7-bits >> and adding the two (rather than XORing) so that the noise is >> superposed and never causes low values to wrap around to high values >> or vice-versa? > > If you think about it, adding and XOR-ing are almost the same. But >the real problem is still that it is the PRBS *itself* that contains >these "wrap-arounds" (rapid change of MSB) already. I must have had a big brain fart when I thought about this before -- XOR will only toggle a few bits .. noise in the channel would only offset the value a little but not prevent the XOR on the receive end from largely undoing what the XOR on the transmit end had done. Adding 8-bit values, however, would sometimes result in a small error wrapping the value around, for example: original signal: 0xff PRN added: 0x01 transmitted signal: 0x00 noise/error: 0x01 received signal: 0x01 PRN subtracted: 0x01 result: 0x00 error: 0xff It was the above scenario that I had in mind. Gotta get out of the habit of having several beers before chatting on this group :o) XOR, on the other hand, would do much better: original signal: 0xff PRN xor'd: 0x01 transmitted signal: 0xfe noise/error: 0x01 received signal: 0xff PRN xor'd: 0x01 result: 0xfe error: 0x01 So, after reconsidering, I would expect XOR to work quite nicely. >> If large errors are introduced by the bandwidth limits of the channel >> (limits on slew-rate, etc.) then couldn't you run the PRN through a >> lowpass filter and still get good results? > > If you low-pass it and combine with the signal, it will no longer >fully mask the signal. :) Yes but do you think you could make any sense of a conversation if the only unmasked components were above 2kHz? {Quote hidden}>> If you did the above (adding PRN at transmitter and subtracting it at >> receiver) then the signal amplitude should be continuously very high >> unless you are synchronized. As long as your original data has some >> silent or quiet parts then you should be able to slew the phase of the >> PRN at the receiver until the average amplitude drops > > That's close to the method. I think there's something sneaky in the >maths; if you XOR (auto-correlate) the PRBS with itself out-of-phase, >the resultant has, I suspect, some interesting properties. Hmm.. this sounds interesting. I would be quite interested in any method that works better than the brute-force slew-and-correlate technique(which works alright with a large window and many phases being correlated simultaneously but still takes a significant amount of time to lock with a long PRN sequence). >> This sounds fun to try! I'd be interested in hearing about the >> results if anyone tries this. > > The theory has as I say, already been nutted out. I'd just like to >see a good article... Hmm... if I get a few moments free I might whip up a simulator in C++ ... simulate the communications channel with an editable transfer function plus some noise sources. I didn't think I was very interested in this before but all this talk of slew-rate and bandwidth limitations rendering the technique unusable has got me going. I really do think this would work quite nicely. It would certainly be challenging to get the receiver to reliably lock with an unknown transfer function for the communications channel, but, nevertheless, it is quite feasible IMO. BTW -- who started this thread originally? Are you interested in trying out this technique? (if the C++ simulation gives good results) Ken