Search code examples
androidencryptiondtmf

Is there any direct way of encrypting DTMF tone so that only intended will receive this?

I googled for any help on this particular requirement, since nothing came through I have decided to post this question. I will keep it short,

I need a help on DTMF generation using android. The requirement is as follows.

1.Generate DTMF Tone using an android phone.(Using Android Tone generator class)

2.Detect this DTMF Tone with voice recorder and display the particular key. (This whole action will be done in a noise free environment)

My question is, how can I encrypt this so that only intended can receive this. Every one who will be listening this can only detect the key if they have decryption algorithm.

Any help would be appreciated.

Thanks,

Nikhil.T

Solution

  • Encryption and encoding are separate steps.

    For example, let's suppose that we want to send the message ROT13 is not a serious encryption algorithm to another device. We might encrypt it using the ROT13 cipher, even though it is not a serious encryption algorithm. That would give us an encrypted message of EBG13 vf abg n frevbhf rapelcgvba nytbevguz, assuming that this site is applying ROT13 properly.

    To get that encrypted message to another device, we can use any number of possible encoding schemes and communications paths. You seem to want to use audio tones. ToneGenerator has lots of tones. Let's say that you want to stick to the classic "touch-tone" tones, represented by the TONE_DTMF_* constants on ToneGenerator. There are 16 of those.

    So, you would need to convert your encrypted message into a base-16 representation, akin to how people convert byte arrays into a base-64 representation. The result of that would be a byte[] of values ranging from 0-15. You would then map those to the 16 tones (e.g., TONE_DTMF_0 for a value of 0). Sending the message would involve playing those tones in sequence, perhaps with some sort of "start of message" and "end of message" tones bracketing them.

    Receiving the message would be a matter of using AudioRecord or something to hear the tones, decode the tones into the byte[] of 0-15 values, reverse the base-16 conversion to get the encrypted message, then use the decryption algorithm to get the original message.

    Chirp and similar solutions exist for doing audio-based data transfer, and this blog post outlines a JavaScript-based solution for implementing this sort of system. Neither, AFAIK, integrate encryption, but that's a matter of what data you ask those systems to send.