k256

k256 is a pure Rust implementation of the secp256k1 (K-256) elliptic curve, the curve used by Bitcoin, Ethereum, and most other cryptocurrencies. It provides constant-time scalar and point arithmetic, ECDSA signing and verification with public-key recovery, Taproot Schnorr signatures (BIP340), and Elliptic Curve Diffie-Hellman (ECDH) key agreement, all built on shared abstractions from the elliptic-curve crate maintained by the RustCrypto organization.

The crate is no_std by default, forbids unsafe code, and has been independently audited by NCC Group, making it suitable for embedded, WASM, and other constrained environments alongside conventional application use. It re-exports PKCS#8/SPKI encoding for reading and writing keys in DER or PEM, and its arithmetic is feature-gated so consumers pull in only the operations they need.

What You Get

• Constant-time secp256k1 scalar and point arithmetic via projective/affine coordinate types with precomputed base-point tables
• ECDSA signing, verification, and low-S-normalized (BIP0062) public-key recovery, as used by Ethereum
• Taproot Schnorr signatures per BIP340, including tagged-hash and x-only-pubkey helpers
• Elliptic Curve Diffie-Hellman (ECDH) key agreement gated behind the ecdh feature
• PKCS#8/SPKI DER and PEM encoding for secret and public keys via the shared elliptic-curve traits

Common Use Cases

• Verifying Bitcoin and Ethereum transaction signatures in a Rust node, wallet, or indexer
• Implementing ECDSA public-key recovery for Ethereum-style address derivation
• Building Taproot-compatible Schnorr signing/verification for BIP340 wallets
• Deriving shared secrets over secp256k1 with ECDH in a no_std or embedded context

Under The Hood

Architecture — k256 is organized around a zero-sized Secp256k1 curve marker type implementing the elliptic-curve crate’s Curve/PrimeCurve traits, with feature-gated modules layered on top: src/arithmetic/ (affine/projective points, field and scalar math, precomputed tables), src/ecdsa.rs (SigningKey/VerifyingKey and recovery), src/schnorr.rs (BIP340 Taproot signatures with dedicated schnorr/ submodules), and src/ecdh.rs. This lets consumers pull in only SecretKey/PublicKey type aliases without the arithmetic backend, or opt into full scalar multiplication. Tech Stack — Pure Rust (edition 2024, MSRV 1.85), no_std by default with alloc/std as additive features, depending on sibling RustCrypto crates (elliptic-curve, primeorder, wnaf, hash2curve) rather than any C bindings, plus optional ecdsa/signature/serdect/sha2 for higher-level key types. Code Quality — High: #![forbid(unsafe_code)] at the crate root, tests/projective.rs plus doctested examples in ecdsa.rs/schnorr.rs, a dedicated benches/ suite (ecdsa, field, point, scalar, schnorr) under Criterion, proptest-regressions/ for property-test-found edge cases, and an extensive [lints.clippy] block enforcing unwrap_used, missing_docs, and numeric-cast safety. The crate has been independently audited by NCC Group, which found and fixed high-severity issues in both the ECDSA and Schnorr implementations. API Design — Ergonomic and consistent with sibling RustCrypto curve crates (p256, p384): SecretKey/PublicKey/NonZeroScalar type aliases are shared across the family, doctested usage examples exist for both signing and public-key recovery, and every public item carries rustdoc (enforced by missing_docs lint). Feature flags are numerous (arithmetic, ecdsa, schnorr, ecdh, serde, pem, std, etc.), which adds a real learning curve for newcomers deciding which combination they need.