Why “Adams Bridge” Leaks:

Attacking a PQC Root-of-Trust

Markku-Juhani O. Saarinen
<[email protected]>

Loc & Date: hardwear.io USA 2025

30-May-2025 Santa Clara, CA, USA
TALK OUTLINE
Caliptra2 & Adam’s Bridge
- Why we may be running into it a lot in the near future.

Faulting Signature Verify

- A secure boot bypass strategy; malformed sig + fault.

Why Adam’s Bridge Leaks

- Adam’s Bridge “leaks” in TVLA as it doesn’t mask secret
keys. Direct exploitation may be tricky.

Time permitting: Demo https://github.com/ml-dsa/abr-sim

2
Caliptra2 & Adam’s Bridge

3
WHAT ARE WE TALKING ABOUT
CALIPTRA: A SoC Root of Trust IP jointly developed
and used by { AMD, Microsoft, NVIDIA, Google, .. }
👉 Secure (“measured”) boot, FW updates, attestation.

ADAM’S BRIDGE: PQC hardware accelerator for Caliptra.

First version supports only ML-DSA-87 (Dilithium-5.)

ML-DSA (Dilithium): Lattice-based signature scheme

defined in FIPS 204. Post-quantum Cryptography (PQC)
replacement for ECDSA in most applications.
4
Caliptra: Everywhere in 2026?
From John Traver (AMD): “An Overview of Caliptra, A Root of Trust for Measurement”

5
6
7
CPU/GPU/FPGA/etc..SoCs need a RoT?

https://github.com/google/security-research/security/advisories/GHSA-4xq7-4mgh-gp6w

https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking
8
WHY THE RUSH WITH DILITHIUM?
PQC Transition timeline is super tight for hardware.

“It’s the law.” (And a bunch of NSMs, policies,

directives, and regulations.) For DoD (CNSA):

NSS: “.. Beginning 1 January 2027, unless otherwise excepted

through public messaging on nsa.gov, protection profile,
capabilities package, or waived through the waiver process, CNSA
2.0 algorithms will be required in all new products and services
that provide cryptographic protection for users or for updates.”
CNSSP-15 (March 2025): https://www.cnss.gov/CNSS/issuances/Policies.cfm

9
CNSSP-15 (December 2024 version)

https://www.cnss.gov/CNSS/issuances/Policies.cfm

ML-DSA-87 parameter set is the only one in CNSA 2.0.

10
NIST IR 8547 (November 2024 IPD)

https://doi.org/10.6028/NIST.IR.8547.ipd 11
Adam’s Bridge Status
- ABr is 47,600 lines of publicly available SystemVerilog:
https://github.com/chipsalliance/adams-bridge

- We’ll use Adam’s Bridge release v1.0/v1.0.1 (May 16, 2025).

Supports ML-DSA-87 (“Cat 5”) parameter set only.

- Four functions (only): {KeyGen, Sign, Verify, KeyGen+Sign}.

- No programmability. Updates/patching not possible on ABr.

- The github repo has had its first ML-KEM commits in May.

12
Single-purpose HW Components ..

13
It’s really really big..
Protected ML-DSA-87 is 0.114mm2 @5nm (they’re saying 600MHz):
“0.0921mm2 for stdcell and 0.0220mm 2 for 57.38 KB RAM”

Rough estimate from area: 3 million gate equivalents,

~335k LUT FPGA synthesis supports this magnitude of ASIC size.

Protected Adams Bridge Area: >30x small microprocessor area!

(ARM Cortex M3 is 100-120k NAND2. IBEX on FPGA is 4k LUT).

Other secure ML-DSA HW modules are only 10%-30% of this size.

14
It’s pretty fast, though
ML-DSA-87 KeyGen: 15,530 Cycles
ML-DSA-87 Sign: 139,150 Cycles (average)
(minimum: 36,640 Cycles, 1 round: 35,958 cycles.)
ML-DSA-87 Verify: 18,770 Cycles

Signing flow example: Memory mapped (AHB) registers.

