28 stable releases (7 major)

8.0.2 Feb 9, 2023
8.0.1 Nov 17, 2022
7.1.0 Oct 24, 2022
7.0.0 Jul 15, 2022
1.0.1 Jun 28, 2021

#210 in Cryptography

Download history 1786/week @ 2023-12-11 1374/week @ 2023-12-18 616/week @ 2023-12-25 1049/week @ 2024-01-01 1745/week @ 2024-01-08 2166/week @ 2024-01-15 2759/week @ 2024-01-22 3721/week @ 2024-01-29 3465/week @ 2024-02-05 4013/week @ 2024-02-12 7437/week @ 2024-02-19 4140/week @ 2024-02-26 7257/week @ 2024-03-04 5766/week @ 2024-03-11 5549/week @ 2024-03-18 5608/week @ 2024-03-25

24,255 downloads per month
Used in 29 crates (21 directly)

MIT/Apache

150KB
3K SLoC

BLST Threshold Crypto (blsttc)

A pairing-based threshold cryptosystem for collaborative decryption and signatures.

The blsttc crate provides cryptographic keys with methods for signing and encrypting messages, as well as key sets for threshold signatures and threshold encryption.

blsttc is an adaptation of the threshold_crypto crate using blast (blst) for signing and verification speed improvements.

The threshold signature scheme is described in Threshold Signatures, Multisignatures and Blind Signatures Based on the Gap-Diffie-Hellman-Group Signature Scheme by Alexandra Boldyreva. This paper extends Boneh-Lynn-Shacham signatures to the threshold setting. Message encryption uses the scheme by Baek and Zhang. Our implementation is based on the pairing elliptic curve library.

In a network environment, messages are signed and encrypted, and key and signature shares are distributed to network participants. A message can be decrypted and authenticated only with cooperation from at least threshold + 1 nodes.

Security Audit

An official security audit has been completed on threshold_crypto by Jean-Philippe Aumasson. No exploitable security issues were found, and potential improvements have been addressed. Outdated dependencies mentioned in the audit were updated in commit 54026f5.

Note: This library makes no attempt at ensuring constant time operations and as such may leak information that could be used in a timing side-channel attack.

Usage

Cargo.toml:

[dependencies]
blsttc = "0.4.1"

main.rs:

extern crate rand;
extern crate blsttc;

use blsttc::SecretKey;

/// Very basic secret key usage.
fn main() {
    let sk0 = SecretKey::random();
    let sk1 = SecretKey::random();

    let pk0 = sk0.public_key();

    let msg0 = b"Real news";
    let msg1 = b"Fake news";

    assert!(pk0.verify(&sk0.sign(msg0), msg0));
    assert!(!pk0.verify(&sk1.sign(msg0), msg0)); // Wrong key.
    assert!(!pk0.verify(&sk0.sign(msg1), msg0)); // Wrong message.
}

Testing

Run tests with:

$ cargo test

Examples

Run examples from the examples directory using:

$ cargo run --example <example name>

Also see the distributed_key_generation test.

Application Details

The basic usage outline is:

  • choose a threshold value t
  • create a key set
  • distribute N secret key shares among the participants
  • publish the public master key

A third party can now encrypt a message to the public master key and any set of t + 1 participants (but no fewer!) can collaborate to decrypt it. Also, any set of t + 1 participants can collaborate to sign a message, producing a signature that is verifiable with the public master key.

In this system, a signature is unique and independent of the set of participants that produced it. If S1 and S2 are signatures for the same message, produced by two different sets of t + 1 secret key share holders, both signatures will be valid AND equal. This is useful in some applications, for example a message signature can serve as a pseudorandom number unknown to anyone until t + 1 participants agree to reveal it.

In its simplest form, threshold_crypto requires a trusted dealer to produce and distribute the secret key shares. However, keys can be produced so that only the corresponding participant knows their secret in the end. This crate includes the basic tools to implement such a Distributed Key Generation scheme.

A major application for this library is within a distributed network that must tolerate up to t adversarial (malicious or faulty) nodes. Because t + 1 nodes are required to sign or reveal information, messages can be trusted by third-parties as representing the consensus of the network.

Performance

Benchmarking functionality is kept in the benches directory. You can run the benchmarks with the following command:

$ RUSTFLAGS="-C target_cpu=native" cargo bench

We use the criterion benchmarking library.

License

Licensed under either of:

at your option.

Contributing

See the CONTRIBUTING document for contribution, testing and pull request protocol.

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.

Dependencies

~4.5MB
~150K SLoC