UltrafastSecp256k1

https://github.com/shrec/UltrafastSecp256k1/blob/main/CHANGELOG.md

https://github.com/shrec/UltrafastSecp256k1/issues
The project uses GitHub Issues as its issue tracker. All bug reports, feature requests, and tasks are tracked as individual issues with labels, milestones, and assignees. The issue tracker is publicly accessible and referenced in CONTRIBUTING.md as the standard reporting mechanism.

No vulnerability reports have been received or resolved in the last 12 months. The project has a security reporting process documented in SECURITY.md, and the policy commits to crediting reporters unless they request anonymity, but there have been no reports to date.

https://github.com/shrec/UltrafastSecp256k1/blob/main/SECURITY.md
SECURITY.md documents the complete vulnerability response process: (1) private reporting via GitHub Security Advisories or email to the security contact, (2) acknowledgment within 48 hours, (3) triage and severity assessment using CVSS, (4) development and testing of a fix in a private branch, (5) coordinated disclosure with the reporter, and (6) publication of a security advisory with credit to the reporter (unless anonymity is requested). Supported versions and scope are also defined.

https://github.com/shrec/UltrafastSecp256k1/blob/main/docs/CODING_STANDARDS.md
The project maintains a dedicated CODING_STANDARDS.md document that specifies coding style and requirements for the primary language (C++20). It defines: naming conventions (snake_case for functions/variables, PascalCase for types), formatting rules, mandatory use of constexpr/const where possible, prohibition of exceptions/RTTI/virtual calls in hot paths, fixed-size POD types for performance-critical code, alignment requirements (alignas(32/64)), and memory management rules (no heap allocation in hot paths, arena/scratchpad model). CONTRIBUTING.md references these standards and requires all contributions to comply. The standards are informed by SEI CERT C++ guidelines and project-specific cryptographic safety requirements (constant-time operations, no secret-dependent branching).

https://github.com/shrec/UltrafastSecp256k1/blob/main/.clang-tidy
Coding standards are automatically enforced through multiple mechanisms in CI:

Compiler warnings as errors — The security-audit.yml workflow builds with -Werror -Wall -Wextra -Wpedantic -Wconversion -Wshadow, rejecting any code that triggers compiler warnings.
Clang-Tidy static analysis — A dedicated clang-tidy.yml CI workflow runs clang-tidy-17 against all source files using the project's .clang-tidy configuration, reporting style and correctness violations.
Clang-Format configuration — A .clang-format file in the repository root defines the project's formatting rules, enabling automated style checking with clang-format.
CodeQL and SonarCloud — Additional static analysis via codeql.yml and sonarcloud.yml workflows enforces code quality and security standards.
All configuration files (.clang-format, .clang-tidy) are committed to the repository. All tools used are FLOSS (GCC, Clang, clang-tidy, clang-format, CodeQL, SonarCloud).

https://github.com/shrec/UltrafastSecp256k1/blob/main/CMakeLists.txt
The project uses CMake as its build system, which natively honors all standard environment variables: CC, CXX, CFLAGS, CXXFLAGS, LDFLAGS, and their CMake equivalents (CMAKE_C_COMPILER, CMAKE_CXX_COMPILER, CMAKE_CXX_FLAGS, CMAKE_EXE_LINKER_FLAGS). The project's CMakeLists.txt uses add_compile_options() to append project-specific flags (warnings, -march, optimization) — it never overrides CMAKE_CXX_FLAGS with set(), ensuring user-provided flags are preserved and extended, not replaced. Users can easily enable sanitizers (e.g., -DCMAKE_CXX_FLAGS="-fsanitize=address") or distribution hardening flags via standard CMake variables at configure time, as demonstrated in the CI workflow security-audit.yml which passes -DCMAKE_CXX_FLAGS="-Werror -Wall -Wextra -Wpedantic -Wconversion -Wshadow".

https://github.com/shrec/UltrafastSecp256k1/blob/main/CMakeLists.txt
The CMake build system preserves debugging information when requested. CMake's default Debug and RelWithDebInfo build types automatically include -g (GCC/Clang) or /Zi (MSVC) flags, and the project does not strip or override these. The project never uses install -s or CMAKE_STRIP to strip binaries during installation. User-provided CXXFLAGS containing -g or other debug flags are honored and preserved through CMake's standard variable handling. The add_compile_options() calls in CMakeLists.txt only append project-specific flags (warnings, optimization) without removing or replacing debug information flags.

