Custom fork of rust-secp256k1 with unsafe modifications for higher speed. Unsuitable for production.
Go to file
Andrew Poelstra 3aada83180
Merge rust-bitcoin/rust-secp256k1#627: Add bindings to the ElligatorSwift implementation
39febcb866 Create rust-bidings (Davidson Souza)

Pull request description:

  ~**Marking as draft as this is an unreleased feature from libsecp**~

  From upstream:
  This implements encoding of curve points using the ElligatorSwift algorithm, using 4 new API calls:

      secp256k1_ellswift_encode, which converts a public key to a 64-byte pseudorandom encoding.
      secp256k1_ellswift_decode, the reverse operation to convert back to normal public keys.
      secp256k1_ellswift_create, which can be seen as a combination of secp256k1_ec_pubkey_create + secp256k1_ellswift_encode, but is somewhat safer.
      secp256k1_ellswift_xdh, which implements x-only Diffie-Hellman directly on top of 64-byte encoded public keys, and more efficiently than decoding + invoking normal ECDH.

  This algorithm allows mapping any pair of field elements (u, t) to a (valid) x coordinate in the curve. This allows representing a field element as a 64-bytes bit string that is indistinguishable from random. You can build a pair of (u, t) from any group element as well.
  We also have an integrated x-only ECDH that can be used to establish a shared secret between two parties. All algorithms are compatible with BIP324 and are tested against the BIP's test cases.

  I have a few questions about the rust side of the implementation:
  Should it be always on, or leave it behind a cargo feature? In `libsecp` this module is default on, but you can disable it.
  I'm not exposing the low-level functions, instead you can use high-level types to interact with ellswift. Is it reasonable to also expose a safe version of the functions above?

ACKs for top commit:
  tcharding:
    ACK 39febcb866
  apoelstra:
    ACK 39febcb866

Tree-SHA512: a3c06304a03af9509ff3ef16fd39ee56ec22fc12d1b36be4c20aaa2ad01e98dd34ea64c66db782d3a2c10c3a7b44c701762d45f8d82f45b62db3379710c89c42
2023-10-09 21:26:45 +00:00
.github/workflows ci: Remove MIPS* from CI 2023-09-30 12:04:45 -03:00
contrib ci: generalize grp in "illegal callback" test 2023-09-30 12:04:45 -03:00
examples Use hashes instead of bitcoin_hashes 2023-08-15 14:54:55 +10:00
githooks Add cargo fmt to pre-commit githook 2022-11-22 08:59:09 +11:00
no_std_test Merge rust-bitcoin/rust-secp256k1#644: Improve `Message` constructors 2023-08-10 15:05:43 +00:00
secp256k1-sys Create rust-bidings 2023-10-09 14:57:54 -03:00
src Create rust-bidings 2023-10-09 14:57:54 -03:00
tests Rename KeyPair to Keypair 2023-08-19 08:35:47 +10:00
.gitignore gitignore: remove things that shouldn't be there 2023-09-30 12:04:44 -03:00
CHANGELOG.md Add changelog entry for removal of ONE_KEY 2023-07-08 10:52:52 +10:00
Cargo-minimal.lock Update vendored libsecp to v0.4.0 2023-09-30 12:04:45 -03:00
Cargo-recent.lock Update vendored libsecp to v0.4.0 2023-09-30 12:04:45 -03:00
Cargo.toml Update vendored libsecp to v0.4.0 2023-09-30 12:04:45 -03:00
LICENSE Remove the MIT/CC0 license in favor of just CC0 2015-03-25 18:36:30 -05:00
README.md Rename KeyPair to Keypair 2023-08-19 08:35:47 +10:00
clippy.toml Bump MSRV to 1.48 2023-03-31 09:43:50 +11:00
rustfmt.toml rustfmt: Use now config option fn_params_layout 2023-05-10 08:16:33 +10:00

README.md

Rust Secp256k1

Crate Info CC0 1.0 Universal Licensed CI Status API Docs Rustc Version 1.48.0+

rust-secp256k1 is a wrapper around libsecp256k1, a C library implementing various cryptographic functions using the SECG curve secp256k1.

This library:

  • exposes type-safe Rust bindings for all libsecp256k1 functions
  • implements key generation
  • implements deterministic nonce generation via RFC6979
  • implements many unit tests, adding to those already present in libsecp256k1
  • makes no allocations (except in unit tests) for efficiency and use in freestanding implementations

Contributing

Contributions to this library are welcome. A few guidelines:

  • Any breaking changes must have an accompanied entry in CHANGELOG.md
  • No new dependencies, please.
  • No crypto should be implemented in Rust, with the possible exception of hash functions. Cryptographic contributions should be directed upstream to libsecp256k1.
  • This library should always compile with any combination of features on Rust 1.48.0.

Githooks

To assist devs in catching errors before running CI we provide some githooks. If you do not already have locally configured githooks you can use the ones in this repository by running, in the root directory of the repository:

git config --local core.hooksPath githooks/

Alternatively add symlinks in your .git/hooks directory to any of the githooks we provide.

Benchmarks

We use a custom Rust compiler configuration conditional to guard the bench mark code. To run the bench marks use: RUSTFLAGS='--cfg=bench' cargo +nightly bench --features=recovery.

A note on non_secure_erase

This crate's secret types (SecretKey, Keypair, SharedSecret, Scalar, and DisplaySecret) have a method called non_secure_erase that attempts to overwrite the contained secret. This method is provided to assist other libraries in building secure secret erasure. However, this library makes no guarantees about the security of using non_secure_erase. In particular, the compiler doesn't have any concept of secrets and in most cases can arbitrarily move or copy values anywhere it pleases. For more information, consult the zeroize documentation.

Fuzzing

If you want to fuzz this library, or any library which depends on it, you will probably want to disable the actual cryptography, since fuzzers are unable to forge signatures and therefore won't test many interesting codepaths. To instead use a trivially-broken but fuzzer-accessible signature scheme, compile with --cfg=secp256k1_fuzz in your RUSTFLAGS variable.

Note that cargo hfuzz does not set this config flag automatically. In 0.27.0 and earlier versions, we used the --cfg=fuzzing which honggfuzz does set, but we changed this because there was no way to override it.