1. Host write keys, random, message, in registers.
2. Write to a control / trigger register to start.
3. Wait for status to become <ready> (perhaps intr).
4. Read the signature out from registers.

15
Each Signing Round: 26.0% success

Avg. ~4 rounds but ~1% of signatures need 16+ rounds!

(All ML-DSA implementations have this characteristic.)
16
Faulting Verification

17
FA Countermeasure for Sig Verify
“Classic” secure boot / firmware update bypass:
Glitch the yes/no result of signature verification.

ABr communicates the verification result in 64 bytes:

“To mitigate a possible fault attack on Boolean flag verification result,
a 64-byte register is considered. Firmware is responsible for
comparing the computed result with a certain segment of signature
(segment c\~), and if they are equal the signature is valid.”
[adams-bridge/docs/AdamsBridgeHardwareSpecification.md]

18
19
20
21
What is returned in early abort?
I have all of ML-DSA RTL in a verilator testbench –
easy to find out: The return value is 64 zero bytes.

There is nothing preventing me (attacker) from:

Offering an invalid “forged” signature with 64 zero
bytes c~ in the beginning.

64-byte comparison will match – “signature is valid”?

(For all messages and public keys!) I reported this..

22
Caliptra PSIRT Response on May 15
“We recognize that robust hardware-FW contract design is key to secure
cryptographic integrations. Based on your report, we also will mention
MLDSA signature verification fails if c~ is all zeros as we do in our
Caliptra-ROM/FW documentation.”

So.. the caller/driver needs to do some additional checks on

signatures and this was not mentioned in hardware documentation.
So Adam’s Bridge is not exactly “fire and forget” after all.

Indeed a firmware fix has been committed on March 21, 2025:

https://github.com/chipsalliance/caliptra-sw/commit/5a675c82c97c9f15
170a8333ead502ddb14967f4
23
24
That check looks unprotected
If we glitch this “all zero” comparison, the rest of
the verification routine thinks that signature is ok.

Note: Firmware offers an oracle on “how verification

fails” - code DRIVER_MLDSA87_UNSUPPORTED_SIGNATURE.

Combined Strategy:
1. Create malicious firmware with a signature block
that has first 64 bytes set to zero.
2. Attempt to glitch the all-zero check in CPU.
25
Can’t demo 🤷 (target not ready)
This looks all feasible in theory, but the firmware
is still being written. (That part of the firmware is
not even merged into the main branch yet.)

Note: At 330k LUTs the current design is too big to

fit on Artix7 FPGA targets (CW305) anymore.
Probably fits on a $10k CW340 “Luna” Board which has
Virtex UltraScale+ and allows glitching, etc.

Or try a silicon target. We’ll keep tracking this.

26
Why Adam’s Bridge Leaks

27
Adams Bridge has bold SCA Claims

28
FAU paper on Adam’s Bridge

- A Correlation Power Analysis (CPA) attack on a secret-key

multiplication step; late October ‘24 version of Adam’s Bridge.
- 10,000 traces to recover the secret keys, CW305 A7 FPGA target.
- M. Karabulut, R. Azarderakhsh, “Efficient CPA Attack on Hardware
Implementation of ML-DSA in Post-Quantum Root of Trust.“
(IEEE HOST ‘2025) https://ia.cr/2025/009
29
FPGA Target and FAU Key Extraction

30
“Review attack literature” (only?)

E. Karabulut, K. Upadhyayula, "Side-Channel Countermeasures for the Adams Bridge Accelerator" 31

..but advanced research exists

Azouaoui et al. “Protecting Dilithium against Leakage: Revisited Sensitivity

Analysis and Improved Implementations” https://ia.cr/2022/1406
32
MASKING: SPLIT SECRETS INTO SHARES

33
ACTUALLY MASKING PQC ALGORITHMS
Type Relationship Algebraic Object
Algebraic / Prime Field X = X0 + X1 (mod q) Mod 3329 (Kyber) or 8380417 (Dilithium)
Algebraic / Power-of-2 X = X0 + X1 (mod 2n) Some Lattice Crypto, SHA2, etc
Boolean / Binary Field X = X0 ⊕ X1 Nonlinear Functions, shifts, symmetric Crypto

