0
$\begingroup$

Example:

message = 'sup'

// encrypt
cipher = aesencrypt(aesencrypt(aesencrypt(message, 'CFB'), 'CTR'), 'OFB')

// decrypt
message = aesdecrypt(aesdecrypt(aesdecrypt(cipher, 'OFB'), 'CTR'), 'CFB')

if it's not a possible vulnerability, it'd just rather use all 3 than decide on one.

$\endgroup$
9
  • 4
    $\begingroup$ Why? They all have different properties. Pick the one that suits your needs. $\endgroup$
    – Marc
    Aug 3 '20 at 16:23
  • 2
    $\begingroup$ Can you explain why you would like to use all three? Their properties are substantially different. $\endgroup$
    – Cort Ammon
    Aug 3 '20 at 16:24
  • $\begingroup$ i want all the worst properties. to make decryption as slow and annoying as possible. no parallelization allowed etc. so in that case does layering those 3 make sense? i'm doing cold storage backup encryption $\endgroup$
    – Farzher
    Aug 3 '20 at 16:29
  • $\begingroup$ @Farzher Well, what you've described is still quite parallelizable. It's not slow, although it woudl be annoying for those who use it. Have you considered using an encryption algorithm which is designed to be slow instead of using one of the fastest most parallelization algorithms to date? We have created algorithms whose sole purpose is to have the properties you seek. $\endgroup$
    – Cort Ammon
    Aug 3 '20 at 16:33
  • 5
    $\begingroup$ First of all, your scheme is incomplete as you don't specify how the keys and IVs need to be handled. Second, you're basically creating your own mode, and in that case you should indicate why it is more or at least as secure than each one mode by itself, and we can then shoot at your proof. Just combining modes willy-nilly cannot be claimed to be secure. $\endgroup$
    – Maarten Bodewes
    Aug 3 '20 at 16:59
4
$\begingroup$

When combined with your comments, I can say this is unsafe in the sense that it is highly advised against "rolling your own encryption."

It looks to me like you are layering multiple encryption methods together without too great of a concern for understanding the attacks made against them. Is this secure? Maybe. In theory, we designed these algorithms sufficiently well that your outermost layer provides you enough protection. Of course, in that case, all your layering really isn't making you more secure.

In general, it is recommended that you use one algorithm, the way it is typically used. Then, if you identify a particular attack vector you care about which isn't handled by that algorithm, you can look at a careful layering. For example, you specifically want a slow algorithm for hashing the key. You then may layer PBKDF2-256 onto your process in order to achieve that specific goal.

In theory, AES was well designed enough that you can get away with layering, and the strength of the encryption you have is at least as strong as the outer layer. However, if you are layering encryption schemes without thinking through the threat model carefully, you could get unlucky and break a key feature of one layer with a feature of another. Its not the layering that's the issue, but rather the mindset that layering makes it stronger that is the issue. This is not always provably the case, and it puts you at risk for future decisions you might make, thinking you are making the product stronger.

A test you can give yourself: If I want to do X in cryptography, do I see any commercial or open source libraries doing X? If not, that's a sign that what I'm doing is unorthodox and may not be as secure as I think it is.

$\endgroup$
11
  • $\begingroup$ i understand. i'm already layering hashing algos which makes sense to avoid future ASICs, etc. i just decided to do a similar thing with AES, instead of deciding on one mode, no reason to not use them all, right? (which was my question) $\endgroup$
    – Farzher
    Aug 3 '20 at 17:01
  • $\begingroup$ i've seen examples of layering encryption undoing the encryption, because of xor type stuff. i just want to make sure that's not happening here $\endgroup$
    – Farzher
    Aug 3 '20 at 17:02
  • $\begingroup$ There's a reason not to layer block cipher more as explained by Cort. The same reason applies to layering password hashing. Don't ignore Maarten's comment either. $\endgroup$
    – Marc
    Aug 3 '20 at 17:08
  • $\begingroup$ What ASIC attack do you think you are thwarting with chaining these modes together? $\endgroup$
    – Cort Ammon
    Aug 3 '20 at 17:10
  • 1
    $\begingroup$ Backup your claim. $\endgroup$
    – Marc
    Aug 3 '20 at 17:16
2
$\begingroup$

A secure cipher is required to produce ciphertexts that are computationally indistinguishable from random strings, so somebody might naïvely think that this is sufficient for your iterated ciphers to be safe. But no, it's not sufficient, because for the iteration to be safe the ciphers also need to be statistically independent of each other.

On trivial example of this would be if you encrypt a message with a one-time pad, and then encrypting the output with the bitwise negation of the same pad. The output is going to be the bit-flip of the original plaintext.

Applying this to your example, the big concern here is you don't specify what key(s) you're using for the encryption operations. If you want maximum assurance that this is safe, you would want each encryption to be done with an independent key. This guarantees that there can't be any problems where the ciphers interfere because they're using the same AES key.

One very simple example is that if you use the same key $K$ and same $\mathrm{IV}$ for both CFB and OFB, the encryption of the first plaintext block $P_1$ is exactly the same in both modes:

$$ C_1 = \mathrm{AES}_K(\mathrm{IV}) \oplus P_1 $$

So the composed double encryption of the same $P_1$ would be:

$$ C'_1 = \mathrm{AES}_K(\mathrm{IV}) \oplus \mathrm{AES}_K(\mathrm{IV}) \oplus P_1 = P_1 $$

...which is the same as the plaintext block, because of course, you've effectively encrypted and decrypted that block.


And, as other answers and comments have pointed out, there's little point to doing any of this. Don't roll your own, it's a minefield. If you really needed to make encryption and decryption slow (why?) there'd be better ways of achieving that, using password mangling functions like Argon2 as key derivation steps.

$\endgroup$

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.