[Japabu]

Based on main c2fa263, after #993 and #1015 merged. Two commits: 7a7aa26 (round 0, bb4033d rebased) and 0193e43 (round 1).

Problem

At #1000 on the T14, P-256 ECDH was 4.36x ring and ECDSA P-256 verify 2.39x.

• Key generation ran the variable-base Booth windows from G, 255 doublings in all.
• Every window's addition also computed a masked doubling.
• Squaring was a multiplication, and inversion was square-and-multiply bit by bit.
• Verify rebuilt G's odd multiples on every call.
• The constant-time harness (toyos-crypto stage 4, the test side: vectors, integer oracle, differential, fuzz, controls, Miri and the constant-time harness #993) flagged P-256 on the T14 with main's older code. The hypothesis is identity-phase values under a fixed scalar with Intel DOITM off. Here the running point is kept off the identity by construction, as the reviewer suggested.

This is item 8b: N4 (base comb), N5 (inversion chain), a dedicated squaring, and a static G table for verify (D1).

What changes

• Comb (keygen, P-256).
  • The table: row i holds j·2^(5i)·G for j = 1..=16, in 52 rows of affine points (52 KiB), built at compile time by const Montgomery arithmetic with one simultaneous inversion.
  • Each window is one masked scan of all 16 entries, one conditional negation by mask, and one mixed addition (8M + 3S). There are no doublings.
• Odd representatives (both secret multiplications). Each runs on k' = k + j·n, with j the one of m and m + 1 that makes k' odd (m = 1 for P-256, 2 for P-384).
  • The top Booth digit is then nonzero, so neither the comb nor the doubling chain ever holds the identity.
  • A zero digit adds the row's (or table's) first entry and discards the sum by mask. No addition runs on an identity of zeros.
• Exceptional additions, proved at the sites.
  • Bounds on the running multiple show that only the last addition can meet equal operands. The comb's top window can do so for k = 2^256·d mod n; the doubling chain's last window for k = 2d mod n.
  • That last addition doubles by mask. Every other addition is the incomplete formula, which removes 51 masked doublings per ECDH.
  • Tests reach both doubling cases.
• Field.
  • P-256's mul, square, add and sub are written out word by word, because the shipped profile left the generic loops rolled. On x86-64 the mul is 260 instructions with 20 mulq and the square 194 with 14, both without branches.
  • Squaring computes the cross products once and reduces the 8-word square with the special step.
  • Inversion is an addition chain for P-256's prime (255 S + 12 M) and 4-bit windows over the public exponent for the other moduli.
  • u128 throughout: no asm! and no mulx, as directed.
• Verify. u1 is recoded at width 7 over a static table of G, 3G, ..., 63G (one per curve) and added in affine form. Q's table builds with public additions.

Generated code

Inspected in [profile.toyos] on x86_64-unknown-toyos and aarch64-unknown-toyos, from P-256 and P-384 agree and public_key.

• Every branch is one of:
  • a loop counter;
  • the public i == last test;
  • booth's public bit-position tests;
  • the scans' entry counter;
  • add_public on the peer's public points;
  • the public inversion exponent;
  • copy_nonoverlapping's debug check on stack addresses.
• Found and fixed during the inspection: overflow-checked + on secret-derived words in the new square, reduction and recoding, which would have been branches; and an iterator adaptor the shipped profile kept out of line.

Constant-time acceptance (metal, 0193e43)

#993's fixed-versus-random harness (crypto_secret_timing_curves): 1,000,000 measurements per routine, against a threshold of max |t| < 4.5. Logs: https://github.com/ToyOSOrg/evidence/tree/86e6b16f5f71dfd16c62777736bd7cda0629bec9/pr-1013/r2/metal

routine	main's old code, T14, DOITM off	this PR, T14, DOITM off	this PR, T14, DOITM on (22344f2)
P-256 public key	LEAKS 73.06	pass 1.21	pass 1.11
P-256 agreement	LEAKS 83.35	pass 2.99	pass 1.68
P-384 public key	pass 2.66	pass 0.83	pass 1.73
P-384 agreement	LEAKS 5.79	pass 1.39	pass 1.37
leaky control	LEAKS	LEAKS 94.46 / 1159.31	LEAKS 74.40 / 1278.05
null control	pass	pass 2.34 / 1.94	pass 2.31 / 2.80

