16

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);
user875234
  • 263
  • 2
  • 6

6 Answers6

20

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.

Ella Rose
  • 19,971
  • 6
  • 56
  • 103
4

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.

Kevin
  • 149
  • 4
3

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.

John Coleman
  • 362
  • 1
  • 10
3

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.

Siva Kumar
  • 299
  • 2
  • 5
1

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.

Ky -
  • 113
  • 5
0

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

Leo.W
  • 318
  • 1
  • 8