- Masking splits all secret variables into “shares.” Even perfect

measurement of an individual share does not leak secret info.

- Most cryptographers agree: Masking and other attack mitigation

techniques for PQC algorithms are much more complex than
countermeasures for older cryptography.

- Why? The algorithms are not homogenous like RSA or ECC but contain a
number of dissimilar steps. In practice, one needs to design dozen
different provable masking gadgets for one algorithm such as ML-DSA.
34
34
ABr: PW Mult and INTT (only)

35
So, AbR is not really masked
- Secret keys are not masked (the way we understand it.)
“Operations Protected with Masking: Point-wise
multiplication and the first state of inverse NTT.”

- Key generation is not protected at all.

“The key generation operation does not have a
non-profiled attack vector since its nature is inherently
secure against CPA-style attacks.” (well, CPA..)

- Well, there can’t be security proofs for this because

secret variables are not protected everywhere..
36
DPA/DEMA Fundamentals – “Toggling”
Logic changes (0 → 1 or 1 → 0) consume dynamic power.
Toggling is used in DPA “Differential Power Analysis.”

There is also static power consumption, but unchanging

bits generally don’t leak much side-channel information.

State changes also emanate on the

electromagnetic spectrum (DEMA).

Programmable CPU registers and memory

are just one part of the vast logic
machinery that handles your secret bits..
37
OBSERVATIONS
- No control processor, but a hardcoded microcode
“sequencer”, basically a finite state machine:
mldsa_seq_prim.sv: 324 “instructions”
mldsa_seq_sec.sv: 114 “instructions”

- RTL is reasonably fast to simulate with verilator:

3200 cycles/sec (13.3sec/sign) without VCD dump
670 cycles/sec (63.6sec/sign) with VCD dump

- Simulation repo: https://github.com/ml-dsa/abr-sim

38
Rough VCD Pre-Silicon Testing
- verilator: Produce VCD traces, DUT doing signing operations.

- readvcd: VCD-to-Trace program reads VCD file: Keeps track of

all state bits and compute Hamming distance for each clock
cycle. These “toggle counts” approximate power for DPA.

- Since the simulated signal is very “clean”, not nearly as

many traces are required than from FPGA-oscilloscope setup.

- Better for locating leakage. Very precise; we get exact

cycle of leak points and can check (from VCD) the names of
wires and signals that were active and causing it.
39
“Toggle Trace” of ML-DSA Signing

40
PQC Leakage Assessment Strategies
1. Fixed vs Random (non-specific t-test)
- Trace set A: Fixed secret variable for every trace.
- Trace set B: New random secret variable for each trace.
- Statistically distinguishing of A from B is evidence of leakage.

2. A/B Categorization works with capture-then-analyze flow:

- Record traces with detailed test vector metadata.
- Traces are categorized after capture to A and B sets based on CSP
selection criteria. Example: a specific secret key bit.
- The same trace data can be categorized repeatedly.

In both cases:
Set A and Set B statistically differentiable with t-test = FAIL.

41
Test Vector Leakage Assessment

42
Dilithium Secret Key TVLA
- Basic TVLA fix-vs-random is really only suitable for
symmetric ciphers..

- And a Dilithium secret key has six components, three

(K,s1,s2) of which are actually secret for signing:

SK = ( ρ, K, tr, s1, s2, t0 )

- The public parts, e.g. matrix A expansion from symmetric

seed ρ do not need protection.

- How to create two sets of test vectors here?

43
ML-DSA Key Generation

44
Fixing (s1,s2) by inserting ρ’

45
Fix-vs-Random TVLA: 11000 traces

46
Zoom into the beginning

47
Comparing std. devs (zoomed)

48
Examining Some Leak Points
Cycle TVLA Major Active signals
2783 +185.5 top0.skdecode_inst.s1s2_data
Biggest spikes are created in the beginning — the secret key is
not masked and has to be deserialized as plaintext for NTT.

