# Staying PCI compliant while upgrading encryption

I am trying to migrate my encryption methods, currently I use RSA 1024 key size and hashing with SHA-1.

This configuration is going to be deprecated soon, but 2048 key size will have my system so slow and heavy transactions. Therefore, I am thinking about keeping RSA 1024 but hashing with SHA-256 (more secure and recomended by PCI).

Does anyone know if this configuration is PCI compilant? Would I have trouble getting certificates with it?

• Ignorant question ("ignorant" as I have never worked in the payment industry, and so I don't know what flexibility PCI, or real life PCI-compliant equipment allows), would ECC be a possible option? ECC has significantly smaller ciphertexts, and smaller computational requirements than the RSA private operation, and so if PCI allows that, they might possibly be a viable alternative to stepping to 2k RSA... – poncho Aug 11 '16 at 14:35
• @poncho: I'm not a PCI-DSS practitioner; but on crypto strength, their requirement are mainstream; the glossary asks for "Cryptography based on industry-tested and accepted algorithms, along with key lengths that provide a minimum of 112-bits of effective key strength and proper key-management practices", citing "AES (128 bits and higher), TDES/TDEA (triple-length keys), RSA (2048 bits and higher), ECC (224 bits and higher), and DSA/D-H (2048/224 bits and higher)" as currently compliant. – fgrieu Aug 11 '16 at 14:52
• I'd personally recommend you to upgrade your system. The only reason why RSA 2Kib would be too slow is if you are using a slow smart card based system. With OpenSSL or a HSM the speed of RSA should not pose a problem (unless you're going over 4Kib keys anyway). Don't forget to use CRT parameters for your private keys (multi-prime is often not available). Oh, and SHA-512 will be faster than SHA-256 on 64 bit systems. – Maarten Bodewes Aug 11 '16 at 15:51
• Thanks, but this system is about payment devices (32 bits system) and I don't think it support over SHA-256. – santiPipes Aug 11 '16 at 16:10
• On 64-bit systems I tested an iPhone 6S and Quad-Core Intel Xeon 2.8 SHA-512 vs SHA-256. 1KiB data size: iPhone SHA-512 5.3x times slower, Xeon 2.8 GHz SHA-512 1.2 times slower. 100KiB data size: iPhone SHA-512 1.8x times slower, Xeon 2.8 GHz SHA-512 1.2 times faster. I'm sure there are other CPUs where opposites are true. – zaph Aug 15 '16 at 19:33

Supplementing RSA-1024 with SHA-256 instead of SHA-1 won't cut it from a PCI-DSS compliance standpoint: RSA-2048 is a minimum for a large class of uses according to PCI-DSS's definition of

Strong Cryptography: Cryptography based on industry tested and accepted algorithms, along with key lengths that provide a minimum of 112-bits of effective key strength and proper key-management practices (..)
At the time of publication, examples of industry-tested and accepted standards and algorithms include AES (128 bits and higher), TDES/TDEA (triple-length keys), RSA (2048 bits and higher), ECC (224 bits and higher), and DSA/D-H (2048/224 bits and higher). See the current version of NIST Special Publication 800-57 Part 1 for more guidance on cryptographic key strengths and algorithms.
Note: The above examples are appropriate for persistent storage of cardholder data. The minimum cryptography requirements for transaction-based operations, as defined in PCI PIN and PTS, are more flexible as there are additional controls in place to reduce the level of exposure.
It is recommended that all new implementations use a minimum of 128-bits of effective key strength.

Also, just switching from SHA-1 to SHA-256 arguably would not help against real attacks: as a general rule, a security chain can only be as strong as its weakest link; and in many usage patterns, second-preimage (rather than collision) is what matters, making RSA-1024 a weaker link than SHA-1 is.

Addition following comment: SHA-1's collision resistance is weaker than RSA-1024. But in most applications, a successful attack requires breaking the hash's second preimage resistance, and SHA-1 remains extremely strong against that. There are a few exceptions where breaking collision resistance matters, like attacking an hypothetical certification authority still issuing SHA-1 based certificates and using predictable certificate numbers; but notice that from the standpoint a PCI-DSS entity, using a strong hash does not help protect from this hypothetical attack; what matters is that acceptors of certificates reject certificates made with SHA-1 (or reject certificates issued by authorities that do not have a policy stating that when they issue certificates based on SHA-1, they use an unpredictable certificate number).

• I'm with you until that last statement. It depends on how SHA-1 is used, but for generic signatures I would consider SHA-1 more of a risk than RSA, especially if many keys are used. The cost of factoring RSA for each private key is likely much higher than breaking SHA-1 if the current attacks are extended. At least the RSA algorithm itself is secure (until Quantum Computing really arrives, anyway). – Maarten Bodewes Aug 11 '16 at 15:48

Core to PCI is "appropriate controls" so you always have the option of strengthening a compensating control to account for a weak control. This could include updating intrusion detection, better perimeter controls etc.

While updating SHA is useful, you'd be better off updating both RSA and SHA but at the end of the day, your QSA can give the best guidance on how this fits in your environment (because it is dependent on your particular circumstances)

My advice: your best long term plan is to treat this as an opportunity for an upgrade. Bring your systems up to date so they can cope with 2048bit keys.

• Thanks for the comments, I was really afraid about that solution. In this system all increase in the size of the message means more time and size of them. I more this topic than the development effort. – santiPipes Aug 11 '16 at 14:29

Upgrade to ECDSA or (even better) EdDSA. Much faster, and even more secure than RSA-2048.

If you get sued after an incident it may demonstrate some effort? Giving you the benefit of doubt here. However sha256 by itself won't really move the needle for the security of the overall system. I don't expect you to get much leeway in audits too.

You/your business should have upgraded these system sometime back (RSA 1024?) but that won't help now so some thoughts:

Software options:

1. Quickly migrate to RSA2048 (replace calls for 1024 with 2048), measure lost revenue due to transaction overload.
2. Upgrade to elliptic curve cryptography. This could be challenging since older devices don't have the best crypto library support. Plus your crypto pipeline and key management could change (= more design work).

Hardware options:

1. Upgrade units for faster performance to maintain (and future plan) for transaction capacity. You can compare with lost revenue to see if this makes sense.

2. If your estimated lawsuit and audit expenses (typically $6M and$80k resp) are far less than any engineering upgrades and operational roll outs (very unlikely), again do nothing.