• The AMD bench, DOITM off, this PR: P-256 public key 1.30, P-256 agreement 1.50, P-384 public key 2.26, P-384 agreement 3.39, Ed25519 2.47: all pass. The DOITM probe on main's old code had P-384 agreement leaking there at 5.37.
• The AMD bench, same boot: P-256 ECDH 1.93 (4.07 at main), ECDSA P-256 1.84 (2.21 at main).
• So with DOITM off, the representatives that keep the running point off the identity remove the T14 leak that main's old code showed. That is consistent with the hypothesis that identity-phase values took value-dependent time, though the run does not prove that cause.
• Timing tests alone do not prove constant time. The construction and the generated-code inspection are the rest of the evidence.

Review round 1 (0193e43)

• The variable-base proof now covers i = 0: 32T = k' − d₀ is a nonzero multiple of 32 below 4n + 16, and n is odd, so the running point is not the identity there either.
• The comb proof gives its missing reason: S_i is odd and d·2^(5i) is even, so their difference is nonzero.
• The comb is 52 KiB. The comb test's doc now names d = 1..=4.
• The const forms are documented as being for compile time and tests only, not for secrets: they lack the register barrier, and minus branches on its borrow.
• Rebase onto main's toyos-crypto stage 4, the test side: vectors, integer oracle, differential, fuzz, controls, Miri and the constant-time harness #993. Its integer oracle replaces the residue test that round 0 had extended. The const forms are now checked as a second implementation of its Field trait (compile_time_montgomery_forms_match_integers), against num-bigint on its boundary values, seeded values, chains and laws.

Round 1 checks, at 0193e43. Logs: https://github.com/ToyOSOrg/evidence/tree/e63da096c9d4d0eb760797f7fa0f3e974518474c/pr-1013/r2

