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

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)

• What cipher mode are you using? – Deer Hunter Dec 19 '14 at 16:20
• The cipher code will be: AES-CBC – troy r Dec 19 '14 at 16:46
• Such in-depth questions about cryptography algorithms should be better asked on cryptography.stackexchange.com – Philipp Dec 19 '14 at 17:02
• This probably would go without saying, but I hope that's not a real credit card number ;-) – David Z Dec 19 '14 at 22:15
• Since you're storing credit card numbers, are you intending to be PCI compliant? What is your threat model (e.g., what kinds of attacks are you attempting to thwart)? How are you managing your encryption keys? – Stephen Touset Dec 20 '14 at 3:59

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 C1 = C XOR D, and C2 = D. To assemble the shares, just XOR them together: it so happens that C1 XOR C2 = C. That kind of splitting is demonstrably secure (an attacker who learns C1 or C2, 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").

• If the PRNG used to create D has a flaw, what are the security consequences (aside from "perceived security is now less than actual security")? Is it reduced below where it was with just C, or does security just revert to the security of the AES encryption with the issue that you think it's the security of the split? – cpast Dec 19 '14 at 19:24
• If the PRNG output is in some way predictable by attackers, then the security properties achieved by the "splitting" are reduced, possibly lost completely -- at which point you still have an AES-encrypted string, which should resist until the end of times (unless the encryption key can be guessed, e.g. it was generated with the same flawed PRNG; or the library that uses AES to "encrypt a string" turns out to do something stupid, e.g. CBC with a fixed IV for all strings). – Tom Leek Dec 19 '14 at 20:07
• I guess the really worst case scenario is that through some spectacular buffer-overrun error in your awful, awful home-brewed PRNG code, D ends up being always equal to K ;-) – Steve Jessop Dec 19 '14 at 20:47

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.

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.