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
  • 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 '18 at 15:19
  • I meant either back-calculate the secret key or be able to recover the input in some other way. – user875234 Sep 12 '18 at 15:23

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,603
  • 6
  • 53
  • 101
  • 1
    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). – user253751 Sep 12 '18 at 00:34
  • @immibis: Which is why a good cryptography setup should use compression when the plaintext input cannot be assumed to be random. – MSalters Sep 12 '18 at 10:51
  • 6
    @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 https://en.wikipedia.org/wiki/CRIME for a real life example of compression gone wrong) – Thomas Sep 12 '18 at 11:32
  • 1
    @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. – MechMK1 Sep 12 '18 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. – MSalters Sep 12 '18 at 15:20
  • @MSalters Look up CRIME and BREACH. – user253751 Sep 12 '18 at 22:20
  • @immibis: The key to CRIME is that you leak unencrypted plaintext compression state to the attacker. It wouldn't have been an issue if the plaintext and the attacker text would have been compressed separately. – MSalters Sep 14 '18 at 09:45
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
  • 9
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
  • 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. – Ella Rose Sep 12 '18 at 22:20
  • @EllaRose sorry, yeah I was rushing. Edited! – Ky - Sep 13 '18 at 00:40
0

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

Leo.W
  • 318
  • 1
  • 8