Storing encrypted direct debit details with RijndaelManaged [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

This question does not appear to be about programming within the scope defined in the help center.

Closed 8 years ago.

Improve this question

I'm by no means a security expect and would like some help/pointers on the following scenario. Just to be clear, this question is more about encryption than bank details.

I'm needing to store UK direct debit details in a secure way in order that it can be sent off to a payment provider for tokenization. At the moment I'm using RijndaelManaged with a 256 bit key and unique IV's for each piece of information (account name, account number and sort code). The key is not stored with this information.

The question I've got, and taking sort code as an example, is that we know that UK bank sort codes are just comprised of numbers and are only 6 digits long. So there's a very small set of them that exist, thus a dictionary could easily contain every single one.

If the database that is storing this information was compromised and dumped, how easy would it be to decrypt the information, given that the IV's are stored alongside each encrypted sort code, the RijndaelManaged algorithm is well known and there are only 999,999 sort codes to check ?

In addition, if the only 'unknown' to an attacker is the private key, as lets say, he already knows a particular sort code, could the private key be ascertained ? I don't believe it could without doing quite a few calculations, but I'm not sure...

I was thinking that padding the sort codes with random characters would make decrypting this information harder, but then this padding would also need to be stored somewhere.

Answer 1

It is not possible to decrypt the data without knowing the secret key. A dictionary attack is not possible either because the dictionary would entirely depend on the key. However, it is worth keeping in mind that if an adversary obtains the key, he can decrypt the whole database.

There's no need to pad the plaintext with random data, because the initialization vector does basically the same thing.

However, there are many important requirements and regulations for storing and handling card data. Not properly adhering to them may leave you open to various legal threats or other expensive sanctions. Rather than risking that, many choose to leave all the complex stuff to a payment processor.