0

Let's say I have some data ciphered using key, $K_1$, in to format $D_1$, which I want to convert into format $D_2$ that can be decrypted using $K_2$.

So I know $D_1, K_1$ and $K_2$.

I want to convert $D_1$ to $D_2$ but I want to avoid actually decrypting the data $D_1$ into its plaintext form. Is it possible to do so for any of the popular symmetric encryption algorithms such as DES, 3DES, ARCFOUR, AES, Camellia, RC2, IDEA, SEED? I am guessing it's not possible, but still thought I'd ask, since I don't know much about most of these methods.

A reason for doing something like this may be in an enterprise setting where companies typically create their own https proxies and act as MITM. If they only want to analyze the headers of the http packet but not the body itself then they could only decrypt a portion of the data and pass on the rest of it. This way they can be minimally invasive given their security policies.

Lery
  • 7,679
  • 1
  • 26
  • 46
Pushpendre
  • 103
  • 2
  • 1
    Any stream cipher, such as RC4 or ChaCha20, also blocks ciphers in CTR mode. – paj28 Jul 16 '17 at 03:35
  • After reading about stream ciphers and block ciphers I understand that stream ciphers work by generating a key of the length of the message through a stream emitted from prng, and a block cipher works on blocks of data.

    Your comment says that stream ciphers can be used to make block ciphers in CTR mode.

    Since stream ciphers just xor data and xor is associative, it seems that the conversion from D₁ to D₂ is just a matter of xoring the keys k1, k2. Was this what you meant?

     – Pushpendre Jul 17 '17 at 04:11
  • Yeah. pretty much. You need to XOR the PRNG output, not the key. And CTR mode turns a block cipher into a stream cipher, not the other way round. But yeah, you've got the idea. – paj28 Jul 17 '17 at 04:57
  • This is certainly related (maybe a duplicate?) to that recent question. – Lery Jul 17 '17 at 08:40

1 Answers1

1

Yes, this is possible for all synchronous stream ciphers where your plaintext $M$ is simply XoRed with a keystream $K_1$ to produce the ciphertext: $D_1=M\oplus K_1$ because then you can simply XoR again the ciphered data $D_1$ with $K_1\oplus K_2$ together to get: $$D_2= D_1 \oplus K_1\oplus K_2 = M \oplus K_1\oplus K_1\oplus K_2 =M\oplus K_2.$$

So modern stream ciphers such as Chacha20, but also older such as AES-CTR, support this.

This also means that you can also use this with any block cipher in CTR mode of operation, so Camellia, IDEA, AES etc. are all fine.

However, other stream cipher have ciphertext dependent operations, like AES-CFB, and won't allow for it as easily. Besides, if you want to have actual security you should also worry about authenticity and integrity of your data, which means you have to HMAC (or CBC-MAC) again with the new key afterwards... AEAD schemes won't typically support "re-keying" of the cipher.

It might also be possible for other ciphers, in ways similar to those explained in this recent answer.

There are also other malleable schemes which might allows you to change a part or all of the secret material without decryption, provided you know both the old and new secret material, for instance it is easy in RSA to change the public & private exponents, but then you need to use the same $N=pq$, so anybody knowing the factors $p,q$ would still be able to crack both private exponent, being given the public exponents.

Lery
  • 7,679
  • 1
  • 26
  • 46