# Make AES more secure by randomising the blocks in an encrypted file

I am developing a software with hybrid encryption (RSA-4096 and AES-256-CBC). The iv and key of an AES encrypted file will be RSA encrypted end exchanged through a different way than the encrypted file. Thats ok for me to this point.

I am thinking about where it is most easy to break the encryption of my own files and always come to the point where a key and iv guessing would take ages but is theoretically easy. It just takes time with the computing power we have today.

In my application the transfer of the encrypted file will not be possible if there are bits lost in any case.

Version 1: Since CBC is always based on the the pre block, why do I not just change the order of the blocks in the file and write a map together with the key and iv into the RSA part? Is this a stupid idea?

Version 2: Why do I not just replace a random character in each AES block with its "value" + 1 or so and write into my RSA a map of the chawed characters?

In my opinion in Version 1 the "guessing power" would be the "AES blockcount"*"time for a single file" and after that the order would sill be wrong. I have no idea what effort it would take to get the right order...

In the second Version it would be even to hard for me to calculate. It could be any bit in a block with a wrong value and a guessing of iv and key per block.

Does that make sense? Who knows about the computing power we will have in a few years. And I also don't want people to read the files in a few years ;-)

TL,DR: No, don't do it. Use a standard protocol and don't write your own implementation. If you're thinking at the level of AES, CBC and RSA, you're doing it wrong. I recommend crypto_box.

I am developing a software with hybrid encryption (RSA-4096

RSA-4096 is ok if done right. Done right means OAEP or RSA-KEM. PKCS#1v1.5 is theoretically possible to get right, but very difficult because it is prone to oracle attacks. A lack of padding or homegrown padding is plain broken. ECIES gives you as much or better security at much better performance, and typically fewer risks of getting it wrong due to insecure parameters.

and AES-256-CBC).

Unauthenticated modes are dangerous because they are prone to oracle attacks. Even PGP got it wrong. Don't use unauthenticated modes. And especially don't use CBC, which has padding, which allows even more oracle attacks.

You might think you don't care about authentication, but you're probably wrong. If someone can send fake messages, that does help them obtain the content of confidential messages. The efail attack on PGP works by piecing parts of legitimate messages into fake messages and having the fake messages (attempt to be) decrypted. Use GCM or CCM instead (or use ChaCha20_Poly1305 instead of AES-GCM or AES-CCM). (But as I said earlier, what you should really be using is something like crypto_box.)

Also note that using authenticated encryption prevents oracle attacks at the level of the symmetric cryptography, but it doesn't prevent similar attacks at a higher level, since an attacker can make up their own symmetric key and send whatever they want by encrypting their own symmetric key with the public key. You should sign messages (sign (a hash of) the plaintext) with a separate set of asymmetric keys, where the sender holds the private key and the recipient knows the sender's public key (or can get it from a reliable source).

The iv and key of an AES encrypted file will be RSA encrypted end exchanged through a different way than the encrypted file.

You can, and typically should send the IV with the file. The IV doesn't need to be confidential. The AES key is encrypted with RSA (that's how hybrid encryption works) and the encrypted AES key is typically sent with the file. The RSA private key is typically never transmitted at all: that's the point of asymmetric cryptography.

You do need to take care of transmitting the public RSA key separately, but that's a whole different issue which I won't go into here.

I am thinking about where it is most easy to break the encryption of my own files and always come to the point where a key and iv guessing would take ages but is theoretically easy. It just takes time with the computing power we have today.

No, guessing the key is the hardest way to break the encryption. Nobody can break AES by guessing the key. It's theoretically easy, but practically impossible because it takes far, far more time than you have. If you took all the existing computing power on Earth now (yes, including NSA's) and ran it for the current age of the universe, you would still not stand a good chance of guessing an AES-128 key.

The way cryptography gets broken in the real world is not because the building blocks are weak, but because people take strong building blocks and assemble them badly.

Version 1: Since CBC is always based on the the pre block, why do I not just change the order of the blocks in the file and write a map together with the key and iv into the RSA part? Is this a stupid idea?

You can only send a limited amount of extra data in the RSA part, so that would limit the size of the message. For a very short message (up to about 15–20 blocks — $$\log_2(15!) \approx 40$$, $$\log_2(20!) \approx 61$$), all possible permutations can easily be enumerated, so you have no security gain. For longer messages, what do you gain? The attacker has undecipherable blocks in some unspecified order. They're undecipherable anyway. The attacker can't even distinguish between the blocks.

So maybe you have extra security in case something else is broken? Think again. If the permutation gives extra security, it can only be because the attacker cannot distinguish between the blocks: otherwise that means the attacker can reconstruct the permutation. And if something else is broken, broken means that the attacker does have extra knowledge about the blocks. This extra knowledge isn't absolutely guaranteed to let the attacker know which order to put them in, but it's likely to help.

So the offshoot is that no, you're very unlikely to gain anything. What do you have to lose? Well, once again, where cryptography gets broken is because the building blocks are misused. Every extra complexity that you add increases the attack surface of both your protocol, and your implementation. Doing extra stuff makes your protocol less secure, not more.

Version 2: Why do I not just replace a random character in each AES block with its "value" + 1 or so and write into my RSA a map of the chawed characters?

For pretty much the same reasons as version 1, this has a cost and no advantage. You'd just be increasing the attack surface to make indistinguishable blocks indistinguishable.

Who knows about the computing power we will have in a few years.

To be resistant to quantum computers in case they actually become useful to break cryptography, use AES-256. Quantum computers basically halve the effective key size of symmetric algorithms. AES-128 is good against classical computing but fails to a quantum computer that's able to perform about $$2^{64}$$ (a few billion billions) operations.

The asymmetric part is more problematic. We don't have a widely accepted asymmetric encryption algorithm that would resist quantum computers.

But by far, the biggest risk in what you want to do is design and implementation mistakes. The worst thing you can do is to devise your own protocol. What you should do is:

• Use an existing, vetted implementation of an existing, vetted protocol. To encrypt some data with an asymmetric key scheme, crypto_box has a good reputation.
• Be agile: prepare to upgrade your protocol if it gets broken.
• CBC sucks not only because of padding oracle attacks but also because it doesn't provide any authentication whatsoever. – SEJPM Jul 28 '19 at 13:44
• @SEJPM Right, I didn't even get into authentication. But the padding oracle attacks are possible pretty much because CBC doesn't do authentication. Though I should mention what do use instead of CBC (well, ok, it's crypto_box, but that's at a different level). – Gilles 'SO- stop being evil' Jul 28 '19 at 13:46
• To have full message authenticity you should sign the ciphertext or plaintext. An adversary could otherwise simply generate his own ciphertext using the public key. AEAD schemes or MAC is not going to protect you against that kind of attack. An AEAD scheme could be used to maintain confidentiality (no CBC style plaintext/padding attacks) and integrity, but not authenticity. – Maarten Bodewes Jul 28 '19 at 14:41
• I thought PGP used CFB, not CBC. It's S/MIME that uses CBC. – forest Jul 29 '19 at 6:05