6456 -54.2 masked_bf_inst00.add_res_delay_inst.shift_reg

7118 +63.7 masked_bf_inst00.sub_inst_0.a2b_inst.x_reg
11042 +80.9 pwm_inst00.add_inst0.add_res_reg
There may be some bugs in the pointwise multiplication and NTT
gadgets as they have leakage correlations with secret keys.

49
What can we say from Pre-Silicon
- No surprise: Leakage happens during early phases when the
“plaintext” secret key is being moved about and transformed
(NTT(s1), NTT(s2) ..)

- This would be automatically considered “broken” by the

theory. However, leakage alone does not imply efficient key
recovery or forgery attacks.

- Adam’s Bridge may be (in practice) saved by “being fast”;

having wide data paths. A lot bits are moved in parallel so
the attacker learns relatilvely little of individual bits.

- Follow-up questions: Where do the keys come from? etc

50
SUMMARY POINTS
- Expect to be working on PQC targets a lot in near future.
- Combining fault attacks with malformed signatures can help attacks
against signature verification (learn how ML-DSA, SLH-DSA works!)
- Researchers know that many side-channel attacks work against Dilithium.
Lattice countermeasure “theory” work has been going on for many years.
- Attack papers do not claim to describe all of the vulnerabilities, just
what happened to be the low hanging fruit for specific targets.
- For countermeasures, take a systematic masking approach – must be
complemented with other countermeasures, and with adversarial analysis.
- Masking and other countermeasures impact architecture. Don’t try to
somehow “patch” countermeasures into an unprotected implementation.
- My ABr pre-silicon testing code: https://github.com/ml-dsa/abr-sim

51
Supplementary Material
(consulting if needed)

52
Masking Elsewhere ..
WrapQ: Side-Channel Secure Key Management for Post-Quantum Cryptography
Markku-Juhani O. Saarinen, PQShield Ltd, Tampere University
Abstract
Transition to PQC brings complex challenges to builders of secure cryptographic hardware. PQC keys usually need to be stored
off-module and protected via symmetric encryption and message authentication codes. Only a short, symmetric Key-Encrypting Key
(KEK) can be managed on-chip with trusted non-volatile key storage. For secure use, PQC key material is handled in masked format; as
randomized shares. Due to the masked encoding of the key material, algorithm-specific techniques are needed to protect the
side-channel security of the PQC key import and export processes. In this work, we study key handling techniques used in real-life secure
Kyber and Dilithium hardware. We describe WrapQ, a masking-friendly key-wrapping mechanism designed for lattice cryptography. On a
high level, WrapQ protects the integrity and confidentiality of key material and allows keys to be stored outside the main security
boundary of the module. Significantly, its wrapping and unwrapping processes minimize side-channel leakage from the KEK
integrity/authentication keys as well as the masked Kyber or Dilithium key material payload.
In this work, we study key handling techniques used in real-life secure Kyber and Dilithium hardware. We describe WrapQ, a
masking-friendly key-wrapping mechanism designed for lattice cryptography. On a high level, WrapQ protects the integrity and
confidentiality of key material and allows keys to be stored outside the main security boundary of the module. Significantly, its wrapping
and unwrapping processes minimize side-channel leakage from the KEK integrity/authentication keys as well as the masked Kyber or
Dilithium key material payload. (..)

https://eprint.iacr.org/2022/1499 (PQCrypto 2023)

53
On Certification of PQC Modules
FIPS 140-3 for PQC CC AVA_VAN and “Attack Potential”
- Required by U.S. Govt and - High assurance level (EUCC:
industrial best practices. AVA_VAN.3+) is required for
- ACVP certifications have been Root of Trust IP, Smart Cards,
issued since August 2024. Secure elements, IoT (SESIP).

- Currently focuses only on - AVA_VAN checks more of

functional (test vector) and real-life security via a
“checklist compliance”. “penetration test.”

