Why This Question Matters
Fintech security teams are buzzing after a cryptography workshop introduced MD-Hill-SPN, a new Hill cipher. This cipher achieves full plaintext avalanche from round 1 and boasts impressive metrics by round 4. Teams are questioning if they should be concerned about their current AES-256 setups and what "memory-hard key derivation" means for compliance. Here's what you need to know.
Should You Care About Hill Ciphers for PCI DSS Compliance?
No, Hill ciphers aren't relevant for PCI DSS compliance.
PCI DSS Requirement 3.5.1 mandates strong cryptography using industry-accepted algorithms like AES-256 and RSA-2048, validated under FIPS 140-3. Hill ciphers, including MD-Hill-SPN, don't meet these criteria.
Focus on the evaluation methodology. MD-Hill-SPN underwent rigorous testing, similar to what your cryptographic modules should pass. If your vendor can't explain their implementation's resistance to differential cryptanalysis or the performance of their S-boxes, that's a documentation gap. Your compliance evidence should reference FIPS 140-3 validation, not experimental ciphers. Understanding cryptographic evaluation helps you ask better questions during vendor assessments.
What Is a 'Memory-Hard' Key Derivation Function?
Memory-hard KDFs require attackers to use large amounts of RAM per guess, making brute-force attacks costly.
NIST SP 800-63B recommends password-based KDFs that resist hardware-accelerated attacks. Argon2 and scrypt are memory-hard; PBKDF2 is not. If you're deriving Data Encryption Keys (DEKs) from passwords, attackers with a GPU farm can test millions of PBKDF2 candidates per second. With Argon2, they might test thousands.
MD-Hill-SPN uses a memory-hard KDF in its key schedule. This reflects current thinking: key derivation should be the bottleneck, not the cipher rounds. If your system derives encryption keys from merchant credentials, audit your KDF. If it's SHA-256 iterated 10,000 times, you're not memory-hard, and you should document that risk.
Is AES Still Enough?
Yes, AES-256 remains the industry standard.
MD-Hill-SPN shows that a Hill cipher can achieve properties comparable to modern block ciphers, but it doesn't replace AES. Your focus should be on implementation, not algorithm choice. Breaches often occur from poor key management, not cryptanalytic attacks on AES. Review your Key Encryption Key (KEK) rotation, verify your FIPS 140-3 module boundaries, and ensure your Point-to-Point Encryption (P2PE) uses authenticated encryption modes like GCM.
If you're doing this, you don't need to replace AES. Just keep doing it correctly.
What Are 'Branch Numbers'?
Branch numbers measure diffusion: how many output bytes change when you modify input bytes.
An MDS cipher achieves the theoretical maximum. MD-Hill-SPN reports branch numbers at the Singleton bound, meaning changing one input byte guarantees maximum output byte changes. This matters if you're building a custom data masking solution. Low branch numbers mean an attacker can predict unchanged output bits.
For commercial solutions, this is handled. AES uses an MDS matrix in its MixColumns step. Verify your vendor didn't disable or weaken this step for performance.
How to Evaluate a New Cryptographic Algorithm
Look for peer review, standardization, and implementation diversity.
MD-Hill-SPN is an ePrint preprint by one author. It reports strong results but hasn't undergone NIST's cryptographic competition or widespread implementation. AES went through a public competition and extensive research. That's your baseline. If a vendor proposes a "proprietary encryption algorithm," ask:
- Where's the published specification?
- Who's reviewed it besides the inventors?
- Which FIPS 140-3 modules implement it?
- What's the migration path if it's broken?
If they can't answer, you're evaluating vendor lock-in risk, not cryptography.
Should You Wait for 'Better' Encryption?
No. Deploy proven cryptography now and design for algorithm agility.
Cryptographic agility means you can swap algorithms without rewriting your application. Store a cipher suite identifier with each encrypted record. Use abstraction layers to rotate from AES-256-GCM to ChaCha20-Poly1305 without touching business logic.
If MD-Hill-SPN or another cipher matures, you'll be ready to adopt it. If AES remains dominant, you haven't lost anything. Delaying encryption leaves Primary Account Numbers (PANs) in plaintext.
PCI DSS Requirement 3.5.1 says use strong, industry-accepted cryptography. That's AES today. Implement it correctly, document your key lifecycle, and build infrastructure to change algorithms as standards evolve.
Where to Go for More
NIST's Cryptographic Standards and Guidelines page tracks algorithm recommendations. The IACR ePrint archive publishes cryptography research, including the MD-Hill-SPN paper. For production guidance, NIST SP 800-175B covers key derivation, and FIPS 140-3 defines cryptographic module requirements.
Focus on operational excellence: correct implementation of proven algorithms, not early adoption of experimental ones. If your team can explain your current cipher modes, key rotation procedures, and FIPS validation status, you're ahead of most in the industry.
