Skip to content

Security: cryptidtech/multi-sig

Security

SECURITY.md

Security Policy

Overview

The multi-sig crate gives self-describing digital signatures. It follows the multisig specification. This document outlines the security properties, threat model, and guarantees of this crate.

std-only Status

This crate is std-only. It depends on std::collections::BTreeMap, std::fmt, and unsigned-varint with the std feature. The crypto dependency stack (blsful, ssh-key, chacha20poly1305) also requires std. A no_std conversion is not planned for this crate.

Release-Candidate Dependencies

This crate depends on the following release-candidate (RC) crate:

  • ssh-key = "0.7.0-rc.11" — SSH key and signature encoding

The blsful dependency is now on a stable release (4.0.0). The vsss-rs crate is a transitive dependency via blsful. It resolved to the stable release 6.0.1 in this version.

The ssh-key crate is on an RC version. No stable release exists at the time of writing. The crate keeps it on RC for three reasons:

  1. No stable release exists. The upstream maintainers of ssh-key have not published a stable (non-RC) release. The only alternatives are to vendor a fork (duplicating unaudited code) or to forgo the functionality. Neither is acceptable for this crate.
  2. RC is the actively-maintained line. The RC versions receive bug fixes, security patches, and API feedback. Staying on the latest RC keeps this crate current with upstream corrections, including vulnerability fixes. It does not freeze on an older, unpatched revision.
  3. The RC APIs this crate depends on are stable in practice. The surface area consumed (SSH key encoding) has not changed across the RC bumps this crate has tracked. Breaking changes are absorbed as part of routine maintenance.

This is a tracked acceptance. The RC version is reviewed on each upstream release. The crate is upgraded to the latest RC as they become available. It will migrate to stable when the upstream publishes one. Consumers should be aware that RC APIs may change before stabilisation.

Decoded-Size Caps

The decoder enforces these caps on untrusted wire data to mitigate CWE-400 (Uncontrolled Resource Consumption):

  • MAX_ATTRIBUTES = 256 — maximum number of attributes per Multisig.
  • MAX_DECODED_SIZE = 16 MiB — maximum total decoded bytes per Multisig. Tracked across the attribute decode loop.
  • MAX_THRESHOLD_PARTICIPANTS = 1024 — maximum threshold or limit value in a BLS signature share.
  • Per-attribute Varbytes payloads are individually capped by multi_util (16 MiB).

Exceeding any cap returns a clean Err (Error::TooManyAttributes, Error::InputTooLarge, or Error::TooManyParticipants). The decoder never panics on oversized input.

BLS12-381 Codec Inference

The deprecated Builder::new_from_bls_signature and Builder::new_from_bls_signature_share constructors infer the BLS12-381 codec (G1 vs G2) from the compressed-point byte length (48 bytes to G1, 96 bytes to G2). This is a heuristic, not cryptographic binding. Prefer new_from_bls_signature_with_codec and new_from_bls_signature_share_with_codec. They take an explicit codec parameter.

Memory Safety

  • No unsafe code. #![deny(unsafe_code)] is enforced at compile time.
  • Input validation. All decode paths validate lengths, attribute counts, and codec identifiers.

Reporting Vulnerabilities

Report security issues via the project GitHub issue tracker or privately to the maintainers.

There aren't any published security advisories