-- Edit 2 ---

This question is different from Connect STM32 BLUEPILL to the TRRS connector on the computer

But just in case for not falling into double posting I deleted that post. (This post hes more explanation on what I try to do , on the actual hardware setup, and the answer here will be a lot more useful for the coming after me then the old post , so I deleted the old one so this one will be the main one.)

I hope this o.k. , if not please tell me in comments and I will restore the old post back (even do on my opinion he wasn't helpful or elaborate as this one).

-- Edit ---

This project is for learning purposes, I know that voice over Bluetooth is already encrypted, and there is a few outer off the shelf voice encryption, I don't need to encrypt voice , I want to encrypt voice my self for learning purposes.

I am very grateful to anyone who helped and helps and answers my questions. It helps me to learn and move forward.


Although in the question I'm talking about encryption but does a simple xor with constant value, I know that this is not a real encryption, it is only for the example. (Because if we assume that it is possible to do this simple xor, there is nothing that prevents me from performing proper stream cipher encryption (I assume that I will be able to establish a key using some protocol at this stage in some way, I will actually solve the protocol issue when I will be there...))

I want to encrypt a voice that goes over the TRRS headset. (Ie xor 0x19 for the example) and on the other side will have another earphone that will receive the information (again via standard TRRS connection) decode it (in our example xor 0x19) and play it.

The way I thought to implement the idea was to connect the headset with TRRS to STM32 Blue pill or TEENSY 3.2 or similar cheap board, within the microcontroller to perform the encryption and then send the encrypted information away through another TRRS. On the other side repeat the same idea when this time the microcontroller decodes the data before passing the information to the second TRRS.

This is a schematic that shows a connection between headphones, a blue pill, and a computer. enter image description here

In another question I asked here I have been told that this is not the right way to go because I will have severe synchronization problems and because I won't sample the same "byte" twice because of synchronization problems and other problems so I will get different results that will make everything screw.

What is the right way to make such an idea work?

  • \$\begingroup\$ @ChrisStratton Sorry about this, I try to understand this I won't ask more about this, I just try to figure out what is the proper way of deal with this and how to start solve this issue. that lead to look a like but different question that logically it is proper to separate them to a different threads, again I very sorry about this. \$\endgroup\$ – dog scotter Dec 10 '18 at 14:42
  • \$\begingroup\$ Possible duplicate of Connect STM32 BLUEPILL to the TRRS connector on the computer and four other recent questions of yours. STOP REPOSTING THE SAME PROJECT It was already explained to you long ago why this project is unworkable without digital communication between the devices. \$\endgroup\$ – Chris Stratton Dec 10 '18 at 14:58
  • \$\begingroup\$ @ChrisStratton, Thank you. I understand it now, and i try to understand it better in my question to @JRE. I try to figure out what exactly must become digital for this to work. \$\endgroup\$ – dog scotter Dec 10 '18 at 15:11

Your proposed plan will not work.

Never mind synchronization. The levels between the DAC and ADC will not match. There is noise that will be picked up and/generated in the conversions.

Besides that, your "encryption" will generate sharp edged signals. The sound cards will (must) round those sharp edges.

Your digital "encryption" will be turned to mush.

You would do better to find a something like this example from Keil.

You implement a sound card, and mangle the data in it. The digital audio goes through the PC, and to whereever. On the receiving end, you have another of your gadgets that unmangles the audio.

This will only work if the PCs and software in between your devices pass the digital data through without change. Application of any filter function at all will change your encrypted audio to the point that you can no longer decrypt it. You will have mush again.

This also means that all compressed audio formats (mp3, and whatever voip uses) cannot be used.

An alternative would be to scramble the audio.

You could do the scrambling analog (cheaper to build) or digital (see above about building your own soundcard.)

A simple inverter would be at least as secure as your planned "xor encryption."

  • \$\begingroup\$ If i will use vocoder in this schema so instead of adc, I will use vocoder and then on his packet i will make the encryption (the xor with constant data is obviously not an encryption , I used it as an example for stream encryption) and then send it forward to the out trrs, is it solve the sharp edged signals , synchronization, and noise problem? \$\endgroup\$ – dog scotter Dec 10 '18 at 14:24
  • \$\begingroup\$ another option - what if i change the schema to be , voice to adc and then encrypt it and then transmit it over Bluetooth , so instead of make the chain analog, digital, analog -> analog, digital, analog in which i loos data in the pass from analog to analogm i now will have analog(voice), digital(voice encrypted), digital (Bluetooth) -> digital (Bluetooth), digital(voice decrypted), analog(voice) \$\endgroup\$ – dog scotter Dec 10 '18 at 14:54
  • \$\begingroup\$ Bluetooth already encrypts better than someone asking these questions is likely to, so all you have to do is buy an off-the-shelf bluetooth headset and your need is met without doing a project at all. \$\endgroup\$ – Chris Stratton Dec 10 '18 at 15:15
  • 1
    \$\begingroup\$ To repeat the essence of what I said in your first question, for learning purposes you should do this as a pure software project between two networked PCs, and probably even then first do it with pre-recorded audio files. Don't even think of messing around with embedded systems until you have that part working well. \$\endgroup\$ – Chris Stratton Dec 10 '18 at 16:34
  • 1
    \$\begingroup\$ To respond to a question you posed in a comment on one of your deleted questions: headphones do not move data over the trrs connector. They carry a purely analog represenation of the sound. Nothing digital. Not "data" as you seem to be expecting it. \$\endgroup\$ – JRE Dec 10 '18 at 17:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.