e3bddfa750modules: Port bitcoin-core/secp256k1#1579 to zkp-specific code (DarkWindman)13d389629aCONTRIBUTING: mention that `EXIT_` codes should be used (Sebastian Falbesoner)c855581728test, bench, precompute_ecmult: use `EXIT_...` constants for `main` return values (Sebastian Falbesoner)965393fceaexamples: use `EXIT_...` constants for `main` return values (Sebastian Falbesoner)b682dbcf84README: add instructions for verifying GPG signatures (James O'Beirne)a82287fb85schnorrsig: clear out masked secret key in BIP-340 nonce function (Sebastian Falbesoner)2ac9f558c4doc: Improve cmake instructions in README (Fabian Jahr)39705450ebFix some misspellings (Nicolas Iooss)c97059f594release cleanup: bump version after 0.6.0 (Jonas Nick)39d5dfd542release: prepare for 0.6.0 (Jonas Nick)df2eceb279build: add ellswift.md and musig.md to release tarball (Jonas Nick)a306bb7e90tools: fix check-abi.sh after cmake out locations were changed (Jonas Nick)145868a84dDo not export `secp256k1_musig_nonce_gen_internal` (Hennadii Stepanov)765ef53335Clear _gej instances after point multiplication to avoid potential leaks (Sebastian Falbesoner)349e6ab916Introduce separate _clear functions for hash module (Tim Ruffing)99cc9fd6d0Don't rely on memset to set signed integers to 0 (Tim Ruffing)97c57f42baImplement various _clear() functions with secp256k1_memclear() (Tim Ruffing)9bb368d146Use secp256k1_memclear() to clear stack memory instead of memset() (Tim Ruffing)e3497bbf00Separate between clearing memory and setting to zero in tests (Tim Ruffing)d79a6ccd43Separate secp256k1_fe_set_int( . , 0 ) from secp256k1_fe_clear() (Tim Ruffing)1c08126222Add secp256k1_memclear() for clearing secret data (Tim Ruffing)e7d384488eDon't clear secrets in pippenger implementation (Tim Ruffing) Pull request description: Merge bitcoin-core/secp256k1#1579: Clear sensitive memory without getting optimized out (revival of #636) Merge bitcoin-core/secp256k1#1631: release: prepare for 0.6.0 Merge bitcoin-core/secp256k1#1633: release cleanup: bump version after 0.6.0 Merge bitcoin-core/secp256k1#1634: Fix some misspellings Merge bitcoin-core/secp256k1#1641: doc: Improve cmake instructions in README Merge bitcoin-core/secp256k1#1650: schnorrsig: clear out masked secret key in BIP-340 nonce function Merge bitcoin-core/secp256k1#1646: README: add instructions for verifying GPG signatures Merge bitcoin-core/secp256k1#1654: use `EXIT_` constants over magic numbers for indicating program execution status This PR can be recreated with `./contrib/sync-upstream.sh -b master range c0d9480`. Tips: * Use `git show --remerge-diff <pr-branch>` to show the conflict resolution in the merge commit. * Use `git read-tree --reset -u <pr-branch>` to replay these resolutions during the conflict resolution stage when recreating the PR branch locally. Be aware that this may discard your index as well as the uncommitted changes and untracked files in your worktree. ### zkp fixes for Valgrind compatibility PR #1579 introduced `secp256k1_memclear` that marks cleared memory as undefined. Updated rangeproof to use `memset`/`secp256k1_scalar_set_int` for initialization, keeping `memclear` only for cleanup. ACKs for top commit: real-or-random: ACKe3bddfa750Tree-SHA512: 7a089d1c6cb34dd0706d53a9a92c0aecc6183a60c77de147ba97db9133bb96031aa2178e0cc07017c76fb30048697c1d976eb7b6c206fa50984d28487cf023f6
01b58933 18f9b967 e59158b6 1fae76f5 f0868a9b 68b55209 9b7c59cb 1464f15c 9a8db52f 7d48f5ed a38d879a ' into temp-merge-1628
0cdc758a ec329c25 8deef00b f79f46c7 00774d07 2e3bf136 c0d9480f ' into temp-merge-1654
3aef6ab8 0fa84f86 249c81ea 7966aee3 fb758fe8 3fc1de5c 0aacf643 9e6d1b0e 332af315 afd7eb4a c9ebca95 cc557575 0f7657d5 907a6721 b40e2d30 c545fdc3 2bd5f3e6 0e00fc7d c734c642 26392da2 ' into temp-merge-1386
0cdc758a ec329c25 8deef00b f79f46c7 00774d07 2e3bf136 c0d9480f ' into temp-merge-1654
0cdc758a ec329c25 8deef00b f79f46c7 00774d07 2e3bf136 c0d9480f ' into temp-merge-1654
0cdc758a ec329c25 8deef00b f79f46c7 00774d07 2e3bf136 c0d9480f ' into temp-merge-1654
0cdc758a ec329c25 8deef00b f79f46c7 00774d07 2e3bf136 c0d9480f ' into temp-merge-1654
0cdc758a ec329c25 8deef00b f79f46c7 00774d07 2e3bf136 c0d9480f ' into temp-merge-1654
libsecp256k1-zkp
A fork of libsecp256k1 with support for advanced and experimental features
Added features:
- Experimental module for ECDSA adaptor signatures.
- Experimental module for ECDSA sign-to-contract.
- Experimental module for Confidential Assets (Pedersen commitments, range proofs, and surjection proofs).
- Experimental module for Bulletproofs++ range proofs.
- Experimental module for address whitelisting.
Experimental features are made available for testing and review by the community. The APIs of these features should not be considered stable.
Build steps
Obtaining and verifying
The git tag for each release (e.g. v0.6.0) is GPG-signed by one of the maintainers.
For a fully verified build of this project, it is recommended to obtain this repository
via git, obtain the GPG keys of the signing maintainer(s), and then verify the release
tag's signature using git.
This can be done with the following steps:
- Obtain the GPG keys listed in SECURITY.md.
- If possible, cross-reference these key IDs with another source controlled by its owner (e.g. social media, personal website). This is to mitigate the unlikely case that incorrect content is being presented by this repository.
- Clone the repository:
git clone https://github.com/bitcoin-core/secp256k1 - Check out the latest release tag, e.g.
git checkout v0.6.0 - Use git to verify the GPG signature:
% git tag -v v0.6.0 | grep -C 3 'Good signature' gpg: Signature made Mon 04 Nov 2024 12:14:44 PM EST gpg: using RSA key 4BBB845A6F5A65A69DFAEC234861DBF262123605 gpg: Good signature from "Jonas Nick <jonas@n-ck.net>" [unknown] gpg: aka "Jonas Nick <jonasd.nick@gmail.com>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 36C7 1A37 C9D9 88BD E825 08D9 B1A7 0E4F 8DCD 0366 Subkey fingerprint: 4BBB 845A 6F5A 65A6 9DFA EC23 4861 DBF2 6212 3605
Building with Autotools
$ ./autogen.sh # Generate a ./configure script
$ ./configure # Generate a build system
$ make # Run the actual build process
$ make check # Run the test suite
$ sudo make install # Install the library into the system (optional)
To compile optional modules (such as Schnorr signatures), you need to run ./configure with additional flags (such as --enable-module-schnorrsig). Run ./configure --help to see the full list of available flags. For experimental modules, you will also need --enable-experimental as well as a flag for each individual module, e.g. --enable-module-rangeproof.
Building with CMake (experimental)
To maintain a pristine source tree, CMake encourages to perform an out-of-source build by using a separate dedicated build tree.
Building on POSIX systems
$ cmake -B build # Generate a build system in subdirectory "build"
$ cmake --build build # Run the actual build process
$ ctest --test-dir build # Run the test suite
$ sudo cmake --install build # Install the library into the system (optional)
To compile optional modules (such as Schnorr signatures), you need to run cmake with additional flags (such as -DSECP256K1_ENABLE_MODULE_SCHNORRSIG=ON). Run cmake -B build -LH or ccmake -B build to see the full list of available flags.
Cross compiling
To alleviate issues with cross compiling, preconfigured toolchain files are available in the cmake directory.
For example, to cross compile for Windows:
$ cmake -B build -DCMAKE_TOOLCHAIN_FILE=cmake/x86_64-w64-mingw32.toolchain.cmake
To cross compile for Android with NDK (using NDK's toolchain file, and assuming the ANDROID_NDK_ROOT environment variable has been set):
$ cmake -B build -DCMAKE_TOOLCHAIN_FILE="${ANDROID_NDK_ROOT}/build/cmake/android.toolchain.cmake" -DANDROID_ABI=arm64-v8a -DANDROID_PLATFORM=28
Building on Windows
To build on Windows with Visual Studio, a proper generator must be specified for a new build tree.
The following example assumes using of Visual Studio 2022 and CMake v3.21+.
In "Developer Command Prompt for VS 2022":
>cmake -G "Visual Studio 17 2022" -A x64 -B build
>cmake --build build --config RelWithDebInfo
Usage examples
Usage examples can be found in the examples directory. To compile them you need to configure with --enable-examples.
- ECDSA example
- Schnorr signatures example
- Deriving a shared secret (ECDH) example
- ElligatorSwift key exchange example
To compile the Schnorr signature and ECDH examples, you need to enable the corresponding module by providing a flag to the configure script, for example --enable-module-schnorrsig.
Benchmark
If configured with --enable-benchmark (which is the default), binaries for benchmarking the libsecp256k1-zkp functions will be present in the root directory after the build.
To print the benchmark result to the command line:
$ ./bench_name
To create a CSV file for the benchmark result :
$ ./bench_name | sed '2d;s/ \{1,\}//g' > bench_name.csv
Reporting a vulnerability
See SECURITY.md
Contributing to libsecp256k1
See CONTRIBUTING.md