Clear Schnorr accumulator and 4x64 multiplication product #1966

Schnorr signing and 4x64 scalar multiplication leave local temporaries uncleared after their last use. These temporaries can retain information from which the secret key can be recovered if an attacker can read the residual memory.

• Clear the Schnorr signing accumulator e after its final use. On success it holds the public signature scalar, but with a valid keypair and a failing nonce callback or a nonce that reduces to zero, signing continues with the dummy nonce k = 1. The signature output is erased on failure while e retains 1 + challenge * sk modulo the group order. Given the message and public key, this value permits key recovery when the challenge is nonzero.
• Clear the 4x64 scalar multiplication buffer l[8] immediately after reduction. It contains the full 512-bit product and is separate from the signing accumulator. During ordinary successful Schnorr signing, it can retain challenge * sk, which also permits key recovery given the public nonzero challenge.

Both commits use the existing compiler-resistant clearing primitives. The accumulator change applies across scalar backends; the multiplication-buffer change is specific to 4x64.

This issue was found and the PR created by my agent using GPT-6-Astra.

Concept ACK. The 8x32 backend has the same temporary: secp256k1_scalar_mul in scalar_8x32_impl.h keeps the 512-bit product in l[16] and does not clear it. That backend is the one used on 32-bit targets without a 128-bit integer type, so the second commit could clear l there as well.

Clearing e in secp256k1_schnorrsig_sign_internal makes sense. On signing failure (ret == 0), the dummy nonce path computes with k = 1 and relies on secp256k1_memczero(sig64, 64, !ret) to avoid returning e = k + e_hash * sk, which would expose sk = (e - 1) * e_hash^(-1) mod n. Zeroing the output buffer while leaving e on the stack leaves that secret behind. Clearing it brings schnorrsig in line with secp256k1_ecdsa_sig_sign, which already clears its scalar accumulator n.

I'd drop the second commit rather than extending it to 8x32. secp256k1_scalar_mul is an inner-loop primitive called heavily in public contexts like signature verification and ecmult. Inserting secp256k1_memclear_explicit adds a memset and a full memory clobber barrier to every scalar multiplication across the library.

Clearing l also doesn't wipe the actual arithmetic state. In the assembly path, the 512-bit product and reduction temporaries reside in registers (r8-r15, rax, rdx) and stack slots that aren't scrubbed on return, while the caller still holds the inputs and the reduced output. Intermediate scratch wiping has never been the contract for low-level field or scalar primitives; secret zeroization is managed at the caller/module boundary.

Taking commit 1 and dropping commit 2 seems like the right move.

On arm64 the clear costs nothing above noise: scalar_mul takes 22.2 ns on master and on this PR with 4x64, 56.9 ns versus 57.1 ns on 8x32 with l[16] also cleared, and verify and sign do not move. The clear is not dropped and calls no memset: scalar_mul_512 is an out-of-line call that writes the product to l on the stack, and the library's scalar_mul zeroes it with two 32-byte stores. Method: median of the best time over 7 interleaved Release runs per variant, 8x32 forced with SECP256K1_TEST_OVERRIDE_WIDE_MULTIPLY=int64; x86_64 and its assembly path not measured.

Even with minimal store overhead on arm64, wiping l does not establish a security boundary. In optimized builds, scalar_mul inlines both multiplication and reduction into a frame where intermediate limbs, carries, and reduction temporaries spill across multiple stack slots and volatile registers (r8-r15 on x86_64, x0-x30 on arm64). Zeroing the 64-byte l array leaves those spilled temporaries and register state unscrubbed on return, while the caller still holds both inputs and the reduced output.

Inner-loop primitives cannot clean registers or caller frames, and they have no way to distinguish secret scalars from purely public ones in verification and ecmult. That is why libsecp256k1 enforces secret zeroization at the caller boundary—where the confidentiality context is actually known, as commit 1 does for e. Adding partial scratch zeroing inside arithmetic primitives introduces compiler barriers and maintenance baggage without providing real stack sanitization.

Commit 1 is a clean, genuine fix; dropping commit 2 keeps the library's layer boundaries intact.