• cargo run -- --ci host: exit 0, 93 green.
• Crate clippy and tests in the three CI forms: exit 0.
• Readbacks staged: crypto_instrument and crypto_secret_timing_curves (toyos-crypto stage 4, the test side: vectors, integer oracle, differential, fuzz, controls, Miri and the constant-time harness #993's harness), DOITM off. The harness is item 8's constant-time acceptance check. A third image runs the curves harness with DOITM on every CPU, built from crypto-sec's never-landed probe 380e63bbd cherry-picked onto this code (branch wt/toyos-crypto-perf-doitm, never lands).

Metal

The combined T14 boot (ec01b15, which carries round 0 unchanged) passed with judge exit 0. Ours over ring:

row	at #1000	this PR
P-256 ECDH	4.36	1.91
ECDSA P-256 verify	2.39	1.78
P-384 ECDH	1.21	1.01
ECDSA P-384 verify	—	0.53

Checks (round 0, at bb4033d; round 1 below)

All at bb4033d. Logs: https://github.com/ToyOSOrg/evidence/tree/b4adc3c52b22430e559eb9a1a56040f847e8d4c9/pr-1013/r1

• cargo run -- --ci host: exit 0, 93 steps green.
• Crate clippy (adopted lints, -D warnings) and cargo test -p toyos-crypto --release, in the three CI forms: exit 0 each.
• Builds for x86_64-unknown-uefi and aarch64-unknown-uefi: exit 0.
• crypto_instrument_prints_its_table (QEMU x86_64): exit 0. The log's first line names the revision.
• These still pass: Wycheproof ECDSA and ECDH, the ring differentials and the boundary scalars.
• New tests:
  • static_tables_hold_their_multiples: all 832 comb entries and both odd-multiple tables against the public path.
  • the_comb_matches_the_public_path: includes k = 2^256·d mod n for d = 1..4, where the top window doubles.
  • the_last_addition_doubles_where_it_must: the k = 2d mod n with first digit d, one per curve.
  • booth_digits_recompose_the_scalar, rewritten for representatives: odd, ≡ k mod n, below 2^(64N+2), top digit nonzero, ±16 reached.
  • The integer oracle now also holds the const forms (times, plus, minus, inverted) to the run-time ones for every modulus.
• Negative controls. Each is a checked patch applied, built (exit 0), tested with --features sign --release --no-fail-fast, and reverted in the same run. All 15 go red:

control	red
comb's top-window masked doubling removed	the comb test
variable-base last masked doubling removed	the_last_addition_doubles_where_it_must (green before that test was added)
representative parity flipped (even k')	Booth/representative test, comb test
P-384 offset 1 instead of 2	Booth/representative test, cross-path test
comb lookup never negates	comb test, differentials
comb keeps a zero digit's sum	comb test, differentials
comb rows advanced by 2^4 instead of 2^5	table test, comb test
G odd-multiple table stepped by G	table test, cross-path tests
P-256 square: wrong diagonal	integer oracle, every curve test
generic square: cross products not doubled	as above
generic reduction drops the top carry	as above
P-256 inversion chain: x30 from 14 squarings	integer oracle, curve tests
windowed inversion reads 3-bit digits	integer oracle, cross-path test
verify adds G's entry instead of subtracting	cross-path tests, table test
P-256 multiply's reduction shifts q by 31	integer oracle, curve tests

Measurements

Readback staged at bb4033d (crypto_instrument, cryptocase; exit 2 = Staged, no machine touched). The rows this moves are p-256/ecdh, ecdsa-p-256 verify, and to a lesser degree the P-384 rows.

• Exploratory, development Mac (aarch64) under load, a shipped-like profile; ours over ring:

row	before	ours	ring	ratio
P-256 ECDH	162 us	56 us	33 us	1.69
P-256 verify	82 us	48 us	30 us	1.58
P-384 ECDH	550 us	397 us	419 us	0.95
P-384 verify	271 us	196 us	405 us	0.48

• P-256 ECDH split: key generation 11.4 us (comb), agreement 45.6 us (Booth). Not a bench measurement.

Risks

• The constant-time acceptance check for item 8 is toyos-crypto stage 4, the test side: vectors, integer oracle, differential, fuzz, controls, Miri and the constant-time harness #993's harness re-run on this code; DOITM is being probed separately. Timing tests alone do not establish constant time. This PR's evidence for it is the construction and the inspection above.
• The comb adds 52 KiB of static data and about 8 s to the crate's debug build (2.4 s to 10.4 s on the development Mac) (const evaluation; long_running_const_eval is allowed at that one item).

🤖 Generated with Claude Code

https://claude.ai/code/session_01PXEk8BBMDT8tXu4AnENB9Q

[Japabu]

Review of #1013, round 1 (head bb4033d, item 8b)

What I read and did not run

• Read:
  • the commit against 81c1386;
  • nist.rs and montgomery.rs in full at the head, plus the ecc.rs and test changes;
  • the evidence in the scratch copies of b4adc3c: the controls with their patches and results.txt, the inspection README, the four branch walks, and the P-256 mul/square listings.
• Not run: no builds or tests. I did not read the analysis notes or any ring or BoringSSL source.

Architecture

• Scope. This is N4, N5, a dedicated squaring and D1, as the brief scopes them.
• The representative k' = k + j·n. It is the right construction:
  • it removes the identity phase from both secret multiplications;
  • it removes 51 masked doublings by proof rather than by masking;
  • it costs one N-word multiply-add.
• Shared builders. The comb and the static G tables are built by one Build with one simultaneous inversion each. Its const field forms are used only by Build and tests.
• Field. The P-256 field is unrolled u128 code, with no asm and no mulx, as decided.
• Size. Net +914/−107. Roughly 230 lines are tests and 170 are the unrolled P-256 field.
• Static data. About 57 KiB: the 52 KiB comb plus the two G tables.

The exceptional-addition proofs, checked

Variable base (Point::mul, nist.rs:390–398).

• Representative range.
  • P-256 (m = 1): k' ∈ [n+1, 3n−1].
  • P-384 (m = 2): k' ∈ [2n+1, 4n−1].
  • Both are below 2^(64N+2), so the top window's u₅ is zero and its digit is non-negative.
  • Both exceed 2^(5·top−1): 2^254 for P-256 (n > 2^255), and 2^384 for P-384 (2n > 2^384, while k + n can fall below 2^384, hence m = 2). So d_top ≥ 1.
• Lower part S. I checked that |S| ≤ 2^(5i+4). Booth's telescoping gives S = (k' mod 2^(5i+5)) − b₅ᵢ₊₄·2^(5i+5), and that lies in [−2^(5i+4), 2^(5i+4)).
• T ≥ 1. For i = top − 1, T = d_top. For smaller i, k' − S > 2^(5i+5).
• Upper bound. 32T ≤ k'/2^(5i) + 16 < n/8 + 16 for i ≥ 1. So 0 < 32T ∓ d < n for every |d| ≤ 16, including the d = 0 entry P that is discarded.
• Result. For i ≥ 1 the running point is never the identity, and it never equals or opposes the addend. Every running point is a multiple in (0, n), so the doublings never meet the identity.
• i = 0.
  • k' is odd, so d₀ is odd and nonzero.
  • Opposite operands would need k' ≡ 0, which is impossible.
  • Equal operands need k ≡ 2d₀ (mod n). That is the case the masked doubling covers, and the_last_addition_doubles_where_it_must reaches it on both curves.
  • The running point here is not the identity, but the comment does not prove it (item 1). It holds because 32T = k' − d₀ is a multiple of 32 in (0, 4n + 16), while every multiple of n there (n, 2n, 3n, 4n) has a factor of at most 4 beside the odd n.

Comb (comb_mul, nist.rs:473–481).

• Running multiple. Before window i, the running multiple is S_i = (k' mod 2^(5i)) − b₅ᵢ₋₁·2^(5i).
  • It is odd, because k' is odd.
  • 0 < |S_i| ≤ 2^(5i−1) ≤ 2^254 < n, so the running point is never the identity.
• Windows below the top. S_i ∓ D·2^(5i), for D = |d|, or D = 1 for a zero digit's row[0], is odd and therefore nonzero. Its magnitude is at most 16.5·2^(5i), which is below n for i ≤ 50.
• Top window, i = 51.
  • Opposite operands would need k' ≡ 0.
  • Equal operands need k ≡ 2^256·d (mod n), which the top-window mask covers.
  • When d = 0, the sum, garbage or a doubling, is discarded.
• Masking. comb-no-top-doubling is red on the comb test, so the case is reached.
• Result. The proof is correct. One step is unstated (item 1).

Representative.

• j = m + ((m ⊕ k₀ ⊕ 1) & 1) gives an odd k' without branching.
• mac computes k + j·n with the carry in word N, and it lives in a Workspace.
• The test checks oddness, k' ≡ k, the range bound, the recomposition and a nonzero top digit, for both curves.

Field, checked by hand

• P-256 mul. It is word for word the generic special step from crypto: P-256 special reduction, Booth windows, joint ECDSA verify (parity item 8a) #1000: q = x₀, q << 32 and q >> 32 at words 1 and 2, and q·p₃ at word 3.
• P-256 square.
  • Cross products: (0,1), (0,2), (0,3), (1,2), (1,3) and (2,3), with no column overflowing 128 bits.
  • Doubling by shifts, then the diagonals with a carry chain.
  • Four special reduction steps, with the carry rippled to word 7.
  • extra records the single carry out. The total is below p² + p·2^256 < 2^513, so the carry is at most one, and the result is below 2p.
• redc and square_wide. The generic forms agree.
• Inversion chain.
  • p − 2 reads 32 ones, 31 zeros, one, 96 zeros, 94 ones, zero, one, from the top.
  • The chain builds x2, x3, x6, x12, x15, x30 and x32, then shifts by 32, 128, 32, 30 and 2. That is 255 squarings and 12 multiplications.
• Generic inversion. It uses 4-bit windows over the public p − 2 and branches only on its digits. That is public, and it is the P-384 affine path used on the secret product.
• Overflow-check fixes. Every new carry uses overflowing_* or wrapping_*, and the shipped listings for mul and square have no conditional jump.

Constant time

• Lookups. Both read all 16 entries with ct::nonzero and Residue::select. Magnitude and sign come by arithmetic. Row addresses depend only on the public window index.
• Selects and digits. The i == 0 and i == R − 1 tests are on the public counter. Digit discarding is by mask. Booth's branches are on bit positions.
• The walks. They agree.
  • P-256 agree: cmpq $-6/$-1 on the counter, and cmpq $59 on the shift.
  • base_mul: cmpq $259 on 5i + 4, and cmpq $254 on the position.
  • Both lookups: cmpq $17 on the entry counter.
• One limitation. Two branches have no flag setter within the printed three instructions: agree's je .LBB54_7 and base_mul's jb .LBB193_3. I could not classify them from the walk alone. The README's classification is plausible (booth's word < W and shift > 58), but suggestion 5 would let a reader check it.
• Remaining source. I see no code-level secret-dependent timing source. What remains is operand-value dependence under DOITM off, which this construction reduces but cannot exclude. toyos-crypto stage 4, the test side: vectors, integer oracle, differential, fuzz, controls, Miri and the constant-time harness #993's harness on this code is the acceptance check, as the Risks section says.

Findings

BLOCKER

1. nist.rs:390–398 and :473–481 — each proof omits one step it relies on.
   • Variable base. It argues the running point is not the identity only for i ≥ 1. The last addition is the incomplete formula, and on an identity it would give a wrong point, so the comment must also cover i = 0.
     • Suggested sentence: "At i = 0, 32T = k' − d₀ is a nonzero multiple of 32 below 4n + 16, and n is odd, so it is not a multiple of n."
   • Comb. "0 < |S_i ∓ d·2^(5i)|" needs its reason: S_i is odd and d·2^(5i) is even.
   • These are security proofs at their sites, so they must be complete. One clause each.
2. nist.rs:994 — the test's doc is stale. It says "d = 1, 2", but the code uses 1..=4, as the body does.
3. nist.rs:321 and the commit body — "53 KiB" is wrong. 52 rows × 16 entries × 64 B is 53 248 B, which is 52 KiB.
4. montgomery.rs:138–140 — "their final subtraction is a plain select" is false for minus, which branches on borrow.
   • These const fns are pub(crate) and callable at run time, and none of them is constant time.
   • State the actual contract: compile-time tables and tests only, not for secrets.

SUGGESTION

5. Inspection evidence. On x86-64, have branches.py print the flag-setting instruction, as it already does on aarch64, so that every branch can be classified from the listing.
6. montgomery.rs mod p256 — pin the layout at compile time. The const assertion pins FORM but not N = 4. words::<N> would silently zero-extend for a larger N. Giving the p256 functions [u64; 4] signatures, and converting once at the Form::P256 dispatch, would make misuse a compile error.
7. Verify path. add_affine_public's equal-operands branch (r = ±G-table entry with r ≠ O) is reached by no test. check_exceptional_sums hits the projective one. It is public code and simple to inspect, so this is optional.

Tests and evidence

• Checks. --ci host, the three forms, both UEFI builds and QEMU exit 0 at bb4033d.
• Controls. The 15 controls, run on 81c1386 plus the identical tree, are real patches and all red.
  • mul-no-last-doubling was green until the_last_addition_doubles_where_it_must was added, which is exactly the gap a control should expose.
  • The two masked doublings, the representative parity, the P-384 offset, the zero-digit discard, the row step, the inversion chain and the special reduction are each pinned by a control.
• Mac table. It is labelled exploratory.

Verdict: SEND BACK (items 1–4, all comment wording; the arithmetic and both proofs' conclusions are correct).

[Japabu]

Review of #1013, round 2 (head 0193e43, item 8b)

What I read and did not run

• Read:
  • the round-1 commit 0193e43;
  • git range-diff of bb4033d against its rebase 7a7aa26, whose only change is the move to main's toyos-crypto stage 4, the test side: vectors, integer oracle, differential, fuzz, controls, Miri and the constant-time harness #993 oracle (MontgomeryConst in test_arithmetic.rs);
  • nist.rs's mul and comb_mul and their proofs, and montgomery.rs's const forms with their call sites, at the head.
• Evidence read:
  • the judge logs and kernel logs of three readbacks: readback-1013r1 (T14), readback-1013r1-amd and readback-1013-doitm (T14, DOITM on);
  • the published AMD constant-time results (evidence 86e6b16, pr-1013/r2/metal).
• Not run: no builds or tests. I read no other implementation's source.

Architecture

Unchanged since round 1, where it was accepted: the odd representative k' = k + j·n, the comb and G tables from one const Build, and the unrolled u128 P-256 field. The rebase replaces round 0's extension of the old residue test with a second Field implementation over the const forms. That is the cheaper and more thorough oracle: boundary values, seeded values, chains and laws, for all four moduli.

Round-1 blockers

1. Variable-base proof at i = 0 (nist.rs:396–398). Resolved. 32T = k' − d₀ is a nonzero multiple of 32 below 4n + 16. Since gcd(32, n) = 1, a common multiple of 32 and n is at least 32n, so 32T is not a multiple of n. The running point is therefore not the identity.
2. Comb proof (nist.rs:479). Resolved. The proof is stated for i ≥ 1, where S_i is odd and d·2^(5i) is even, so their difference is nonzero. The i = 0 window is a lookup, not an addition (comb_mul), so the domain is exact.
3. Test doc and size. Resolved. The test doc names d = 1..=4, which matches the loop. The comb is 52 KiB, which matches 52 × 16 × 64 B.
4. Const-form contract (montgomery.rs:138–140). Resolved. The doc says the forms are for compile time and tests, not for secrets, and names both reasons. I confirmed that ct::value_barrier is the register barrier, and that minus branches on borrow. Every use of times, plus, minus and inverted in nist.rs is in Build or in tests. The other times and plus calls in the crate belong to other types.

Evidence

All three images print supervisor: build 0193e43e3… clean, or 22344f2 for the DOITM probe.

• T14 (LENOVO 20W0003AMZ, BIOS N34ET71W 1.71). Judge exit: 2 passed, 0 failed.
  • crypto_instrument PASS.
  • crypto_secret_timing_curves PASS. Max |t| was 1.21 for P-256 public key and 2.99 for P-256 agreement; P-384 and Ed25519 were all ≤ 2.31.
  • Both controls behave as they should: the leaky control LEAKS, and the null control passes.
  • toyos-crypto stage 4, the test side: vectors, integer oracle, differential, fuzz, controls, Miri and the constant-time harness #993 had flagged P-256 on this machine with main's older code; with this construction it passes.
• AMD bench (LENOVO 82A2, BIOS DMCN38WW). 2 passed, 0 failed. The curve routines' max |t| is 1.30–3.39 (P-384 agreement 3.39), which matches the published copy. The controls behave the same way.
• T14 with DOITM on (probe 380e63bbd on this code, never lands). PASS, with every curve routine's max |t| ≤ 2.02 and the controls correct. The probe asserts DOITM's enumeration on every CPU, so the passing boot shows that DOITM was set.
• Rows. On the T14, P-256 ECDH is 1.908 and ECDSA P-256 verify 1.805. On the AMD bench they are 1.933 and 1.844, and ECDSA P-384 verify passes on both benches at about 0.54. These rows still fail parity, and the PR says so; it moves P-256 from 4.36 / 2.39.
• What this establishes and what it does not. The harness passes are item 8's acceptance evidence for the measured leakage model on both benches. The construction and the inspection remain the evidence for constant time, as the Risks section says.
• Reuse. The host checks at 0193e43 are in evidence e63da09 pr-1013/r2. Round 1 changed comments only, plus the rebase's test move, which those checks cover.

Findings

BLOCKER

None.

SUGGESTION

1. nist.rs:480 — the edited line runs to 116 columns, while the surrounding doc paragraph wraps at about 80. Reflow the paragraph.
2. test_arithmetic.rs MontgomeryConst — its modulus, input_bound, from and value repeat Montgomery's word for word. One struct with a const-form flag, or shared helpers, would cut about 15 lines. This is optional.
3. Round 1's suggestions 5–7 still stand as optional. Declining them is acceptable.

PR body (orchestrator)

• Risks. It still says "The comb adds 53 KiB". It is 52 KiB.
• Metal section. It reports only the combined boot ec01b15. Add the round-1 results at 0193e43:
  • both benches' crypto_secret_timing_curves passes and the DOITM-on pass, with their evidence links;
  • the Risks sentence on toyos-crypto stage 4, the test side: vectors, integer oracle, differential, fuzz, controls, Miri and the constant-time harness #993's harness, which is now satisfied for DOITM off on both benches and for DOITM on on the T14.

Verdict: LAND