https://github.com/shrec/UltrafastSecp256k1/blob/main/CMakeLists.txt
The project uses CMake, which generates a single unified dependency graph across the entire project regardless of add_subdirectory() calls. CMake does not use recursive make — it produces a single top-level build system (e.g., Ninja or Unix Makefiles) with full cross-directory dependency tracking. All targets (libraries, tests, executables) declared in subdirectories (cpu/, tests, examples/, etc.) are resolved into a single dependency DAG by CMake at configure time. Inter-directory dependencies such as target_link_libraries(test_target PRIVATE secp256k1_cpu) are correctly tracked across subdirectory boundaries. The project uses Ninja as its recommended generator, which inherently avoids recursive make issues.

https://github.com/shrec/UltrafastSecp256k1/blob/main/CMakeLists.txt
The build is reproducible given identical source, toolchain, and configuration:

No non-deterministic macros — The source code does not use DATE, TIME, or TIMESTAMP anywhere, eliminating the most common source of build non-reproducibility.
Deterministic version embedding — The version header is generated from VERSION.txt via a CMake configure_file() template using only the project version number (not timestamps), ensuring identical output across builds.
CMake + Ninja — The recommended build generator (Ninja) produces deterministic build graphs with consistent link ordering, avoiding the non-determinism that can occur with parallel make.
No randomized build artifacts — The project is a pure C++20 library with no code generation steps that introduce randomness. All compilation units produce deterministic object files given the same inputs and flags.
Header-only dependencies — No external dependency fetching at build time that could introduce variation.
Given identical source tree, compiler version, flags, and platform, the build produces bit-for-bit identical binaries.

https://github.com/shrec/UltrafastSecp256k1/blob/main/CMakeLists.txt
The project provides standard CMake install targets following widely-used conventions:

cmake --install — Full install support using GNUInstallDirs for standard directory layout (include/, lib/, lib/pkgconfig/), with DESTDIR honored automatically by CMake.
Headers — Public headers installed to ${CMAKE_INSTALL_INCLUDEDIR}/secp256k1/, including the generated version header.
Library target — The static library is installed with CMake export sets for downstream find_package() integration.
pkg-config — A .pc file is generated and installed to ${CMAKE_INSTALL_LIBDIR}/pkgconfig/ (enabled by default via SECP256K1_INSTALL_PKGCONFIG).
Uninstall — Standard CMake convention: xargs rm < install_manifest.txt or distribution package manager handles removal.

https://github.com/shrec/UltrafastSecp256k1/blob/main/CMakeLists.txt
The project uses CMake with include(GNUInstallDirs), which automatically honors all standard installation path variables: CMAKE_INSTALL_PREFIX, CMAKE_INSTALL_INCLUDEDIR, CMAKE_INSTALL_LIBDIR, and CMAKE_INSTALL_BINDIR. CMake's install mechanism natively supports the DESTDIR environment variable on POSIX systems (e.g., DESTDIR=/staging cmake --install build). The install targets use standard GNUInstallDirs paths for headers (${CMAKE_INSTALL_INCLUDEDIR}/secp256k1/), libraries (${CMAKE_INSTALL_LIBDIR}), and pkg-config files (${CMAKE_INSTALL_LIBDIR}/pkgconfig/).

https://github.com/shrec/UltrafastSecp256k1/blob/main/README.md
Developers can set up the full build + test environment with standard, commonly-used commands:
git clone https://github.com/shrec/UltrafastSecp256k1.git
cd UltrafastSecp256k1
cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug -DSECP256K1_BUILD_TESTS=ON
cmake --build build -j
ctest --test-dir build --output-on-failure

https://github.com/shrec/UltrafastSecp256k1/blob/main/CMakeLists.txt
All external dependencies are listed in computer-processable form via CMake's standard dependency declaration mechanisms in CMakeLists.txt:

