onchip profile is not REU-free: fe25519_mul still REU-DMAs multiply rows — "No REU required" onchip PRG fails full handshake without REU #67

Summary

The USE_NISTCURVES_ONCHIP profile (and therefore the packaged
dist/c64-https-uci-onchip.prg, documented as "No REU required — for stock
machines without an REU") is REU-free only on the ECDSA verify path. The
in-tree X25519 (src/crypto/fe25519.s) still fetches multiply rows via
reu_fetch_mul_row, which under the onchip build binds to the sibling's
REU-DMA routine in libs/nistcurves/src/mul_8x8.s (exported unconditionally;
only fp256/fp384 route through the on-chip og_common generator).

On a machine with no REU, the row fetch silently no-ops and mul_dma_lo/hi
stays at reu_mul_init's staging residue — every fe_mul returns garbage, so
the X25519 shared secret is wrong and the TLS handshake fails at the first
encrypted record, silently.

Evidence (2026-07-28)

• Source: src/crypto/fe25519.s imports/calls reu_fetch_mul_row with no
  USE_NISTCURVES_ONCHIP adaptation (fe_mul ~line 398; fe_sqr sites ~443/490).
• Empirical: on a BACKEND=uci USE_NISTCURVES_ONCHIP=1 build in VICE,
  fe_mul KATs (via labels + jsr) are 3/3 WRONG without -reu and 3/3
  correct with -reu.

Why validation missed it

The packaging no-REU validation ran the 3-vector ECDSA KAT in VICE without
REU (that path is genuinely REU-free via og_common) plus boot-to-banner.
X25519 was never KAT'd REU-less, and every full-handshake onchip e2e ran on
U64E/C64U hardware with REU enabled.

Fix direction

Adapt fe_mul/fe_sqr row fetches to on-chip generation under
.ifdef USE_NISTCURVES_ONCHIP (fp256's gen_mul_row/og_common is the
template — but note og_common's inline quarter-square is documented non-CT,
and X25519 operates on secret data; prefer a fixed-count CT generation loop
over ct_mul_8x8). Acceptance: full tools/test_x25519.py (incl. --slow
RFC 7748 vectors) in VICE without -reu on an onchip build.

A fix branch is in progress (feat/fe25519-onchip-rows).

🤖 Generated with Claude Code