- Random numbers: SP 800-90 - AVA_VAN security level

testing still good for PQC. is determined by "attack
potential": A score-based
- Slowly coming: “non-invasive” system measuring attack cost.
(ISO 17825) leakage assessment
for FIPS 140-3 level 3+. - Includes SCA, FA, etc.
55
(From PP-0117)

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Reporte/ReportePP/pp0117V2b_pdf.pdf 56
PQC Module Certification
- FIPS 140-3: Functional testing of ML-DSA implementations
since Aug 2024. Bunch of modules have been certified.
- Most major vendors are upgrading their product lines, as
they have to.

- ANSSI, BSI and other Europeans recommend ML-DSA to be

combined with a classical algorithm (RSA or ECDSA).
- BSI had not received certification requests in January 2025.
- ANSSI has started working on procedures to test ML-DSA.

57
CC: Main Protection Profiles
AVA_VAN.3+ is a common requirement for Root of Trust and
Security IC products. We assume that this will not change
(much) with Post-Quantum Cryptography.

[JSADEN011] “SESIP Profile for PSA Certified™ Level 3”

PSA-RoT: 35 person-days of AVA_VAN.3 activities.

[PP-0084] “Security IC Platform Protection Profile”

EAL 4 augmented by AVA_VAN.5 and ALC_DVS.2

[PP-0117] “Secure Sub-System in System-on-Chip (3S in SoC)”

EAL 4 augmented by ATE_DPT.2, AVA_VAN.5, ALC_DVS.2, ALC_FLR.2

58
AVA_VAN: CC Vulnerability Analysis
Attack Potential is evaluated
with a score-based system that AVA_VAN.1 Vulnerability Survey
roughly maps to the “cost of - TOE resistance against BASIC Attack Potential (0-15)
attack” (think $€£.)
AVA_VAN.2 (Unstructured) Vuln. Analysis
Considers attack Identification - TOE resistance against BASIC Attack Potential (16-20)
+ exploitation, with many
factors:
AVA_VAN.3 Focused (Unstructured) Vuln. Analysis
- Elapsed time (hours–months) - TOE resistance against ENHANCED-BASIC AP (21-24)
- Attacker Expertise
(multiple) AVA_VAN.4 Methodical Vuln. Analysis
- Knowledge (how restricted) - TOE resistance against MODERATE AP (25-30)
- Access to the TOE (samples)
- Equipment (common/bespoke)
AVA_VAN.5 Advanced Methodical Vuln. Analysis
(“Application of Attack - TOE resistance against HIGH Attack Potential (31-)
Potential” docs.)

59
Attack Potential: Example

AP Component Identification Exploitation

Elapsed time 2 (< one week) 6 (< one month)
Expertise 5 (expert) 4 (expert)
Knowledge of the TOE 4 (sensitive) 0 (public)
Access to the TOE 0 (< 10 samples) 0 (< 10 samples)
Equipment 3 (specialized) 4 (specialized)
Open Samples 0 (public) 0 (public)
Total 28 (AVA_VAN.4 / moderate AP range)

SOG-IS: “Application of Attack Potential to Smartcards and Similar Devices”

https://www.sogis.eu/documents/cc/domains/sc/JIL-Application-of-Attack-Potential-to-Smartcards-v3.2.1.pdf
60
Some Classical countermeasures – RSA and ECC
These were extremely simple algorithms + had algebraic structure
RSA: Blinding and masking (D. Chaum 1982, P. Kocher 1996)
- Message blinding: Pick random r, compute blinded c’=cre (mod n),
decrypt/sign c’ instead of c: m’=c’d (mod n), normalize by m = m’r-1.
- Exponent masking: use d’ = (p-1)(q-1)r + d to randomize exponentiation.

ECC: J.-S. Coron, “Resistance against Differential Power Analysis for Elliptic
Curve Cryptosystems.” Proc. CHES’99, pp. 292–302, 1999
- For 20+ years: Randomization of the Private Exponent [Scalar], Blinding
the [Base] Point P, Randomized Projective Coordinates, + misc.

