Bruteforcing a symmetric cipher [duplicate]

Question

I don't understand how we could bruteforce a symmetric cipher.

Let's take AES with a key size of $128$ as an example. It means that there are $2^{128}$ possible keys, and as many ways to decrypt a ciphertext $c$. Given that there are so many different keys, it is theorically possible to decrypt $c$ into multiple plausible messages (e.g. message that read like english). So while we are bruteforcing $c$, if at some point we obtain a plausible message we can't tell for sure that we found the good key because there are plenty of other plausible messages that we haven't found yet.

It's not like with hash functions or asymmetric ciphers, where we have a way to make sure that we found the good antecedent/private key.

So I don't understand what they mean in this article: https://en.wikipedia.org/wiki/Key_size

For example:

For instance, Triple DES was designed to have a $168$ bit key, but an attack of complexity $2^{112}$ is now known (i.e. Triple DES now only has $112$ bits of security, and of the $168$ bits in the key the attack has rendered $56$ 'ineffective' towards security).

Even if Triple DES only had 50 bits of security, we would still be able to decrypt multiple plausible messages that are not the original message, let alone the case where the original message is gibberish and not necessarily natural language. I feel like the notion of "security level" is not the same for hash functions/asymmetric ciphers and symmetric ciphers. For both, it refers to the subset of the antecedent/key space that we know the good antecedent/key is in, but for the latter, we can never be sure that we have found the good secret key, and thus that we bruteforced successfully.

Could you explain it to me please? Thank you for your help.

Answer 1

You are forgetting that messages usually consist of many blocks and that many messages contain much more structure than just English text. For example an RSA private key will, when encoded, have a easy to distinguish header and will consist of many blocks of plaintext / ciphertext when encrypted with a block cipher. The same is true for Word documents, XML messages, images and many other formats.

Otherwise, it is a simple game of chance. At each block that decrypts correctly according to the available information, you get more confident that you've found the right message. However, you can choose a block for which you have the most information and only continue decrypting the next block once you've found a match. That way you can very quickly filter out wrong keys.

For instance, for English text you'll generally know at least one bit: the highest one bit of ASCII text is always zero, so that already makes 8 bits per block that you need to get right. Assume that you've got another 2 bits per byte / character simply by checking if the English text is consistent after that. Then you only need to advance to the next block once in $2^{8 \cdot 3} = 2^{24} = 16,777,216$. During the calculation of cryptographic strength, we can safely ignore that kind of detail. If the message is very small then such analysis will indeed fail, and you cannot tell if the key is correct or not. This is easy to show by looking at single bit encryption, e.g. using stream cipher mode such as CTR.

As indicated in the comments, generally we also assume that messages have integrity protection and provide message authentication, usually through authenticated cipher modes or explicit inclusion of a Message Authentication Code (MAC) / authentication tag. In that case, the correctness of the key can also be verified through that code. For most modes that add at least 64 bits to test (128 bits for most authenticated modes and 256 or more if HMAC is used).

Usually, for attacks, we assume that (part of) the message is known, i.e. known plaintext for a known-plaintext attack at the very minimum. Ciphers are expected to be even more secure than that: allowing the attacker to choose which messages get encrypted while leaking no information about the data (other then information about the message size). In other words, the ciphertext should be INDistinguishable from random under a Chosen Plaintext Attack, i.e. IND-CPA secure.