The Challenge
A proposed lightweight 128-bit blockcipher called MERIDIAN was evaluated as an alternative to AES for resource-constrained environments. The designers claimed it offered adequate security with lower computational overhead, making it appealing for IoT deployments and embedded payment terminals where processing power and battery life are crucial.
JP Aumasson's cryptanalysis revealed a fundamental flaw: MERIDIAN's "Directional Substitution" layer isn't injective. This means the function doesn't create a one-to-one mapping between inputs and outputs, resulting in collisions for every key across all 12 rounds. No keyed instance of MERIDIAN functions as a permutation, so no decryption function can invert encryption on all plaintexts. The cipher doesn't work as advertised.
This isn't a theoretical edge case. It's a complete failure of the core blockcipher property.
The Environment and Constraints
Payment security engineers must reduce computational overhead without compromising cardholder data protection. Point-to-Point Encryption (P2PE) solutions in contactless terminals, mobile point-of-sale devices, and IoT-connected payment hardware benefit from lightweight cryptographic primitives that consume less power and process transactions faster.
MERIDIAN targeted this market. A lightweight AES alternative could let hardware designers reduce chip complexity, extend battery life in wireless terminals, and potentially lower costs per unit. For organizations deploying thousands of payment devices, these improvements translate to real savings.
However, these constraints create risk. When evaluating cryptographic algorithms for production, you're not just assessing performance. You're validating that the algorithm provides reversible, collision-resistant encryption to protect data confidentiality.
The regulatory environment assumes your encryption works. PCI DSS Requirement 3.5 requires strong cryptography with associated key-management processes. If your chosen algorithm has a fundamental flaw preventing proper decryption, you're not just non-compliant. You've encrypted data you can't reliably recover.
The Approach Taken
Aumasson's analysis focused on the Directional Substitution layer, which should transform input blocks to preserve information. Instead, he showed an explicit collision: two different inputs producing identical outputs under the same key.
The analysis also identified a one-round differential that exceeded MERIDIAN's claimed security bound by a factor of 13.37. This differential probability indicates how likely specific input differences are to produce specific output differences. When actual values exceed claimed bounds by more than an order of magnitude, it signals either miscalculation in the original security proof or fundamental design weaknesses.
This cryptanalysis doesn't require breaking real-world implementations or mounting side-channel attacks. It examines the mathematical properties of the algorithm itself. The collision exists in the design, not in any particular deployment.
Results and What It Reveals
The finding invalidates MERIDIAN's blockcipher claims entirely. You can't deploy an algorithm that fails injectivity and expect it to function as encryption. The implications extend beyond this specific cipher:
Pre-deployment validation saves you from operational disasters. If MERIDIAN had been integrated into production payment terminals before this analysis, organizations would face a choice between using broken encryption or executing emergency firmware updates across their entire device fleet. Neither option is acceptable when handling Primary Account Numbers (PANs).
Security proofs require independent verification. The designers provided security bounds that were wrong by a factor of 13.37 for one-round differentials. This gap suggests the original analysis either used flawed methodology or made incorrect assumptions about the algorithm's properties.
Lightweight doesn't mean less rigorous. The push for efficiency in constrained environments can't compromise fundamental cryptographic properties. An algorithm that saves 30% on power consumption but fails to decrypt half your transactions isn't a tradeoff. It's a failure.
What Should Have Been Done Differently
MERIDIAN's designers should have subjected the Directional Substitution layer to rigorous mathematical analysis before publishing security claims. Proving injectivity for a proposed permutation isn't optional. It's the foundation of blockcipher design.
The broader cryptographic community needs to apply the same scrutiny to lightweight proposals as it does to general-purpose algorithms. The assumption that "it's just for IoT" can't lower the bar for mathematical correctness. IoT devices increasingly handle sensitive data, including payment credentials and authentication tokens.
Organizations evaluating cryptographic algorithms for payment applications should require independent cryptanalysis before production deployment. Your internal security team might validate implementation correctness, but fundamental design flaws require specialized expertise. If you're considering a non-standard algorithm, budget for external review.
Takeaways for Your Team
Don't deploy non-standard cryptography without independent validation. AES exists and works. If you're considering an alternative, you need a compelling reason and proof that the alternative actually functions as claimed. Performance improvements don't matter if the algorithm fails basic properties.
Understand what injectivity means for your encryption. A non-injective function creates collisions. In encryption, collisions mean you can't reliably decrypt. Two different plaintexts produce the same ciphertext under the same key. Your decryption function has no way to determine which plaintext was original.
Verify security claims against published analysis. When evaluating cryptographic libraries or hardware security modules, check whether the underlying algorithms have been subjected to peer review. Look for published cryptanalysis from researchers who aren't affiliated with the designers. If you can't find independent validation, that's a signal to proceed carefully.
Map cryptographic failures to compliance requirements. PCI DSS Requirement 3.5.1 specifies that encryption keys must be as strong as the Data Encryption Key (DEK). But if your algorithm isn't actually a blockcipher, the entire key management framework becomes irrelevant. You're not protecting cardholder data. You're scrambling it in a way you might not be able to unscramble.
Build validation into your procurement process. If you're sourcing payment terminals or encryption appliances, require vendors to document which cryptographic algorithms they use and provide evidence of third-party validation. "Industry-standard encryption" isn't specific enough. You need algorithm names, key lengths, and references to standards like FIPS 140-3.
MERIDIAN's failure demonstrates why cryptographic design requires mathematical rigor, not just engineering cleverness. For payment security teams, the lesson is straightforward: proven algorithms exist. Use them.
