2

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,

Zeeshan Abbas
  • 79
  • 5
  • You can do the error correction after encryption, sometimes you move an encrypted file and just rely on a lower level to handle it. You can do stuff inside but it seems like a pain, since there's no easy way to retransmit lost bits of data without letting some information slip out. – daniel Mar 01 '18 at 07:17
  • Thanks Daniel for your kind response. It's cleared that it's good to use the error correction after the encryption. What I want to clarify here is that: Can I use convolutional code/Viterbi decoder for the error detection/correction for encrypted data or not? – Zeeshan Abbas Mar 02 '18 at 05:38
  • You can use whatever you want once it's encrypted, hamming codes, tcp ip retransmission, or even simply repeating the message 50 times – daniel Mar 02 '18 at 06:23
  • Great. Actually, I need it for voice data so retransmission is not possible. I am thinking about using the convolutional code. – Zeeshan Abbas Mar 02 '18 at 06:43
  • If it's like a back and forth conversation there's a bit more to consider as the timing of messages mean something, even compression before sending (which is usually alright) can give away info https://crypto.stackexchange.com/questions/15138/how-does-compression-before-encryption-leak-info-about-the-input – daniel Mar 02 '18 at 07:07

3 Answers3

2

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.

kodlu
  • 22,423
  • 2
  • 27
  • 57
  • would you be kind enough to expand with some examples for outsiders like me? Although I've heard of error-correcting codes, parity, and encryption, I can't get the intuition of it. – DannyNiu Mar 01 '18 at 14:15
  • Thanks @kodlu. I would like to confirm if I can use the same error correction techniques for the encrypted data which we use for the plain data. – Zeeshan Abbas Mar 02 '18 at 06:41
  • Yes, of course, you can. The two can be decoupled to a large extend, the only issue is when a decoding error happens, you're kind of stuck with the wrong decryption for the blocks that are wrongly decoded. However, it's the job of the coding and modulation layers to deal with that, not that of the encryption. – kodlu Mar 02 '18 at 06:44
  • Great. So, it would be like: Data->Encryption->encoder i.e.Error detection/correction. (Channel) Decoder -> Decrption. – Zeeshan Abbas Mar 02 '18 at 06:50
2

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:

  • Stream ciphers (and stream modes of operation) can mitigate some error-based side channels, but they make it easier to modify the plaintext.
  • Ironically, ability to predictably modify the plaintext introduces a different kind of side channels.
  • Uncompressed PCM audio is easy to modify (if it is not authenticated) and read using (if you use crypto in some wrong ways, e.g., IV reuse) xor attacks on stream ciphers. On the other hand, compressed audio without authentication might introduce some error-based side channels (that uncompressed audio would survive).

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.

v6ak
  • 631
  • 4
  • 9
  • Really thankful for these very important points you mentioned. I have to use this for secure voice communication so I don't think that we need the authentication. I will be pleased if you put light again keeping the voice data in mind. – Zeeshan Abbas Mar 06 '18 at 06:54
  • OK, added to the answer. – v6ak Mar 06 '18 at 08:46
1

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.

Meir Maor
  • 11,835
  • 1
  • 23
  • 54