Migrate secp256k1 backend from libsecp256k1 to k256

[Copilot]

• Check current workflow runs and CI status for the branch
• Re-inspect the final secp256k1 migration diff and touched tests
• Run the repository validation commands used for this area
• Run a final automated review/security validation pass
• Reply on the PR with the final review result

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (af732d4) to head (f2eba2f).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##            master      #152    +/-   ##
==========================================
  Coverage   100.00%   100.00%            
==========================================
  Files           12        12            
  Lines          665       790   +125     
==========================================
+ Hits           665       790   +125     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[kigawas]

@copilot push the coverage to 100%

[Copilot]

@copilot push the coverage to 100%

Pushed in 1d86e75. The migrated src/elliptic/secp256k1.rs adapter now reaches 100% function and line coverage under cargo llvm-cov, and the added tests keep the zero-tweak error contract intact.

[kigawas]

@copilot review the code from cryptography perspective. Reference: https://raw.githubusercontent.com/ashutosh1206/Crypton/refs/heads/master/Diffie-Hellman-Key-Exchange/Attack-Invalid-Curve-Point/README.md

[Copilot]

@copilot review the code from cryptography perspective. Reference: https://raw.githubusercontent.com/ashutosh1206/Crypton/refs/heads/master/Diffie-Hellman-Key-Exchange/Attack-Invalid-Curve-Poi...

Reviewed in 9b4cb61. I don’t see an invalid-curve issue in the secp256k1 path: attacker-controlled keys are parsed via k256::PublicKey::from_sec1_bytes, which goes through SEC1 decoding and rejects off-curve and identity points before scalar multiplication, and secp256k1 has cofactor 1 so valid non-identity points are already in the prime-order subgroup. I also added a regression test proving malformed raw and uncompressed public keys are rejected before ECDH.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• docs.rs
  • Triggering command: /home/REDACTED/work/_temp/ghcca-node/node/bin/node /home/REDACTED/work/_temp/ghcca-node/node/bin/node --enable-source-maps /home/REDACTED/work/_temp/copilot-developer-action-main/dist/index.js (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[kigawas]

@copilot do a final pass code review

[Copilot]

@copilot do a final pass code review

Final pass done in f2eba2f. I found one CI-only test portability issue in the secp256k1 error tests under the no-default-features/std feature matrix and fixed it; the production secp256k1 migration still looks good from a crypto perspective. Re-validated with cargo test --lib, CURVE=secp256k1 sh ./scripts/check.sh, and the previously failing CURVE=secp256k1 sh ./scripts/test.sh path.

[kigawas]

@copilot why we need PublicKeyFormat‎? Is it justified?

[Copilot]

@copilot why we need PublicKeyFormat‎? Is it justified?

It’s justified mainly for API compatibility, not because the current crate internals need it. Before the migration, PublicKey::parse_slice(pk, None) was part of the secp256k1 adapter surface, and keeping PublicKeyFormat preserves the ability for direct callers to explicitly distinguish compressed (33), full/uncompressed (65), and raw (64-without-0x04) encodings. Inside this crate we only use None, so if we want to simplify later we could remove it in a separate breaking-cleanup change; for this migration I kept it to avoid changing semantics while switching backends.

[kigawas]

LGTM