1
$\begingroup$

I'm trying to use super encryption (also known as “multiple encryption”) with AES in CFB mode with IV and password salting and AES in CTR mode both without padding. I first use AES CFB and then AES in CTR mode. Will my approach compromise security in any way, or is it efficient (in terms of resource consumption, security, and speed) compared to using either one of the modes?

$\endgroup$
4
$\begingroup$

Since you are deriving the key from a password, there is generally not a security advantage to using multiple encryption in the way you described. The entropy of key material generated is less than the maximum security provided by AES, which means an attack on the password will be more effective than a generic key recovery attack on the cipher.

A devastating attack on AES will break the entire system since you are only using a single cipher. The general reasoning for using multiple encryption is that if a single cipher algorithm falls, the system does not. This means you need to use different ciphers, such as AES and Twofish.

In terms of efficiency, any multiple encryption system will be less efficient than a single cipher mode. In your case, you loose the ability to have one of your AES instances available as an in-register cipher with hardware acceleration on a single core, since there is not enough register space to hold the round keys from both instances. If you have multiple cores available this is not a problem, since the CTR stream can be generated in advance of the plaintext, but with CFB it cannot. Spreading across 2 cores using different modes will probably slow it down to less than 50% because of memory access latencies involved when combining the instances. You could keep everything on one core and hop between instances; generate chunk of CTR stream and store, then switch to CFB and use CTR stream while processing plaintext, then repeat as needed. Performing a single mode at a time on the entire plaintext will use the least processor resources, but the most memory, unless you are first writing all intermediate ciphertext to disk.

Depending on implementation, this system may be more vulnerable to a multitude of attacks. Dual AES instances use double the round subkeys, which may need to be stored in RAM rather than CPU register space. This may leave them vulnerable to skimming or cold boot recovery.

There is also more than 1 way to do this. You can perform CFB on all plaintext, then add the CTR stream. Or you can add the CTR stream to the CFB ciphertext block before it is fed back. In the 2nd way, this is equivalent to adding the CTR stream to the plaintext before CFB mode, since both use XOR. You also did not describe any type of authentication scheme, which is extremely important since neither mode is authenticated, especially in the case of stream type ciphers which are vulnerable to bit-flipping.

$\endgroup$
  • 1
    $\begingroup$ On e.g. CPUs with AES-NI this would not necessarily be much slower when encrypting than just using CFB alone, because most of the time is spent waiting on the instruction latency due to CFB-mode's serial dependency. (Not that "not much slower" is a reason to use it.) $\endgroup$ – otus Dec 30 '15 at 9:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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