nx_rsa2048_mod_exp_big.nx

nx_rsa2048_mod_exp_big.nx -- F103e RUNG 4: modular exponentiation with a FULL-WIDTH exponent. THE GAP, found by reading the signature rather than the filename: the estate's `rsa2048_mod_exp(out, s, e: i64, n)` takes the exponent as an **i64**, and its own header says so plainly -- "e fits in i64 (true for all Web PKI: e is either 3, 17, 65537)". That is correct and sufficient for VERIFICATION, where the public exponent is tiny. It is structurally unable to do either of the two things F103e needs next: * RSA SIGNING: s = m^d mod n, where the private exponent d is ~2048 bits. * MILLER-RABIN: a^d mod n, where d = (n-1)/2^r is ~1024 bits -- i.e. RSA KEYGEN. ★★★★★★A LIBRARY NAMED FOR AN OPERATION MAY IMPLEMENT ONLY THE DIRECTION ITS AUTHOR NEEDED. "The estate has RSA" was true and useless; it has RSA-verify. The symbol table said i64 and the filename did not. This is the same square-and-multiply as the incumbent, MSB-first, but walking the bits of a u2048 exponent instead of an i64. It deliberately does NOT re-implement the modular multiply -- it calls the SAME `rsa2048_mul_mod` the incumbent calls, so there is exactly one modmul in the estate. ★THE ORACLE IS THE INCUMBENT: for every exponent that fits in an i64, this function must agree with `rsa2048_mod_exp` BIT FOR BIT. The teeth check e = 3, 17, 65537 and 2^63-1 against it, then exercise an exponent NO i64 can hold -- the case that motivated the organ and the one the incumbent cannot answer, so it is reported as EXERCISED rather than cross-checked. Usage: nx_rsa2048_mod_exp_big selftest Exit: 0 GREEN | 1 RED. Log -> knowledge/status/nishi_os.log, verdict= LAST. license_tier: ORIGINAL