# Is AES easier to crack when the input is small?

Say you just want to encrypt a number. For example, say the number could be any double. A double in C# and Java is 8 bytes.

If you were to encrypt a double using AES (MS-Doc, defaults to CBC as the mode):

var cypherText = AES.Encrypt(123d); // 8 bytes


would that be trivial to crack? If not would it at least be significantly easier to crack than the cyphertext from a larger input:

var largeText = GetDeclarationOfIndependence(); // 6760 ascii characters, so 6760 bytes
var cypherText = AES.Encrypt(largeText);

• By "crack", do you mean back-calculate the secret key, or do you mean recover information about a message given its ciphertext?
– Nat
Sep 12, 2018 at 15:19
• I meant either back-calculate the secret key or be able to recover the input in some other way. Sep 12, 2018 at 15:23

Assuming that encryption is performed correctly:

• Using a modern cipher (AES)
• An appropriate mode of operation
• With no bugs in the implementation

then the nature of the plaintext has no effect on the security of the ciphertext.

If not would it at least be significantly easier to crack than the cyphertext from a larger input:

Actually, a longer ciphertext is technically easier to "crack" than a small one.

The reason being that the larger cryptogram provides the adversary with more known plaintext-ciphertext pairs. Attacks that do exist against modern ciphers typically require very large numbers of plaintext-ciphertext pairs.

That being said, this effect is still negligible in pretty much any realistic use case. The quantity of plaintext-ciphertext pairs required for cryptanalysis is frequently obscenely and prohibitively large.

• Also if you have a big ciphertext, it's easier to know when you got the right ciphertext. (e.g. if you know it's ascii text, just checking the high bit of each byte gives you a big clue). Sep 12, 2018 at 0:34
• @immibis: Which is why a good cryptography setup should use compression when the plaintext input cannot be assumed to be random. Sep 12, 2018 at 10:51
• @MSalters compression can actually lead to serious exploits, as the compressed length can start leaking information about the contents of the plaintext in subtle and unexpected ways (i.e. see en.wikipedia.org/wiki/CRIME for a real life example of compression gone wrong) Sep 12, 2018 at 11:32
• @MSalters Compression can be very dangerous and basically nullifies CPA-security. Take two plaintexts M_1 and M_2, where M_1 is very easily compressible (e.g. 2MB of 0's) and M_2 is almost non-compressible (e.g. 2MB of randomness). C_1 would thus be very small and C_2 be very large. Sep 12, 2018 at 15:06
• @DavidStockinger: That's a non-argument; it's fully reversible. Take two plaintexts M1 and M2 that differ massively in length before compression, but have the same length after compression. But my argument still holds if the encryption leaks message lengths in cases where that forms an attack vector: since for real inputs compression is likely, this means for real-world inputs the variation in compressed lengths is smaller than the variation in uncompressed lengths. Sep 12, 2018 at 15:20

Since you're working with a low possibility space, the absolutely critical thing is that you use Salting and/or Initialization Vectors (IV) - otherwise, what you're doing isn't secure at all.

Here's what I mean, based on various attack vectors:

Person gets access to your app code. You're hosed - I'm assuming you've got a hard-coded encryption key residing in your app. If that's the case, getting the app-code is game-over no matter what.

Person gets access to your back-end data, but doesn't have front-end access. In this case, if you're not using Salt or IV, all the '123's are going to encrypt to the same value. The attacker won't bother trying to 'crack' your encryption key - they're going to try to gather from the data based on the counts/distribution of the encrypted values. Depending on what the data represents, it might be scarily easy to make educated guesses on what each encrypted value represents simply based on its occurrence distribution.

Person gets access to your back-end data, and also has access to use your program. Now you're definitely not okay if you're not using Salt or IV. Because, in this case, the attacker can arrange circumstances to get your app to write a specific value to the database - and then simply look up what the output value is. No guessing - they just cracked all the matching entries without the key. Repeat as many times as needed to get as many values as you need.

TL;DR - You need a Salt/IV for this. Once you do that, you're good to go, and it's not going to matter that you're encrypting a small amount of bits.

• The term "salt" is not interchangeable with "IV". Salts are not relevant in this scenario. I suggest you read the Q/A "Can you help me understand what a cryptographic 'salt' is?" Sep 11, 2018 at 20:03
• I know Salts aren't the same as IVs. I really, really do. But in this situation, both will happen to achieve the condition that "Same initial value and same encryption key don't encrypt to the same output value". Sep 11, 2018 at 20:09
• Minor typo: should be "encrypt to the same value". Sep 12, 2018 at 7:45
• This seems to assume many poor practices, and is not directly related to the question. Always using an IV is of course good advice, both for short and for long messages.
– jpa
Sep 12, 2018 at 9:37

What do you mean by "crack"? Is this double supposed to be a known plaintext? If not, how could you tell when a proposed decryption is the right one? There are possibly several pairs of the form (double,key) which give rise to the same ciphertext. If the length of the plaintext is less than the unicity distance of the cipher, it might be impossible to crack, even in principle.

For the given any size of the input, the size of ciphertext generated through AES algorithm would be same. As AES is a block cipher technique, the size of each ciphertext would be the same irrespective of the input message is smaller or larger. Therefore, the adversaries cannot differentiate from the ciphertext of larger message from a ciphertext of smaller message. Moreover, you mentioned CBC mode, which is non-deterministic, i.e., even if the same plaintext is encrypted again and again, it will give different ciphertext each time. Thus, the encrypted message cannot be cracked trivially.

This might be a technicality, but certainly assuming there is no key or that the key is also small, then yes; if you're performing a brute-force attack, then certainly you'll find the original input faster if the original input is small.

• Are you positing a scenario where the attacker has the key but no ciphertext? It's not clear what a "brute force attack" is if the attacker already possesses the key. Sep 12, 2018 at 22:20
• @EllaRose sorry, yeah I was rushing. Edited!
– Ky.
Sep 13, 2018 at 0:40

No, if you use AES with different KEYs/IVs.