Basically 1 step – ModExp (RSA) or Scalar Mult (ECC) – to protect

61
Background: Masking Generic Circuits
When we don’t have a handy algebraic structure
Each bit x is split into d uniform random shares: [[x]] = x0 ⊕ x1 ⊕ .. ⊕ xd-1.

“We prove that the amount of side channel information required grows
exponentially in [ d ], the number of shares.”
[ S. Chari, C. S. Jutla, J. R. Rao, P. Rohatgi. CRYPTO ‘99 ]

“We show that any circuit with n gates can be transformed into a circuit of
size O(nt2) that is perfectly secure against all probing attacks leaking up to
t bits at a time.”
(“t-probing model”) [ Y. Ishai, A. Sahai, D. Wagner, CRYPTO ‘03 ]

62
Example: Some bit-level first-order gadgets..
Random bits may be required every time
SecXor: [[X]] = [[A]] ⊕ [[B]] X0 = A0 ⊕ B0
(no share mixing!) X1 = A1 ⊕ B1

SecAnd: [[X]] = [[A]] ∧ [[B]] X0 = (A0 ∧ B0) ⊕ R ⊕ (A0 ∧ B1)

(R is a random bit.) X1 = (A1 ∧ B0) ⊕ R ⊕ (A1 ∧ B1)

Evaluation order matters (here from left to right). SecXor is O(d) but SecAnd
complexity increases in quadratic O(d2) fashion with the number of shares.

Recently, quasi-linear O(d log d) masking complexity has been achieved for
some functions, but not for full Dilithium or Kyber. More about this later..
63
NIST PQC: Good News and Bad News
Kyber and Dilithium benefit from this a lot..
Core (Structured/Unstructured - Ring/Module) LWE: “irreversibility” of:

t := A · [[s]] + [[e]]
..where A is a public, s and e are secret. No need to mask resulting t !

Good news: There is no multiplication between two secrets (say, [[s]] · [[r]]).
Since A is public, the core operation is linear: shares don’t interact. It’s O(d) .

Bad News: The s and e distributions are non-uniform. To generate them,

Kyber and Dilithium require a lot of mixing Arithmetic and Boolean masking.
64
[detail] Dilithium Algorithm Parameters
A Signature Algorithm based on MLWE and SIS
- Coefficients / elements work in ℤq with q = 8380417 = 223 - 213 + 1 fitting a 23 bits.
- Ring again is of type Rq = ℤq [x]/(xn + 1) with n=256. NTT arithmetic is used.
- A has two dimensions: k and l, so the total dimension is k × l × n.
- Public key compression (bit dropping): d = 13 bits.
- Challenge distribution has τ non-zero ±1 coefficients and (n-τ) zero coefficients.
- The secret key distribution is uniform but in very short range [-η, +η].
- Uniform y sampling range [-γ1, +γ1] and low-order rounding range is [-γ2, +γ2].
- Furthermore we have rejection bounds β (for signature) and ⍵ (for carry hint h).

Parameter Set (k, l) τ η γ1 (q-1)/γ2 β ⍵ Reps Classic Quant

(L2) ML-DSA-44 (4, 4) 39 2 217 88 78 88 4.3 2123 2112
(L3) ML-DSA-65 (6, 5) 49 4 219 32 196 55 5.1 2182 2165
(L5) ML-DSA-87 (8, 7) 60 2 219 32 120 75 4.0 2252 2229
65
[Identify CSPs] Dilithium Keypair Generation
Simplest and Fastest Operation in Dilithium
02. ρ, ρ’, K ← random or H(Seed) // Public and secret seed values.
03.  ← ExpandA(ρ) // Public  has size k × l × Rq , derived from ρ.
04. s1 ← ExpandS(ρ’, 0,2,..,l-1) // Secret s1 has size l × Rq, distribution [-η, +η].
s2 ← ExpandS(ρ’, l, ..,l+k-1) // Secret s2 has size k × Rq, distribution [-η, +η].
05. t ← A · s1 + s2 // All of t is secure. A · s1 = NTT-1(Â◦NTT( s1)).
06. (t1, t0) ← Power2Round( t, d ) // Split t; t1 high 13 bits, t0 low 10 bits.
07. tr ← H( ρ, t1 ) // tr = SHAKE256(PK).
08. return PK = ( ρ, t1 ), SK = ( ρ, K, tr, s1, s2, t0 )

