4
$\begingroup$

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.

Improve this question
$\endgroup$
9
  • 5
    $\begingroup$ This question appears to be off-topic because it is not about cryptography as defined in our help center. (Security.SE would be a better place for this question… flagged it with an according migration request.) $\endgroup$
    – e-sushi
    Jul 28, 2014 at 16:10
  • 2
    $\begingroup$ A note aside: the short answer is “yes”. (Hint) $\endgroup$
    – e-sushi
    Jul 28, 2014 at 16:27
  • 2
    $\begingroup$ @otus That was my initial reaction too… but the question merely asks if it “would be possible”, not if format-preserving encryption is the optimal way to do it. ;) (Besides: things strongly depend on the individual implementation, the available resources, and the used compression… so, we would definitely need to look at those before simply ruling out FPE as a potential option.) $\endgroup$
    – e-sushi
    Jul 28, 2014 at 18:40
  • 2
    $\begingroup$ @e-sushi: actually, to answer the question "is it possible", the important thing to ask is "does the network that carries the Codec-encoded bitstream just move those bits from the sender to the receiver, or does it do any manipulation (such as doing some internal compression to save bandwidth on an internal link). If the system is just moving bits, I see no problem in sending encrypted bits -- if the system expects that is an actual signal (and so transforms that don't change the signal audibly are allowed), that makes the problem much trickier. $\endgroup$
    – poncho
    Jul 28, 2014 at 21:49
  • 2
    $\begingroup$ @poncho That’s why I answered the “Would it be possible…” with my short “yes”, and later pointed out that things will strongly depend on the details to be able to decide if it makes sense to practically implement things using FPE. (I guess we both know that FPE might not be the most optimal path to choose here. Yet, it “could” be an option… to decide, we would need more details.) $\endgroup$
    – e-sushi
    Jul 28, 2014 at 22:08

1 Answer 1

Reset to default
3
$\begingroup$

The answer depends on how you would layer the encryption on top of the existing protocol.

  1. 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.

  2. 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 "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.

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.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Nicely wrapped up… I don’t think Security.SE would be able to add much more to that. [+1] $\endgroup$
    – e-sushi
    Jul 29, 2014 at 9:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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