NIST's post-quantum cryptography standardization process has advanced FAEST and SDitH to the third round, indicating their likely adoption in payment systems. However, new research shows that differential power analysis (DPA) attacks can extract secret witnesses from these VOLEitH signature schemes on ARM Cortex-M4 devices. These attacks succeed because implementation teams repeat six mistakes that made pre-quantum cryptography vulnerable.
Why These Mistakes Keep Happening
You're racing against a quantum timeline while maintaining systems that process millions of transactions daily. Post-quantum cryptography seems like a future problem, so you focus on functional correctness rather than side-channel resistance. The mathematics are new, the tools are immature, and your team lacks the experience from hardening classical implementations.
The result: you port vulnerable patterns into quantum-resistant schemes. The same power analysis techniques that compromised AES implementations now threaten the cryptographic foundations you're building for the next decade.
Mistake 1: Treating Side-Channel Protection as a Later Phase
Why it happens: Your team validates correctness first, planning to "add security" before deployment. The signing and verification logic passes all functional tests, so you move to the next milestone.
Real consequence: Side-channel vulnerabilities embed themselves in the computational structure. Researchers demonstrated six distinct DPA-style attack classes against FAEST and SDitH by targeting intermediate values during VOLE correlation computation. Retrofitting protection requires architectural changes, not just parameter tweaks.
The fix: Write side-channel resistance requirements into your initial implementation specification. Before coding secret witnesses, define your leakage model and threat assumptions. If deploying to embedded payment terminals using ARM Cortex-M4 processors, test for power analysis vulnerabilities during initial development, not during security review.
Mistake 2: Assuming Mathematical Security Implies Implementation Security
Why it happens: The signature scheme passed NIST's cryptanalysis review, so you assume the implementation inherits that security. Your focus stays on parameter selection and algorithm correctness.
Real consequence: The new attack framework targets the secret witness whose recovery permits signature generation for arbitrary messages. The mathematical proof doesn't account for information leakage through power consumption, timing variation, or electromagnetic emission. Attackers extract secrets without breaking the underlying mathematical problem.
The fix: Separate your security analysis into two tracks: mathematical security (resistance to cryptanalysis) and physical security (resistance to side-channel attacks). For each sensitive intermediate value, document whether it requires constant-time computation, masking, or other protection. The computation of values involved in VOLE correlations demands the same scrutiny you'd apply to AES key schedule operations.
Mistake 3: Focusing Protection on Obvious Operations While Ignoring Intermediate Values
Why it happens: You protect the final signature generation and the initial witness handling, assuming attackers target endpoints. Intermediate computations feel like implementation details rather than attack surfaces.
Real consequence: The research identified leakage from intermediate values during correlation computation, not just from obvious cryptographic operations. Both vertical attacks (analyzing single execution traces) and horizontal attacks (correlating across multiple executions) succeeded by targeting these overlooked computation points.
The fix: Map every intermediate value that depends on secret material, regardless of how briefly it exists in memory or registers. For VOLEitH schemes, this includes values generated during the proof construction phase. Apply the same protection discipline to intermediate computations that you apply to key material. If a value can be linked to secret witness hypotheses, it requires protection.
Mistake 4: Testing Only Under Ideal Conditions
Why it happens: Your validation environment uses clean power, controlled temperature, and isolated execution. You verify that the implementation produces correct signatures, not that it resists attack under operational stress.
Real consequence: The attacks were validated under varying noise conditions and across three different ARM Cortex-M4 devices, demonstrating effectiveness in realistic deployment scenarios. Your clean-room testing misses the leakage patterns that appear when the processor shares power rails with other components or operates in electrically noisy payment terminal environments.
The fix: Test side-channel resistance under conditions that match your deployment environment. If you're targeting payment terminals, test with realistic power noise, concurrent processes, and thermal variation. Simulate both vertical DPA attacks (which need fewer traces but stronger signals) and horizontal attacks (which tolerate more noise but require more traces). Document the minimum noise threshold where your protections fail.
Mistake 5: Treating All VOLEitH Implementations as Equivalent
Why it happens: FAEST and SDitH both use the VOLEitH paradigm, so you assume side-channel protections developed for one scheme transfer directly to the other. You reuse implementation patterns across schemes to reduce development time.
Real consequence: While both schemes proved vulnerable to DPA-style attacks, the specific leakage points and optimal attack strategies differ. The research identified six distinct attack classes, with different effectiveness profiles across the two schemes. Protections tuned for one scheme may leave gaps in the other.
The fix: Analyze each scheme's computational structure independently. Map the specific operations where secret witnesses influence observable behavior. FAEST and SDitH have different proof construction mechanisms, which means different intermediate values require protection. Build scheme-specific test cases rather than generic VOLEitH validation suites.
Mistake 6: Deploying Without Measurement-Based Validation
Why it happens: You rely on code review and architectural analysis to verify side-channel resistance. Acquiring the measurement equipment and expertise for power analysis testing feels like a specialized capability you can defer to external auditors.
Real consequence: The attacks required practical measurements on actual hardware to validate and refine. Without measurement-based testing, you won't detect the leakage patterns that matter in your specific hardware configuration. Theoretical protections fail when instruction scheduling, cache behavior, or power delivery characteristics create unexpected leakage.
The fix: Establish basic power analysis measurement capability before you deploy post-quantum signatures in production. You don't need a nation-state laboratory. The research used ARM Cortex-M4 devices, which are representative of payment terminal hardware you can test on your bench. Measure power consumption during signature generation with known test vectors, then verify that you cannot distinguish between different secret witness values.
Prevention Checklist
- Side-channel requirements defined before implementation starts
- Separate security analysis tracks: mathematical and physical
- Complete inventory of secret-dependent intermediate values
- Protection applied to VOLE correlation computations, not just endpoints
- Testing performed under realistic noise and deployment conditions
- Scheme-specific analysis for each VOLEitH implementation
- Measurement-based validation on target hardware
- Both vertical and horizontal DPA resistance verified
- Leakage model documented with specific noise thresholds
- Continuous monitoring plan for new attack research
The path to quantum-resistant payments requires more than algorithm selection. It requires the implementation discipline that the cryptography community learned through decades of side-channel attacks on classical schemes. Don't repeat those lessons with post-quantum cryptography.
