Storing credit card data using mcrypt or GnuPG

Question

I have a requirement to store credit card information (do not store this is NOT an option).

Using mcrypt with mcrypt_dev_random to generate init_vector requires different ages for encryption / decryption, but seems to be the most "secure" option. mcrypt_dev_urandom is MUCH faster, but not suitable for long-term storage - as I read.

Looking at GnuPG as a possible alternative, and I would like, if possible, to express opinions / lead them.

Answer 1

If you really want to keep credit card information safe, there is a standard for it: Payment card data security standard . And this is much more than using one specific encryption algorithm. It requires you to store some card details on two physically separate machines, among many other things. And even if you follow the PCI standard for writing, experts say that you are still not completely protected. Something less than this is largely not worth discussing in detail, since the overall level of security is so low that it hardly matters.

Answer 2

Remember: the first rule of cryptography is "do not do it yourself."

MCRYPT_DEV_URANDOM enough for strong encryption , but "managing credit card information" is much more complicated than just "encrypting" everything and letting God figure out his own. "P>

The fact that “non-storage is not an option” sounds to me as if you (or better, those above you) are doing it wrong. You should not research this or offer a solution. Don't be a fall guy.

https://www.pcisecuritystandards.org/merchants/how_to_be_compliant.php

Answer 3

The most important question for you is: what do you need for PCI compliance. Do not encrypt homegrown. Read what it requires and prefer to delegate credit card material to a specialized payment processor.

Using mcrypt with mcrypt_dev_random to generate init_vector requires different ages for encryption / decryption, but seems to be the most "secure" option. mcrypt_dev_urandom is MUCH faster, but not suitable for long-term storage - as I read.

This shows some misunderstanding. For one IV one does not need to be secret. The quality of random numbers is less important.

But even for the keys /dev/urandom is good enough if it was originally seeded with enough entropy.