Does the entire AES encrypted dataset have to be present to be 'cracked'?

Question

I am implementing an AES 256 algorithm on credit cards and I am wondering if I would be strengthening or weakening the encrypted dataset if I split the dataset and persisted it in two locations. I don't understand AES algorithm enough to know if 'all bits must be present for cracking' or if a subset of the encrypted data actually makes it easier to crack.

Here is the scenario:

Text to encrypt: 4798531212123535

Algorithm: AES256

Key: b0882e32f1194793800f4f0b43ddec6b273d31aafc474c4c8a3d5ae35b3e104b

Encrypted data: GoCN4o35w4vzU4hQp47CLUgsTgaxRvvT7qdTVh5Hl+I=

Q1: If I were to split the dataset into 2 parts and store them in 2 repositories in 2 parts of the country...If one of the parts were compromised, did I weaken the security by splitting?

Q2: A following question would be: if the partial dataset & the key were compromised, can the key be used to decrypt part of the dataset or does the entire dataset have to be present to win?

Part 1: GoCN4o35w4vzU4hQp47CLUgs

Part 2: TgaxRvvT7qdTVh5Hl+I=

------------ Added for clarity --------------

If Part 1 and the Key were compromised, would the result of decryption result in anything of value? Would the result be a correct sequence of characters?

Compromised values:

Part 1: GoCN4o35w4vzU4hQp47CLUgs

Key: b0882e32f1194793800f4f0b43ddec6b273d31aafc474c4c8a3d5ae35b3e104b

Would the decrypted value be something like: 47985312 (which is a sequence of the original)

Answer 1

You are doing it wrong. Not in the splitting or whatever; but in the thinking. AES encryption, if done properly, won't be "cracked". AES is the most robust piece in your system; this is the last part of it that you should be worrying about.

What AES encryption provides is a very specific functionality: using a given key K, it transforms a piece of data (the "plaintext") into something that is unreadable (the "ciphertext") except to those who know K, because knowing K allows for reversing the transformation. As long as K remains unknown to attackers, the encrypted data is safe. If K is known to attackers, then they have won, and no amount of splitting, or swapping, or dancing around a fire while chanting the glory of the Great Spirit, will save you.

AES uses keys of 128, 192 or 256 bits. There are so many possible keys that probability of an attacker compromising the key through pure luck is infinitesimal. 128-bit keys are sufficient for that; larger keys are not meant to increase security but to assert your status of alpha male among your fellow developers.

If you really need to engage into elaborate data-shuffling rituals so that, for instance, your boss gets the impression that "security is happening" and you are not slacking away, then you may as well do it properly. Don't split; instead, given a sequence of bytes C (the encrypted string), generate a sequence of random bytes D of the same length; then "split" C into two shares C₁ = C XOR D, and C₂ = D. To assemble the shares, just XOR them together: it so happens that C₁ XOR C₂ = C. That kind of splitting is demonstrably secure (an attacker who learns C₁ or C₂, but not both, learns exactly nothing, in an information-theoretic sense, which is about as good as any crypto can get). Provided, of course, that you don't botch things (you MUST generate a strongly random D, and generate a new one each time you have some string to "split").

Answer 2

You should be worrying about secure storage of the AES key, not about breaking up the data. If the key is compromised, it really won't make any difference what you've done with the data because Kerckhoffs's principle.

Edited to add: Most especially, you must not store the AES key in the same database that holds the encrypted data because a database compromise will yield both key and data. Remote database compromises, e.g. by SQL injection, are sometimes possible even when the entire OS is not compromised. Storing the key elsewhere is part of defense in depth. Ideally it would be stored using a hardware security module (HSM), but compiled into a program or even as a file in the file system is far better than storage in the database.

Answer 3

May I suggest that you rethink your approach to this problem. Where are you storing the data? If it's in a database most databases have the ability to encrypt data at rest fairly securely. Does the data need to move over an insecure channel? Look into the HTTPS or secure FTP. Don't mess with crypto unless you absolutely have too. It's extremely easy to get wrong.