- The actual secret key is just ( s1, s2 ). The K variable is only used in non-randomized
signing (where the same message and SK always give the same sig.)
- Note that ExpandS(ρ’) deterministic sampling is only useful in testing. If one can get
uniform [-η, +η] numbers (basically ℤ5 and ℤ9) directly in shares, this is better.
66
[Identify CSPs] Signature Generation (1 of 2)
Create a randomized “challenge” based on the message
09. Â ← ExpandA(ρ) // A has size k × l × Rq , derived from ρ.
10. μ ← H( tr || M ) // 512-bit message hash with H(PK) prefix.
11. κ ← 0, (z, h) ← ⊥ // Iteration counter κ, Iteration result.
12. ρ’ ← random [ or H( K, μ ) ] // [ Use hash in deterministic signing. ]
13. while (z, h) = ⊥ do: // — REJECTION LOOP —
14. | y ← ExpandMask( ρ’, κ.. ) // y is l × Rq sampled from [-γ1, +γ1].
15. | w ← A*y // Compute as w = NTT-1(Â◦NTT( y )).
16. | w1 ← HighBitsq( w, 2γ2) // w1 range is (q-1)/2γ2 so [0,15] or [0,43].
17. | ɕ ← H( μ, w1 ) // ɕ is derived from message and public key.
18. | c ← SampleInBall(ɕ) // c is in Rq, has τ non-zero (±1) coefficients.
19. | z ← y + c*s1 // It’s better to store NTT(s1) – as shares.

That’s the arithmetic for ɕ and z. We must reject them and “goto 14” if some checks fail..
67
[Identify CSPs] Signature Generation (2 of 2)
Based on “Fiat-Shamir with Aborts” - Rejection Iteration
20. | r0 ← LowBits( w - c*s2, 2γ2) // Range is basically ±2γ2
21. | if MaxAbs(z) ≥ γ1-β or MaxAbs(r0) ≥ γ2-β then: (z, h) ← ⊥ // reject
22. | else:
23. | h ← MakeHint( - c * t0 , w - c*s2 - c * t0, 2γ2) // h ∈ {0,1}kN
24. | if MaxAbs(c * t0) > γ2 or CountOnes(h) > ⍵ then: (z, h) ← ⊥ // reject
25. | κ ← κ+l // For creating fresh y in next iteration
end while
26. return Sig = ( ɕ, z, h ) // no longer secret

- Protecting just the ( s1, s2 ) secret itself via masking is easy; NTT in shares.
- Leaking the one-time secret y also breaks things; use masked arithmetic.
- MaxAbs and SampleInBall are very tricky to implement in masked format.
- The protected variables become non-secret (signature) after passing the check.
68
Dilithium Signature Verification
For completeness – Luckily doesn’t involve secrets
{ T, F } = Verify( Sig, M, PK ):

( ɕ, z, h ) ← Sig // Deserialize signature.

( ρ, t1 ) ← PK // Deserialize public key.
27. Â ← ExpandA(ρ) // “Lattice” in NTT transformed domain.
28. μ ← H( H(PK), M ) // Prefix the message hash with H(PK).
29. c ← SampleInBall(ɕ) // Hash to τ non-zero (±1) coefficients.
30. w’1 ← UseHintq( h, A*z - c*t1 · 2d, 2γ2 ) // Hint helps make w’1 exactly matching.

31. if MaxAbs( z ) < γ1-β and ɕ = H( μ || w’1) and CountOnes(h) ≤ ⍵ then:

| return T 👍 “Good signature”
else:
| return F 👎 “Fail!”
69