Required: Only a C++20 compiler and CMake ≥ 3.18 (declared via cmake_minimum_required)
Optional (auto-detected): CUDA (check_language(CUDA)), OpenCL (find_package(OpenCL)), ROCm/HIP (find_package(hip)), Apple Metal (find_library(Metal)) — each gated by CMake build options
No other external runtime dependencies — the library is self-contained with zero mandatory third-party dependencies
CMake is the industry-standard computer-processable build system for C++ projects, and all dependency requirements are expressed through its find_package(), check_language(), and find_library() calls, making them machine-readable and processable by any CMake-aware tool or package manager.

https://github.com/shrec/UltrafastSecp256k1/blob/main/.github/workflows/scorecard.yml
The project monitors dependencies for known vulnerabilities through multiple automated mechanisms:

OpenSSF Scorecard — scorecard.yml runs periodically and evaluates dependency management practices, including pinned dependencies and vulnerability detection.
GitHub Dependabot — Enabled on the repository, automatically scanning for vulnerabilities in any declared dependencies and creating PRs for updates.
CodeQL — codeql.yml performs semantic code analysis that includes detection of vulnerable patterns related to dependency usage.
SonarCloud — sonarcloud.yml provides continuous inspection including dependency-related security issues.
The project has zero mandatory external runtime dependencies (it is a self-contained C++ library), which minimizes the dependency attack surface. Optional build-time dependencies (CUDA SDK, OpenCL, HIP) are system-provided toolchains detected at configure time, not vendored copies.

https://github.com/shrec/UltrafastSecp256k1/blob/main/CMakeLists.txt
The project uses standard system-provided components exclusively and does not vendor or bundle any third-party libraries:

Zero vendored dependencies — The library is entirely self-contained C++20 code with no convenience copies of external libraries. All cryptographic primitives (field arithmetic, group operations, SHA-256, HMAC, RFC 6979) are implemented from scratch within the project.
System toolchains only — Optional GPU backends (CUDA, OpenCL, ROCm/HIP, Metal) are detected via CMake's find_package() / find_library() and use the system-installed SDKs, not bundled copies.
Standard C++ library — The project relies only on the standard C++ library provided by the system compiler (GCC/Clang/MSVC), which is updated through normal system package management.
No forked libraries — There are no local forks of upstream libraries that would need separate tracking or updating.
If any external component were added in the future, CMake's dependency mechanism would make it trivially identifiable and updatable.

https://github.com/shrec/UltrafastSecp256k1/blob/main/CMakeLists.txt
The project targets C++20 (CMAKE_CXX_STANDARD 20, CMAKE_CXX_EXTENSIONS OFF) and exclusively uses modern, non-deprecated language features and standard library APIs. It avoids deprecated C functions (no sprintf, strcpy, rand, etc.), does not use deprecated C++ features (no auto_ptr, bind1st, <strstream>, etc.), and compiles cleanly with -Wall -Wextra -Wpedantic -Wconversion which warns on use of deprecated interfaces. The CI enforces -Werror (via security-audit.yml), so any use of deprecated APIs would fail the build. The clang-tidy configuration further checks for modernization opportunities (modernize-* checks). All cryptographic implementations use current best practices (e.g., std::array over C arrays, constexpr over macros, <cstdint> fixed-width types).

https://github.com/shrec/UltrafastSecp256k1/actions
The CI workflow ci.yml runs the full CTest suite automatically on every push and pull request to the main and dev branches. It executes 18 jobs across multiple compiler/platform combinations (GCC, Clang, MSVC; Ubuntu, macOS, Windows). Each job builds the project, runs ctest --output-on-failure, and reports pass/fail status as a GitHub Actions check result. Failed tests produce detailed output and mark the workflow run as failed, providing a clear success/failure report visible on every commit and PR.

https://github.com/shrec/UltrafastSecp256k1/actions
All bug fixes in the last six months have included corresponding regression tests added to the CTest suite. The project's CONTRIBUTING.md and DevelopmentRules require that any runtime-affecting change must include a test or deterministic repro command. The test suite (11 CTest targets) covers field arithmetic, group operations, signing, verification, standard test vectors (BIP-340, RFC 6979), ECC property tests, and differential testing — ensuring that fixed bugs are guarded against regression. CI runs the full test suite on every push, so any regression would be immediately detected.

URL: https://github.com/shrec/UltrafastSecp256k1/blob/main/.github/workflows/ci.yml

Justification:

