# Is encrypting credit card numbers one by one with rsautl secure?

I wish to encrypt credit card numbers one by one using asymmetric encryption on the command line. My current approach is this…

Encrypt:

/usr/bin/openssl rsautl -encrypt -inkey 'myKey.pub' -pubin | /usr/bin/openssl enc -base64


Decrypt:

openssl enc -base64 -d | openssl rsautl -decrypt -inkey myKey.pem


It is my understanding that this is secure, even when using the same key for each number, because rsautl introduces randomization to prevent finding patterns in the cyphertext.

Am I correct, and is the approach therefore secure?

-

As long as you use a secure padding mode (i.e. -pkcs or -oaep, not -raw). The default padding mode for openssl rsautl is -pkcs (i.e. PKCS#1 v1.5), so you should be OK. That said, OAEP is recommended over PKCS#1 v1.5 padding, so you might want to use the -oaep switch.

-
Just making this comment because it wasn't specified in the question - a 2048-bit key should be used as a minimum (but I'd go even higher if I were encrypting something as sensitive as credit card numbers). –  hunter Nov 7 '13 at 17:30
@hunter The actual key management is not specified. The key management procedures around the private key are very important. Key size is important, but it is only a very small part of the key management. Then again, those would be more at place at security.stackoverflow.com. For credit card numbers I would certainly first check the requirements of the credit card companies themselves. –  owlstead Nov 7 '13 at 19:03
@owlstead - yup, key size is only a small part of key management - but one that often gets overlooked with RSA - I'm amazed at the number of people still using 1024-bit keys in the wild. Thought it was worthwhile making a PSA. –  hunter Nov 7 '13 at 19:13
Great! We use a 4096 key with the public key in the codebase, and the private key on our local-network payment server. To decrypt the log, we login to the payment server and paste the cyphertext into openssl's stdin. We intend to change the key every couple years. –  cmc Nov 11 '13 at 10:48
The phrase "We intend to change the key" implies imprecision. You really should be creating a full key management lifecycle policy to comply with PCI 3.5 and 3.6, something that specifies how you will generate, distribute, store, use, retire, and destroy the keys, how long each of those states last, plans if they're compromised, etc. See pcisecuritystandards.org/documents/pci_dss_v2.pdf for the requirement, and csrc.nist.gov for advice. nvlpubs.nist.gov/nistpubs/SpecialPublications/… deals directly with creating a key management strategy. –  John Deters Nov 11 '13 at 16:55

Be aware that your solution will touch much more than cryptography. Your command shell, the account it runs on, the swap file, the whole machine falls under the purview of PCI DSS regulation and auditing.

If you can avoid storing or even handling the number, so much the better.

-
We are PCI certified so that's fine. But I agree it shouldn't be taken lightly; we decided payment processing is a core competency for us, because of the market edge it gives us in responding to customer needs combined with a software customization framework. –  cmc Nov 11 '13 at 10:44