Purpose of the Template
Your payment security team likely doesn't design block ciphers. Instead, you select and defend them to assessors. The risk lies in accepting a designer's security claims without thorough evaluation.
The SPEEDY block cipher illustrates this risk. Its designers assessed differential cryptanalysis (DC) resistance using two methods. One method restricted 1-bit-to-1-bit differential propagations through the S-box and used branch numbers to estimate differential probability. The other assumed all 1-bit-to-1-bit propagations through an active S-box were possible. A later counterexample invalidated the first evaluation. A new search method, without structural restrictions, reduced the minimum number of active S-boxes for 4 rounds from 35 to [33,34]. It found a 4-round characteristic with 34 active S-boxes outside prior search spaces, disproving branch-number-based claims for 2, 3, and 4 rounds. It also led to the best known key recovery attack on SPEEDY-7-192, with data complexity 2^173.48 and time complexity 2^173.69 encryptions.
The lesson isn't just about one cipher failing. It's about ensuring security arguments cover all necessary search spaces. This template helps you document and test that scope.
Prerequisites
- A current cryptographic inventory listing every algorithm, mode, key length, and the system that uses it.
- Access to primary cryptanalysis literature (IACR ePrint, conference proceedings) or a cryptographer who can interpret it.
- Your approved-algorithm policy, ideally aligned with FIPS 140-3 module requirements and your Key Encryption Key (KEK) and Data Encryption Key (DEK) hierarchy.
- A named owner for cryptographic decisions, with authority to trigger a migration.
The Template
Copy this into your risk register or algorithm-approval record. One record per algorithm.
CIPHER SECURITY-CLAIM REVIEW RECORD
1. IDENTIFICATION
Algorithm / variant: ______________________
Block size / key size: ______________________
Rounds used in deployment: ______________________
Systems and data flows: ______________________
Data protected (e.g., PAN): ______________________
Standardization status: [ ] Approved standard [ ] Published, non-standard [ ] Proprietary
2. DESIGNER SECURITY CLAIM
Claimed resistance (DC, linear, other): ______________
Source document and date: ______________________
Method behind the claim: ______________________
3. SCOPE OF EVALUATION (complete every line)
a. Which differential characteristics were searched?
[ ] Unrestricted [ ] Restricted (describe): ____________
b. Were any S-box propagation patterns excluded or assumed?
[ ] No [ ] Yes (describe): ____________
c. Does the bound rely on branch numbers or other
structural estimates rather than exhaustive search?
[ ] No [ ] Yes (describe): ____________
d. Is the claim a proven bound or a heuristic estimate?
[ ] Proven [ ] Heuristic
4. INDEPENDENT ANALYSIS
Third-party analyses reviewed: ______________________
Any counterexample to a designer claim? [ ] No [ ] Yes
Any revised bound (active S-boxes, EDP)? [ ] No [ ] Yes
Best known attack (data / time complexity): ___________
Margin between best attack and your security target: ___
5. DECISION
[ ] Approve [ ] Approve with conditions [ ] Restrict [ ] Migrate
Conditions / compensating controls: __________________
Reviewer: ____________ Date: ____________
Next review due: ____________
Review triggers: [ ] New ePrint on this cipher
[ ] Change in rounds or key size
[ ] Change in data classification
Explanation of Each Section
Section 3 is crucial. It addresses the core question raised by the SPEEDY cipher: what did the evaluation actually cover? Line 3b targets the restriction that caused issues, where only 1-bit-to-1-bit propagations through the S-box were considered. Line 3c identifies reliance on branch numbers. In SPEEDY's case, branch-number-based claims were disproved by later findings.
Section 4 documents what happened after publication. A claim without independent scrutiny isn't as reliable as one that has been thoroughly vetted. Record both revised bounds and the best known attack, then clearly state your margin.
Section 5 connects the review to a decision and sets review triggers to ensure the record remains current.
Customization Tips
- Elevate standards for payment data. If the cipher protects Cardholder Data or PANs, treat "Heuristic" in 3d as a condition requiring compensating controls or documented acceptance by the cryptographic owner.
- Favor standardized primitives. For most payment use cases, an approved standard with a long public analysis record is preferable to a newer, low-latency design. Use "Proprietary" and "Published, non-standard" as indicators for a more rigorous Section 4.
- Consider round variants. Record rounds explicitly. Analysis of 4- and 5-round characteristics informs you about building blocks; the attack that matters is against your deployed round count, as shown in the SPEEDY-7-192 result.
- Include other attack types. Duplicate Section 3 for linear, integral, and related-key analysis if your threat model requires it.
- Integrate with change control. Make a new published attack a mandatory trigger for re-review, not an optional one.
Validation Steps
- Completeness check. Every line in Section 3 must be answered. "Unknown" is acceptable but must be assigned to someone for follow-up.
- Literature spot-check. Choose one record and have a qualified cryptographer verify that the cited analyses match published data.
- Margin test. For each approved algorithm, compare the best known attack complexity to your security target. If the gap has narrowed since the last review, escalate.
- Inventory reconciliation. Ensure every algorithm in production is documented. Unreviewed ciphers are your biggest risk.
- Trigger drill. Simulate a new ePrint against one algorithm and measure the time to reach a documented decision.
A cipher doesn't become weak the day it's broken. It becomes weak when someone explores the spaces its designers overlooked. Your responsibility is to know which spaces were searched.
