I will be very pleased if anyone can clarify me that, can we use the same error detection/correction techniques like (Convolutional code) for the error detection/correction of encrypted data. Or do we need separate techniques for plain data & encrypted data?
Thanks,
Not only is it easier to do error correction/detection after encryption, it is risky to do the error correction before encryption.
This is because the attacker would know parity check relations (in the typical case of a linear code being used) between the bits of the plaintext, which could get them started on an attack.
It depends on many details symmetric/assymetric, cipher, mode of operation, scenario of encryption, types of attacks you want to defend). I'll try to cover the most common scenarios:
One usually don't use encryption alone. It often needs to be used together with authentication. The task of the authentication is to detect unauthorized modification. So, when decrypting, you need to perform error correction before you verify if the message has not been altered. In such case, you can use any error code correction you want. Encrypted data will look usually as a random data. (It has to look as some random data if encryption is secure and it does not inflate the data much.) Remember, you have to properly recover all the data. If you don't, you can't securely recover anything.
For symmetric encryption, the process will likely be encrypt-then-authenticate-then-use-ECC. For asymmetric, it gets a bit more tricky, but using ECC will be the last step.
In rare cases, you don't need authentication. That is, you assume that attacker cannot modify the data. This might be OK for data at rest, but probably not for data in transit. This might allow you to apply error correction codes before applying encryption (under some circumstances), but this seems to be a tricky area with high likelihood of mistakes. And I don't see any advantages of this approach.
Notes for secure voice:
First, I suggest finding an existing protocol+implementation and wrapping it in error correction (if not already contained). This can prevent many design and implementation hassles. There are some protocols (IIRC: ZRTP and SRTP, or DTLS if you prefer lower level). I don't know them in detail and I have no idea if they fit your needs, but it is IMHO worth checking.
If this is not possible, you have to properly manage mode of operation, IVs, replay attacks and so on.
On authentication: I know two kinds of attacks that can arise from missing authentication:
a. Modification of the data by attacker. b. Error-based side channels.
While I admit that some attacks might be hard in your case, I would not dare to consider them as impossible. Such design looks fragile. Some seemingly innocent modification can break previously secure protocol. Moreover, some factors that can make harder attacks (a) makes easier attacks (b) and vice versa:
In short, proper authentication makes whole threat model much easier.
If you are scared about some details, it might be actually a good reason to consider existing protocols over a custom solution.
You can use any error correction technique after encrypting. You may or may not want to use an encryption mode which allows for partial decryption, if your error correction is insufficient to overcome some errors, do you want to lose all the message after the unrecoverable error or only some limited portion? The various stream ciphers and CTR will allow recovering part of the message while CBC will loose a minimum of two blocks.
Note applying error correction code before encryption is a really bad idea as it introduces lots of redundancy into the plain-text. If you use a stream cipher you will still have error correction while with a block cipher encrypting after error correction will kill most forms of error correction. An infamous bad design example is GSM which applies error correction before encryption making it trivial for a passive attacker to mount known plain-text attacks with lots of pairs against the various ciphers.
