![]() d8311688bd Merge bitcoin-core/secp256k1#1515: ci: Note affected clangs in comment on ASLR quirk a85e2233e7 ci: Note affected clangs in comment on ASLR quirk 4b77fec67a Merge bitcoin-core/secp256k1#1512: msan: notate more variable assignments from assembly code f7f0184ba1 msan: notate more variable assignments from assembly code a61339149f change inconsistent array param to pointer 05bfab69ae Merge bitcoin-core/secp256k1#1507: ci: Add workaround for ASLR bug in sanitizers a5e8ab2484 ci: Add sanitizer env variables to debug output 84a93de4d2 ci: Add workaround for ASLR bug in sanitizers 427e86b9ed Merge bitcoin-core/secp256k1#1490: tests: improve fe_sqr test (issue #1472) 2028069df2 doc: clarify input requirements for secp256k1_fe_mul 11420a7a28 tests: improve fe_sqr test cdc9a6258e Merge bitcoin-core/secp256k1#1489: tests: add missing fe comparison checks for inverse field test cases d926510cf7 Merge bitcoin-core/secp256k1#1496: msan: notate variable assignments from assembly code 31ba404944 msan: notate variable assignments from assembly code e7ea32e30a msan: Add SECP256K1_CHECKMEM_MSAN_DEFINE which applies to memory sanitizer and not valgrind e7bdddd9c9 refactor: rename `check_fe_equal` -> `fe_equal` 00111c9c56 tests: add missing fe comparison checks for inverse field test cases 0653a25d50 Merge bitcoin-core/secp256k1#1486: ci: Update cache action 94a14d5290 ci: Update cache action 2483627299 Merge bitcoin-core/secp256k1#1483: cmake: Recommend native CMake commands in README 5ad3aa3dcd Merge bitcoin-core/secp256k1#1484: tests: Drop redundant _scalar_check_overflow calls 51df2d9ab3 tests: Drop redundant _scalar_check_overflow calls 3777e3f36a cmake: Recommend native CMake commands in README e4af41c61b Merge bitcoin-core/secp256k1#1249: cmake: Add `SECP256K1_LATE_CFLAGS` configure option 3bf4d68fc0 Merge bitcoin-core/secp256k1#1482: build: Clean up handling of module dependencies e6822678ea build: Error if required module explicitly off 89ec583ccf build: Clean up handling of module dependencies 44378867a0 Merge bitcoin-core/secp256k1#1468: v0.4.1 release aftermath a9db9f2d75 Merge bitcoin-core/secp256k1#1480: Get rid of untested sizeof(secp256k1_ge_storage) == 64 code path 74b7c3b53e Merge bitcoin-core/secp256k1#1476: include: make docs more consistent b37fdb28ce check-abi: Minor UI improvements ad5f589a94 check-abi: Default to HEAD for new version 9fb7e2f156 release process: Style and formatting nits ba5d72d626 assumptions: Use new STATIC_ASSERT macro e53c2d9ffc Require that sizeof(secp256k1_ge_storage) == 64 d0ba2abbff util: Add STATIC_ASSERT macro da7bc1b803 include: in doc, remove article in front of "pointer" aa3dd5280b include: make doc about ctx more consistent e3f690015a include: remove obvious "cannot be NULL" doc d373bf6d08 Merge bitcoin-core/secp256k1#1474: tests: restore scalar_mul test 79e094517c Merge bitcoin-core/secp256k1#1473: Fix typos 3dbfb48946 tests: restore scalar_mul test d77170a88d Fix typos e7053d065b release process: Add email step 429d21dc79 release process: Run sanity checks on release PR 42f8c51402 cmake: Add `SECP256K1_LATE_CFLAGS` configure option git-subtree-dir: src/secp256k1 git-subtree-split: d8311688bd383d3a923a1b11789cded3cc8e5e03 |
||
---|---|---|
.github | ||
build-aux/m4 | ||
ci | ||
cmake | ||
contrib | ||
doc | ||
examples | ||
include | ||
sage | ||
src | ||
tools | ||
.cirrus.yml | ||
.gitattributes | ||
.gitignore | ||
autogen.sh | ||
CHANGELOG.md | ||
CMakeLists.txt | ||
CMakePresets.json | ||
configure.ac | ||
CONTRIBUTING.md | ||
COPYING | ||
libsecp256k1.pc.in | ||
Makefile.am | ||
README.md | ||
SECURITY.md |
libsecp256k1
High-performance high-assurance C library for digital signatures and other cryptographic primitives on the secp256k1 elliptic curve.
This library is intended to be the highest quality publicly available library for cryptography on the secp256k1 curve. However, the primary focus of its development has been for usage in the Bitcoin system and usage unlike Bitcoin's may be less well tested, verified, or suffer from a less well thought out interface. Correct usage requires some care and consideration that the library is fit for your application's purpose.
Features:
- secp256k1 ECDSA signing/verification and key generation.
- Additive and multiplicative tweaking of secret/public keys.
- Serialization/parsing of secret keys, public keys, signatures.
- Constant time, constant memory access signing and public key generation.
- Derandomized ECDSA (via RFC6979 or with a caller provided function.)
- Very efficient implementation.
- Suitable for embedded systems.
- No runtime dependencies.
- Optional module for public key recovery.
- Optional module for ECDH key exchange.
- Optional module for Schnorr signatures according to BIP-340.
Implementation details
- General
- No runtime heap allocation.
- Extensive testing infrastructure.
- Structured to facilitate review and analysis.
- Intended to be portable to any system with a C89 compiler and uint64_t support.
- No use of floating types.
- Expose only higher level interfaces to minimize the API surface and improve application security. ("Be difficult to use insecurely.")
- Field operations
- Optimized implementation of arithmetic modulo the curve's field size (2^256 - 0x1000003D1).
- Using 5 52-bit limbs
- Using 10 26-bit limbs (including hand-optimized assembly for 32-bit ARM, by Wladimir J. van der Laan).
- This is an experimental feature that has not received enough scrutiny to satisfy the standard of quality of this library but is made available for testing and review by the community.
- Optimized implementation of arithmetic modulo the curve's field size (2^256 - 0x1000003D1).
- Scalar operations
- Optimized implementation without data-dependent branches of arithmetic modulo the curve's order.
- Using 4 64-bit limbs (relying on __int128 support in the compiler).
- Using 8 32-bit limbs.
- Optimized implementation without data-dependent branches of arithmetic modulo the curve's order.
- Modular inverses (both field elements and scalars) based on safegcd with some modifications, and a variable-time variant (by Peter Dettman).
- Group operations
- Point addition formula specifically simplified for the curve equation (y^2 = x^3 + 7).
- Use addition between points in Jacobian and affine coordinates where possible.
- Use a unified addition/doubling formula where necessary to avoid data-dependent branches.
- Point/x comparison without a field inversion by comparison in the Jacobian coordinate space.
- Point multiplication for verification (aP + bG).
- Use wNAF notation for point multiplicands.
- Use a much larger window for multiples of G, using precomputed multiples.
- Use Shamir's trick to do the multiplication with the public key and the generator simultaneously.
- Use secp256k1's efficiently-computable endomorphism to split the P multiplicand into 2 half-sized ones.
- Point multiplication for signing
- Use a precomputed table of multiples of powers of 16 multiplied with the generator, so general multiplication becomes a series of additions.
- Intended to be completely free of timing sidechannels for secret-key operations (on reasonable hardware/toolchains)
- Access the table with branch-free conditional moves so memory access is uniform.
- No data-dependent branches
- Optional runtime blinding which attempts to frustrate differential power analysis.
- The precomputed tables add and eventually subtract points for which no known scalar (secret key) is known, preventing even an attacker with control over the secret key used to control the data internally.
Building with Autotools
$ ./autogen.sh
$ ./configure
$ make
$ make check # run the test suite
$ sudo make install # 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.
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
$ mkdir build && cd build
$ cmake ..
$ cmake --build .
$ ctest # run the test suite
$ sudo cmake --build . --target install # 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 .. -LH
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 .. -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 .. -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 -S . -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
.
To compile the Schnorr signature and ECDH examples, you also need to configure with --enable-module-schnorrsig
and --enable-module-ecdh
.
Benchmark
If configured with --enable-benchmark
(which is the default), binaries for benchmarking the libsecp256k1 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