OTT service using FPE Would it be possible to create an Over-The-Top communication utility that will encrypt voice using format preserving encryption (voice clear-text to audio encrypted stream) and send that over an existing channel (e.g. Skype/ Cellular)?

I was wondering if the FPE could be made to take such a form that the compression algorithms used in VoIP would not be able to compress and would be forced to send all the analog signal (the encrypted voice message).

As I understand the voice compression algorithms work by cutting off sounds over a certain frequency, so if the encrypted "sound" would be 100% in the "don't truncate" part of the sound spectrum the voice codec would have no way of compressing and default to send the entire thing.
The answer depends on how you would layer the encryption on top of the existing protocol.

If you implemented your own Skype client, you could deal with compression issues yourself. That might allow you to use format preserving encryption, perhaps on the compressed data stream and not the audio itself.
However, you would need to be careful – speech compression is very lossy and concentrates the few bits it uses on where they are needed. You'd need to make sure patterns of speech would not be visible as higher bitrate bursts.

If you let Skype deal with compression, you likely couldn't use format preserving encryption due to compression artifacts. Instead, you'd need to use a lower bitrate encrypted channel that gets encoded as audio, probably together with some kind of error correction.
Again, you'd need a constant bitrate to hide the encrypted information fully, so some extra buffering would likely be needed to make efficient use of what's available. If the bitrate isn't enough, you might need to use a video call as the data channel for encrypted audio.


I'm unsure if the former would be an option over cellular, if the compression is done in hardware outside your control, or if the data gets recompressed en route.

As I understand the voice compression algorithms work by cutting off sounds over a certain frequency, so if the encrypted &quot;sound&quot; would be 100% in the &quot;don't truncate&quot; part of the sound spectrum the voice codec would have no way of compressing and default to send the entire thing.

That's not an accurate picture of how (modern) speech compression works. Instead, like most other lossy compression it also quantizes the information so that it is inaccurate compared to the original, but close enough for a human. Some frequencies are weighted higher and some lower, but all essentially lose information (unless the signal is very low bandwidth). Going into more detail is off topic here, but you can start from Wikipedia if you are interested.
Could you essentially invert the compression process and push the data into forms where it's retained? Maybe. That would be a very complex way to get 1. above without implementing the actual client.