# Json AES128: Security against known plaintext attack

I have a system where I am transmitting json messages securely (using for example AES-128), where each message has the same format.

For example

{"d":{"status":"success"}}

{"d":{"error":"Message length too long"}}


Where every plain-text message is guaranteed to start with {"d":{ and end with }}

Suppose the attacker knows this fact.

• Does this reveal information that could lead to a security exploit (the attacker finding the key)? If so, what would prevent this?

• If there is no security risk, what property of encryption prevents it from being an issue?

EDIT

This is related to my other question about the attacker knowing parts of the plain-text, but I would like to know why it isn't a problem.

-
When you say "I am transmitting json messages securely," what exactly do you mean? AES-128 does not sufficiently describe your message format. AES-128 is only capable of transforming exactly 16 bytes, so I assume you're also using a block cipher mode like CBC on top of it. Which mode are you using? Are you including an HMAC or using an authenticated mode? Are you using a password (if so, what is your KDF?) These answers have a lot of impact on the security of the system and the answer to this specific question. – Rob Napier Jan 16 '14 at 20:20
I am using the default values provided by the .NET implementation, which I believe is CBC with PKCS7 padding. – Matthew Jan 16 '14 at 22:00

Suppose the attacker knows [some part of the plaintext]

Does this reveal information that could lead to a security exploit

Given the rest of your notes, that you're using CBC mode (and depending on how you manage the IV), then yes, it can allow the attacker to modify messages such that the attacker can control the decrypted plaintext. For instance, an attacker could likely modify {"d":{"status":"success"}} to {"X":{"status":"success"}}. This could be a significant exploit or not.

(the attacker finding the key)?

Not directly. That isn't computable, even if you know the full plaintext and ciphertext. While the math is slightly different, this is similar to the problem of coming up with a plaintext that generates a given SHA-256 hash. AES is intended to make this computation no more efficient than a brute-force search.

However, if you are using a password to generate the key, and your KDF is incorrect, then there are definitely very good attacks against the password, and through it, the key. Knowing things about your data format will make these attacks faster (and if you fail to create a proper IV, they will be even faster). There are a lot of little pieces to correct AES encryption. If you get any of them wrong, then all the "AES is unbreakable" claims go out the window. Properly Encrypting With AES With CommonCrypto covers the main issues. They are the same for .NET as they are for ObjC.

If so, what would prevent this?

To the initial problem (data integrity / authentication), as Simon Johnson says, ideally use an authenticated mode such as CCM or GCM rather than CBC.

Alternately, if you do not have an authenticated mode available, use an HMAC to authenticate your data and demonstrate that it has not been modified. I would recommend draft-mcgrew-aead-aes-cbc-hmac-sha2 as a good approach to this. RNCryptor is similar and designed to address this issue, but there is not yet a C# implementation. (If you are interested in this problem, it is very easy to implement the RNCryptor data format in C#, and I'd be happy to work with you to build an open source version.)

If there is no security risk, what property of encryption prevents it from being an issue?

Let us consider the more basic version of this question. Get rid of block cipher modes, IVs, authentication, etc. Let's get back down to just AES. All AES does is transform 16 bytes into a different 16 bytes.

Encrypting with a key K and plaintext P yields a ciphertext C.

E(K, P) = C


For AES, there exists an efficient inverse of E called D such that:

D(K, C) = P


This just says that it is possible to encrypt something with a key, and then decrypt it with the same key. I.e.:

D(K, E(K, P)) = P


What you're asking for is some efficient function X such that:

X(P, C) = K


There are many functions E and D for which an efficient X exists. For example, if E is the xor function, then D is also the xor function and X interestingly enough is also the xor function. However, the AES function is such that there is no known efficient X (I don't believe that this is currently proven, but we certainly do not know what that X is).

This is a very long-winded way of saying that there is no known Known-plaintext attack on AES.

(I'm making a somewhat sloppy and broad claim here. There are some known attacks against AES that are not related to known-plaintext. There is a known attack that can recover an AES-128 key in complexity 2^126.1, which for cryptographers is a really powerful finding, but for most common uses is not a major concern.)

-
This is great information, thank you for your help – Matthew Jan 17 '14 at 18:44

Provided the that you're using AES correctly then it won't be an issue. When used in the correct mode of operation AES is secure against known plaintext attacks.

In fact, it's even secure when the attacker can choose the plaintext you encrypt and examine the resultant cipher-texts. All modern ciphers is designed to be secure even in the face of attackers with this level of power.

You'll want to use AES in GCM mode so that you protect both message integrity and privacy. It's good practice to protect integrity as well as privacy, but in this particular case it takes on particular importance.

If you don't protect integrity properly, then you open the door to chosen cipher-text attacks. Trust me when I say that they can really ruin your day!

-
Thank you for the note on GCM – Matthew Jan 17 '14 at 18:48