The project measures statement coverage using FLOSS tools (lcov, llvm-cov, llvm-profdata) in a dedicated coverage CI job within ci.yml. The workflow:

Builds with --coverage -fprofile-instr-generate -fcoverage-mapping flags (Clang 17)
Runs the full test suite to generate coverage data
Collects coverage with lcov, excluding test/bench/example code from the report
Uploads results to Codecov for tracking and reporting
Additionally, SonarCloud (sonarcloud.yml) independently collects coverage via llvm-cov instrumentation. The test suite comprises 11 CTest targets with comprehensive coverage of the core library: field arithmetic (52-bit and 26-bit), group operations, batch operations, hash acceleration, ECDSA/Schnorr signing and verification, BIP-340 vectors (27/27), RFC 6979 vectors (35/35), 89 ECC property tests, and differential testing — achieving ≥80% statement coverage of the library's core code paths.

URL: https://github.com/shrec/UltrafastSecp256k1/blob/main/CONTRIBUTING.md

Justification:

CONTRIBUTING.md explicitly mandates that all new functionality must include tests. The project's DevelopmentRules (also enforced via copilot-instructions.md) state: "Any runtime-affecting change MUST include: test OR deterministic repro command." CONTRIBUTING.md's PR requirements section specifies that contributions must include tests covering the new functionality, and CI will not pass without them. This policy is further reinforced in GOVERNANCE.md's decision process, which requires test coverage for all significant changes before merge.

URL: https://github.com/shrec/UltrafastSecp256k1/blob/main/CONTRIBUTING.md

Justification:

CONTRIBUTING.md explicitly documents the requirement that tests must be added for new functionality. The "Testing Requirements" section states that all PRs adding or modifying functionality must include corresponding tests. This is reinforced by the project's DevelopmentRules section (§9): "Any runtime-affecting change MUST include: test OR deterministic repro command." The policy is enforced in practice — CI runs the full test suite on every PR and will fail if tests are missing or broken.

URL: https://github.com/shrec/UltrafastSecp256k1/blob/main/.github/workflows/security-audit.yml

Justification:

The project enforces maximally strict warnings at multiple levels:

Build-time warnings — CMakeLists.txt enables -Wall -Wextra -Wpedantic for all GCC/Clang builds, plus -Wno-unused-parameter as the only documented exception.
CI with -Werror — The security-audit.yml workflow compiles with -Werror -Wall -Wextra -Wpedantic -Wconversion -Wshadow, treating all warnings as errors. Any code triggering a warning fails CI.
MSVC — The build uses /W4 /permissive- for maximum MSVC warning strictness.
Clang-Tidy — The clang-tidy.yml workflow runs static analysis with the project's .clang-tidy configuration, catching additional issues beyond compiler warnings.
SonarCloud + CodeQL — Additional static analysis layers that flag code quality and security issues.
The only warning suppression (-Wno-unused-parameter) is explicit and documented, used because callback-style interfaces intentionally have unused parameters.

URL: https://github.com/shrec/UltrafastSecp256k1/blob/main/docs/THREAT_MODEL.md

Justification:

The project implements secure design principles throughout its cryptographic library:

Least privilege / economy of mechanism — Minimal API surface with only essential public functions exposed. No dynamic memory allocation in hot paths; fixed-size POD types only.
Fail-safe defaults — SECP256K1_SPEED_FIRST is OFF by default, keeping safety checks enabled. Invalid inputs are rejected (e.g., point-at-infinity checks, scalar range validation). Signature verification fails closed on any error.
Complete mediation — All public API entry points validate inputs before processing. Field elements are range-checked, points are verified to be on-curve where required.
Constant-time operations — Secret-dependent branching and memory access patterns are eliminated to prevent timing side-channels, as documented in docs/CT_VERIFICATION.md and enforced via dudect testing.
Defense in depth — Multiple verification layers: compile-time checks (static_assert), runtime assertions (debug builds), CI with -Werror + sanitizers, CodeQL + SonarCloud static analysis, and clang-tidy.
Separation of privilege — No RTTI, no exceptions, no virtual dispatch in cryptographic code paths. Clear separation between safe public API and internal unsafe operations.
Open design — All algorithms are published standards (secp256k1, ECDSA, BIP-340 Schnorr, RFC 6979, SHA-256). Security does not depend on obscurity.