feat: add zeroizing read helper for sensitive deserialization

[Jr-kenny]

Describe your changes

Closes #593. Follows up on my comment there, opening this so the actual diff is easier to judge than a description.

Deserializing a secret key reads its bytes into a stack buffer, and each read_from had to remember to call zeroize() on that buffer before every return path. Going through the sensitive read_from impls, some forgot:

• ecdsa_k256_keccak::SecretKey::read_from zeroized on success but leaked the buffer on the early return when from_slice rejects the bytes
• falcon512_poseidon2::SecretKey::read_from never wiped its SK_LEN buffer on any path, success included
• the Poseidon2 AEAD SecretKey::read_from never wiped its buffer either
• the eddsa path was correct, but only because from_bytes is infallible

This adds read_sensitive_array to utils, which returns the array wrapped in Zeroizing so the buffer is wiped on drop no matter how the calling function exits, and switches the four impls over to it. The manual zeroize() calls go away, and a forgotten cleanup in a future read_from stops being possible by construction.

One limit I want to be straight about (also documented on the helper): read_array returns by value, so the single move into the Zeroizing wrapper is not wiped. That residual is the same one the manual calls had. Closing it fully would need a ByteReader method that reads into a caller-provided &mut [u8], which felt like a bigger conversation than this fix.

While in there I noticed falcon512 read_from calls decode_i8(...).unwrap() for the g and big_F chunks (only f gets a proper error). If those can fail on malformed input that's a panic on attacker-supplied bytes, but I didn't want to widen this PR before asking. Happy to file it separately if you think it's reachable.

Testing

• Added a test covering the ECDSA error path (out-of-range and zero scalars must return an error), which is the path that previously skipped the cleanup
• Full miden-crypto lib suite passes (648 tests), clippy clean
• CHANGELOG entry will follow in a commit once this PR has its number

Checklist before requesting a review

• Repo forked and branch created from next according to naming convention.
• Commit messages and codestyle follow conventions.
• Relevant issues are linked in the PR description.
• Tests added for new functionality.
• Documentation/comments updated according to changes.

[github-actions]

Automated check (CONTRIBUTING.md)

Findings:

• Ensure issue Consider adding a zeroizing deserialization reader that would be used for sensitive material #593 is assigned to the PR author.

Recommendations:

• Consider adding a Test plan or clear review steps.

Next steps:

• Ensure issue Consider adding a zeroizing deserialization reader that would be used for sensitive material #593 is assigned to you.
• See CONTRIBUTING.md for expectations.
• If this is a false positive, comment: /quality-review.

[huitseeker]

thanks for tackling this!

[huitseeker]

I think this fixes the serialized SK_LEN buffer, but this Falcon path still decodes secret coefficients into the f, g, and big_f temporaries below. Those are ordinary Vec/Polynomial values, and I do not see a Drop impl for Polynomial, only Zeroize. Should those decoded temporaries also be wrapped or wiped?

[Jr-kenny]

Good catch. The Vec<i8> temporaries coming out of decode_i8 were easy to cover, I've wrapped them in Zeroizing in 53587db so the raw coefficient bytes get wiped on every exit path now.

The Polynomial side turned out to be a deeper hole than it looks. FalconFelt doesn't implement Zeroize at all, so the generic impl on Polynomial can't touch Polynomial<FalconFelt>. And it's actually a bit worse than no Drop impl: polynomial.rs has a manual impl<F: Zeroize> ZeroizeOnDrop for Polynomial<F> {} with nothing backing it, and since ZeroizeOnDrop is just a marker trait, that's a wipe-on-drop promise that never actually runs. Even if both of those were fixed, computing big_g goes through fft().hadamard_div().hadamard_mul().ifft() and building the basis negates polynomials, all of which allocate intermediates carrying secret coefficients that read_from has no handle on.

So doing this properly means giving FalconFelt a Zeroize impl, backing the marker with a real Drop, and going over the falcon math ops for those intermediate allocations. That felt too big to bolt onto this PR, so I'd file it as a follow-up issue and take it on, shout if you'd rather see it handled here. Thanks!

[Jr-kenny]

Filed the follow-up as #1059 with the full picture. While writing it up I found the gap is wider than the read path: write_into drops the encoded secret key unwiped behind a stale comment, and generate_seed leaks an unwiped copy of it on every signature. I have the fix building and passing the falcon suite locally, ready to open once assigned.

[huitseeker]

Thanks!

[Al-Kindi-0]

LGTM, ty!