https://github.com/paritytech/libsecp256k1
Pure Rust Implementation of secp256k1.
https://github.com/paritytech/libsecp256k1
Last synced: 8 months ago
JSON representation
Pure Rust Implementation of secp256k1.
- Host: GitHub
- URL: https://github.com/paritytech/libsecp256k1
- Owner: paritytech
- License: apache-2.0
- Created: 2017-12-05T05:09:29.000Z (almost 8 years ago)
- Default Branch: master
- Last Pushed: 2024-08-17T20:01:27.000Z (about 1 year ago)
- Last Synced: 2025-03-06T16:52:38.008Z (8 months ago)
- Language: Rust
- Homepage:
- Size: 3.44 MB
- Stars: 184
- Watchers: 16
- Forks: 92
- Open Issues: 34
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- License: LICENSE
Awesome Lists containing this project
- awesome-cryptography-rust - libsecp256k1-rs
README
_Please note that this repository is no longer maintained. You can use [k256](https://crates.io/crates/k256) instead._
# SECP256K1 implementation in pure Rust
* [Cargo](https://crates.io/crates/libsecp256k1)
* [Documentation](https://docs.rs/libsecp256k1)
SECP256K1 implementation with `no_std` support. Currently we have implementation for:
* Convert a private key to a public key.
* Sign messages.
* Signature verification.
* Public key recovery from signed messages.
* Shared secrets.
## Feature flags
* `std`: If disabled, works in `no_std` environment. Enabled by default.
* `hmac`: Add certain features that requires the HMAC-DRBG. This includes
signing. Enabled by default.
* `static-context`: To speed up computation, the library uses a pre-computed
table context for many `ecmult` operations. This feature flag puts the context
directly as static variables. If disabled, the context must be created from
heap manually. Increases binary size, enabled by default.
* `lazy-static-context`: Instead of storing the pre-computed table context as
static variables, store it as a variable that dynamically allocates the
context in heap via `lazy_static`. It overwrites `static-context`. Impact
bootstrap performance and only available in `std`, disabled by default.
## Development workflow
### Branch
This repository uses `develop` branch for development. Changes are periodically
merged to `master` branch.
### Pull request
All changes (except new releases) are handled through pull requests. Please open
your PR against `develop` branch.
### Versioning
`libsecp256k1` follows [Semantic Versioning](https://semver.org/). An unreleased crate
in the repository will have the `-dev` suffix in the end, and we do rolling
releases.
When you make a pull request against this repository, please also update the
affected crates' versions, using the following rules. Note that the rules should
be applied recursively -- if a change modifies any upper crate's dependency
(even just the `Cargo.toml` file), then the upper crate will also need to apply
those rules.
Additionally, if your change is notable, then you should also modify the
corresponding `CHANGELOG.md` file, in the "Unreleased" section.
If the affected crate already has `-dev` suffix:
* If your change is a patch, then you do not have to update any versions.
* If your change introduces a new feature, please check if the local version
already had its minor version bumped, if not, bump it.
* If your change modifies the current interface, please check if the local
version already had its major version bumped, if not, bump it.
If the affected crate does not yet have `-dev` suffix:
* If your change is a patch, then bump the patch version, and add `-dev` suffix.
* If your change introduces a new feature, then bump the minor version, and add
`-dev` suffix.
* If your change modifies the current interface, then bump the major version,
and add `-dev` suffix.
If your pull request introduces a new crate, please set its version to
`1.0.0-dev`.