#bls12-381 #signature

no-std blsful

BLS signature implementation according to the IETF spec on the BLS12-381 curve

45 releases (28 stable)

Uses new Rust 2024

4.0.0 Jul 31, 2026
3.1.0 Feb 3, 2026
3.0.0 Sep 29, 2025
3.0.0-pre8 Dec 5, 2024
1.2.0 Mar 30, 2023

#501 in Cryptography

Download history 2457/week @ 2026-04-22 2484/week @ 2026-04-29 2627/week @ 2026-05-06 2431/week @ 2026-05-13 2209/week @ 2026-05-20 1879/week @ 2026-05-27 1961/week @ 2026-06-03 1681/week @ 2026-06-10 1800/week @ 2026-06-17 2637/week @ 2026-06-24 2206/week @ 2026-07-01 2712/week @ 2026-07-08 3012/week @ 2026-07-15 2780/week @ 2026-07-22 2593/week @ 2026-07-29 3906/week @ 2026-08-05

12,778 downloads per month
Used in 11 crates (6 directly)

MIT/Apache

675KB
4.5K SLoC

BLS Signature Scheme

Crate Docs Apache 2.0/MIT Licensed

The blsful crate provides a production-ready BLS signature implementation.

Security Notes

This crate has received one security audit from Kudelski Security, with no significant findings. The audit report can be found here. We'd like to thank LIT Protocol for sponsoring this audit.

All operations are constant time unless explicitly noted.

Documentation

BLS signatures offer the smallest known signature size, as well as other benefits such as one-round threshold signing and signature aggregation.

BLS signatures rely on pairing-friendly curves that have two groups for points. This library provides keys and signatures for both groups.

Use Bls12381G1Impl for signatures in G1 and public keys in G2, or Bls12381G2Impl for signatures in G2 and public keys in G1. The *Enum types are available when that choice is only known at runtime.

The high-level signcryption and time-lock methods return complete ciphertext types. The lower-level sealing and timestamp-proof traits return named SignCryptCiphertextParts, TimeCryptCiphertextParts, and TimestampProofParts values instead of three-value tuples.

This library supports threshold signatures in the form of SignatureShare values generated from SecretKeyShare values instead of a SecretKey. SignatureShare values can be combined to make a full Signature when enough shares are available to meet the threshold. SecretKeyShare values can be generated using Shamir secret sharing from crates like vsss-rs or using distributed key generation methods like gennaro-dkg.

Multi-signatures aggregate signatures over the same message. This allows signature compression and very fast verification, assuming rogue-key attacks have been addressed by using proofs of possession. This library currently provides only the proof-of-possession scheme, as it is the most widely used.

Aggregate signatures combine signatures over different messages. While verification is not much faster, this still allows signature compression.

Examples

Key operations

From a random entropy source:

use blsful::{Bls12381G1Impl, SecretKey};

let sk = SecretKey::<Bls12381G1Impl>::new();
let pk = sk.public_key();
let pop = sk.proof_of_possession().expect("a proof of possession");
pop.verify(&pk).expect("a valid proof");

From a seed:

use blsful::{Bls12381G1Impl, PublicKey, SecretKey};

let sk = SecretKey::<Bls12381G1Impl>::from_hash(b"seed phrase");
let pk = PublicKey::from(&sk);

Split a key into key shares:

let shares = sk.split(3, 5).expect("valid threshold parameters");

Restore a key from shares:

let sk = SecretKey::<Bls12381G1Impl>::combine(&shares).expect("enough valid shares");

Signature operations

Create a signature:

let message = b"00000000-0000-0000-0000-000000000000";
let sig = sk.sign_basic(message).expect("a valid signature");

Verify a signature:

sig.verify(&pk, message).expect("a valid signature");

License

Licensed under either of

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual-licensed as above, without any additional terms or conditions.

References

  1. IETF Spec

Dependencies

~9MB
~188K SLoC