0
$\begingroup$

I have used TrueCrypt but it uses a cascaded encryption. I want to know about encrypting a file using two ciphers with each cipher having different key.

Cipher A (Block Cipher) - with Key KA

Cipher B (Stream Cipher) - with Key KB

First I am encrypting a file with Cipher A (KA). Again I am encrypting a file using Cipher B (KB).

Does this, in any way, make the final encrypted file vulnerable? Or, rather, leave some loopholes.

One other approach I thought is to compress a file before applying second cipher so as to make it more random.

Cipher A -> ZIP -> Cipher B

How secure is this and in which mode the two ciphers be operated to achieve high security?

** Edited **

Both the keys are different. Encrypted file also does not contain any key.

Improve this question
$\endgroup$
10
  • $\begingroup$ Are the keys independent? Is the file you encrypt independent of both keys? $\endgroup$
    – Geoffroy Couteau
    Commented Oct 10, 2016 at 14:01
  • 1
    $\begingroup$ 1) turn cipher A into a stream cipher and see the other answer. 2) Do not use .zip as it may convey information about the plaintext or the intermediate ciphertext. Just XOR'ing the plaintext and the two key streams together should give you optimal security. $\endgroup$
    – Maarten Bodewes ♦
    Commented Oct 10, 2016 at 14:31
  • 1
    $\begingroup$ @RPK The key stream is the output of a stream cipher (ones that are not reliant on the plaintext anyway). This key stream is XOR'ed (again, in general) with the plaintext to form the ciphertext. If you've got two key streams then you can just XOR both key streams and the plaintext to form the ciphertext. That way you should not convey any additional information about the plaintext contents or size (some information about the plaintext size is always leaked - in the case of stream ciphers all of it...). $\endgroup$
    – Maarten Bodewes ♦
    Commented Oct 10, 2016 at 14:41
  • 1
    $\begingroup$ Cipher A -> ZIP -> Cipher B The intermediate step of compressing is not going to do anything. A ciphertext is incompressible on average. In specific cases compression might work, but the Kolmogorov complexity is uncomputable. We just know it is bounded by the usual entropy, and is equal to it for almost all input values. $\endgroup$
    – tylo
    Commented Oct 10, 2016 at 16:46
  • 1
    $\begingroup$ @RPK No, don't use compression unless you have to. Using the PKZIP compression on different data will likely result in different size output. This will give hints to an attacker on the contents of the data. $\endgroup$
    – Maarten Bodewes ♦
    Commented Oct 10, 2016 at 16:59

1 Answer 1

Reset to default
2
$\begingroup$

What you can do is convert the block cipher into a stream cipher. You can do this by using it as primitive for a stream cipher mode of encryption such as CTR. Then you can use the resulting key streams of cipher A and B and XOR them together with the plaintext.

In principle you can also encrypt it using a block cipher mode of encryption or stream cipher in any order. This should not leave loopholes.

Compression or no compression is a tricky question. I'd say that no compression is better. As long as your plaintext doesn't leak information through the size of the plaintext, you're OK. The amount of compression is dependent on the contents and size of the plaintext.

The problem with this is that the compression factor may differ for slightly different plaintext. This means that it will become next to impossible to not leak information.

It's good if the keys are not related to each other. For best security it would also be wise to make sure that the algorithms are not related either.

The use of two ciphers to achieve confidentiality is an operation with questionable returns. Often it is more useful to e.g. use public key cryptography (in a hybrid scheme, so that the private key is not required during encryption) and/or authenticated ciphers.

Improve this answer
$\endgroup$

Your Answer

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

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