hi all
i would to know if how to encrypt the voice in rf transceiver devices!!

 

Theoretically:

1. You digitize the audio data stream
2. You encrypt the data stream
3. You use the encrypted data stream to modulate the RF transmitter

Problem:

1. Small errors in decoding the data will result in drop outs or audio gibberish

 

thank you papabravo! is there Ic or chips to do that? or we must use micro controller with ADC and DAC?
and what RF company do to encrypt their transceiver devices like ICOM and motorola?

 

thank you papabravo! is there Ic or chips to do that? or we must use micro controller with ADC and DAC?
and what RF company do to encrypt their transceiver devices like ICOM and motorola?

I don't know if such a specialty chip exists or not. This is a complex problem for which a simple solution appears unlikely. Do you have any relevant experience in this field?
Here are the top 3 Google hits

http://www.performanceaudio.com/media/pdf/336/14566_s.pdf
https://zaxcom.com/zaxcoms-new-trx900lt-provides-encryption-for-secure-audio-transmission/
http://www.lectrosonics.com/US/phocadownload/700seriesman.pdf

Does not look like simple stuff to me. The prices will probably bend your wallet as well.

 

Does not look like simple stuff to me. The prices will probably bend your wallet as well.

It would simpler just to learn how to speak Navajo for secret messages.
https://en.wikipedia.org/wiki/Code_talker#Cryptographic_properties

Secure voice systems are complex things to implement. http://cryptomuseum.com/crypto/usa/saville.htm

There are several 'audio' (300 to 3,000 Hz voice) scrambler systems that can be used on a normal audio channel, this one is PARKHILL.

 

Does not look like simple stuff to me. The prices will probably bend your wallet as well.

yes Papabravo i have some info in this field, but i'm looking forward to make my encryption device to use it with rf hand held rf transceiver.

 

"info in this field" is not quite the same thing as experience in my opinion. The real problem to solve is not encryption per se, but reliable decryption. I would not even know where to look or how to start to find an algorithm to minimize the chance that a bit error would cause a cascade that would destroy several seconds of audio. Do you have any insight on how to solve that problem?

 

There a many ways to make the transmission reliable and most have very little to do with the encryption -- the same problem of drop out is an issue with any digital transmission. The first level is to simply to include FEC (forward error correction) in the data stream. The stronger the FEC the more reliable the transmission, but the lower the data rate for the same bandwidth because more of it is taken up with the FEC data. Another tactic is to spread the data out so that any given frame that is lost represents short errors spread across the signal instead of a single long error at one place. Since lost frames WILL occur, you also want to use an encryption scheme that will resynchronize on its own.

 

There a many ways to make the transmission reliable and most have very little to do with the encryption -- the same problem of drop out is an issue with any digital transmission. The first level is to simply to include FEC (forward error correction) in the data stream. The stronger the FEC the more reliable the transmission, but the lower the data rate for the same bandwidth because more of it is taken up with the FEC data. Another tactic is to spread the data out so that any given frame that is lost represents short errors spread across the signal instead of a single long error at one place. Since lost frames WILL occur, you also want to use an encryption scheme that will resynchronize on its own.

I was wondering if the decryption and decoding would need to be done in real time. To be useful in a handheld transceiver it seems like that would be essential. On the other hand if the audio contents could be stored and played or replayed from that storage there might be other options. From the original question I had assumed that the entire device might be designed and built from scratch. As I reread the TS/OPs responses it seems he might be talking about an add on device to an existing RF deck. I'm still not sure what the actual requirements might be.

 

I was wondering if the decryption and decoding would need to be done in real time. To be useful in a handheld transceiver it seems like that would be essential. On the other hand if the audio contents could be stored and played or replayed from that storage there might be other options. From the original question I had assumed that the entire device might be designed and built from scratch. As I reread the TS/OPs responses it seems he might be talking about an add on device to an existing RF deck. I'm still not sure what the actual requirements might be.

There is almost always a delay when using a transceiver between the mike PTT and the actual encoded audio at the receiver due to the keying and synchronization process. One of the old devices we used was the KY-(2)8 (NESTOR), it worked great but the fighter pilots hated the delay (it's much better with modern devices). As a result, the equipment was often switched off and transmissions were made in the clear.

 

I was wondering if the decryption and decoding would need to be done in real time. To be useful in a handheld transceiver it seems like that would be essential. On the other hand if the audio contents could be stored and played or replayed from that storage there might be other options. From the original question I had assumed that the entire device might be designed and built from scratch. As I reread the TS/OPs responses it seems he might be talking about an add on device to an existing RF deck. I'm still not sure what the actual requirements might be.

The encryption is done with a streaming cipher and with modern systems it can be done in real time. Of course there is latency, but that is true of any comm system. The objective is simply to keep the latency tolerable. The definition of tolerable depends on the application.

 

There is almost always a delay when using a transceiver between the mike PTT and the actual encoded audio at the receiver due to the keying and synchronization process. One of the old devices we used was the KY-(2)8 (NESTOR), it worked great but the fighter pilots hated the delay (it's much better with modern devices). As a result, the equipment was often switched off and transmissions were made in the clear.

Aircraft communication still uses AM modulation so that simultaneous transmissions don't completely interfere with each other. The way pilots talk to each other and ATC is mostly unintelligible to the rest of humanity. I don't suppose that would meet the TS/OPs definition of encryption

 

In a mundane example, we have a standard set top box in our kitchen and down a set of stairs there is a high definition TV. There is a significant lag in the signal between the two TVS, most annoying when one of us is in the kitchen while the other is watching in the den.

The processing of the high def transmission introduced a significant lag. The lag is measured in seconds, if not minutes. I can leave the kitchen, go down a hail, descend the stairs and turn a corner and not miss any of the broadcast. So if relative real time is required, there could be an issue.

 

yes friend. thank's for every body try to help and give info. my last question is there ready electronic chip or completely integrated project using micro controller to begin doing that!!?
thank's all