End to End Cell Phone Encryption?

Does anyone make a black box that could be attached into the headphone jack of each end of a cell phone conversation and used to encrypt the call? The black box would then have a jack that goes to a normal headset.

I have seen such things for regular analog phone lines, but never as an add-on for a cell phone.

Reply to
W
Loading thread data ...

Reply to
andrea.zerbini8

You wouldn't find it on the headphone jack. A cell phone transmits voice heavily compressed already. Handset encryption is either really, really weak or it turns the voice into an encrypted modem stream. And a modem won't go through a compressed-voice stream. So you have to do the encryption in the voice-carrying data stream on the cell phone (e.g., silentcircle).

Reply to
Fred Goldstein

Can you expand on why encryption is not possible for a cell phone in the handset?

The problem is there are many commercial applications that can be secretly installed onto a cell phone that basically turn it into a spying base station for a remote listener. That person can listen in on your calls or remotely activate the phone. To the extent that the malware lives on the phone, phone-based encryption isn't guaranteed to protect the call from interception.

Reply to
W

A headphone/handset is merely an audio input device. On a cell phone, the audio is compressed nine ways to hell in order to minimize bandwidth, so that the network can spend more of its bits carrying cat videos. The compression is based on passing across the network the minimum amount of information needed to create a mostly, though not perfectly, intelligible stream of English words, with the speaker's vocal nuances partially, but not completely, lost.

SO how do you encrypt that? Since it's looking for the specific features of human voice, in order to compress them, it won't work right on almost anything else.

Thus cell phone encryption has to be done around the voice compressor. Either it takes the compressed voice and encrypts that data stream (which the phone already does, but the network has the key, so it's not private) or it takes the uncompressed voice and compresses and encrypts it, typically sending that over the network as data (i.e., disguised as a cat video).

Reply to
Fred Goldstein

I'm not trying to encrypt the digitized form of the information. But would there be some way to have hardware encryption of the analog signal in a wire-attached headset, based on some long code dialed into the headset. As long as the person on the receiving end has same product and the same code dialed in, the reverse encryption should be straightforward.

Reply to
W

As an earlier poster mentione (might even have been you) there were regular looking handsets that plugged into your standard Bell 2500 set or equivalent... that could toggle between "clear" and "encrypted". I used one myself 20 years ago when I was in an office environment where calls were routinely taped.

I don't recall the specific method it used, by my guess it was a rolling code frequency inversion. That is, the voice part of the call was split into (for illustration here), twenty separate frequency notches, and the part of speech that was normally 250 to 500 hz was moved to 3000 to 3250, with the others swapped around as well .

The main problem with this tech on a cellphone is:

there is so much compresion, make that _lossy_ compression, going on in the cell system that anything not "looking like" (so to speak) key parts of the voice stream are lost by the codec. This would be devastating for getting the conversation across to you.

As a very bad analogy, if I say the numbers "1 2 3 [dropout] 5 6", you'll process that to include the number "4". However, if I said "3 6 2 [dropout] 1 5", you'd be lost.

The some would happen with the reconstructed (at your friend's handset) stream. The parts that the cellco loses, which normaly are filled in ok by your brain (well, to the extent that people manage to delude themselves...) would be way out of the usual sequence so the results would be pretty marginal.

That being said I'd love someone to at least try to design something and test it out...

Reply to
danny burstein

Very succinct and it makes clear why the approach I suggest might not work.

What about the same idea with a bluetooth headset, but the encryption has to take place in the headset before any data is passed digitally to the phone? So you would dial in an encryption code on both ends of the conversation, and the headset would do hardware based encryption of the data before sending anything to phone.

Reply to
W

Same issue. I'd love to see someone try it, but to repeat a couple of my earlier paragraphs:

The codecs in use compress the data stream containing your voice, and in doing so throw out lots of the info. They're designed in such a way that your brain "fills in" the missing segments.

So as a bad analogy, if I was speaking to you (directly in a room) and said "1, 2, 3, [very faint so you hear "something" but it's unintelligible], 5, 6", you'll automatically, without thinking, fill in that as a "4".

Same concept applies to the lost compressive codecs.

But if I (in that room) said "2, 5, [very faint...], 3, 6, 1", you wouldn't fill in the missing digit. And the same issue would apply with standard codecs - they'll drop stuff that "looks" like it's superfluous, but in reality critical.

Reply to
danny burstein

So could you have the encryption hardware integrate with some custom written CODEC in the phone?

Starts to sound like a very difficult project.

Reply to
W

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.