A pairing-based threshold cryptosystem for collaborative decryption and signatures used in HoneybadgerBFT implementation

Last update: Dec 29, 2022

Related tags

Cryptography threshold_crypto

Overview

threshold_crypto

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

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

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.

Usage

Cargo.toml:

[dependencies]
threshold_crypto = { version = "0.4", git = "https://github.com/poanetwork/threshold_crypto" }

main.rs:

extern crate rand;
extern crate threshold_crypto;

use threshold_crypto::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.

Documentation

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.

Mock cryptography

To speed up automatic tests of crates depending on threshold_crypto, the use-insecure-test-only-mock-crypto feature is available. Activating this feature will effectively disable encryption and should only be used during tests! Essentially, the underlying elliptic curves will be replaced by small finite fields, yielding a 10-200X speed-up in execution. The resulting ciphers can be trivially broken in a number of ways and should never be used in production.

License

Licensed under either of:

Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

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.

Comments

Add additional benchmarks

Here's a few additional benchmarks. I put in a Makefile to make running tests/benches a bit easier, but I can do that in a separate commit if you want (or remove it). I ran rustfmt per the contributing guide, but it decided several more files needed reformatting. =) Would you prefer that in a separate commit?

opened by fhaynes 10
Added 'MlockManager' to prevent early 'munlock'ing
Added MlockManager to secrets module.

Prevents unnecessary/duplicate calls to mlock for a page in memory, stops pages from being unlocked when they still contain secret values.

Added dependency page_size.

Closes issue #31
opened by DrPeterVanNostrand 8
TODO: Add a basic Readme

@vkomenda I've been told you may already be handling this or at least you have an example you want to use already but I'm happy to help if you can show me which example you want to use.

Or I'll just make something up :P

opened by c0gent 8
Add benchmark for combining signatures

This benchmark is based on how the test_threshold_sig uses the combine_signatures. Let me know if this benchmarks it correctly.

Is it worth adding in testing different thresholds?

opened by fhaynes 7
Add benchmarks.

Our implementation still uses naive and probably slow algorithms in several places, especially for polynomials and commitments, and we should look into optimizing them. Whether #13 leads anywhere or not, the first step is adding benchmarks. I'm mainly thinking of polynomial multiplication and interpolation, but the more we cover, the better.
good first issue

opened by afck 7
Change the license to MIT/Apache-2.0 by popular vote

The provisional GNU GPL license is too strong for this library and should be replaced with a more permissive one. MIT/Apache-2.0 has been chosen as a suitable candidate.

opened by vkomenda 7
Key serialization and deserialization

You already have some internal serde implementations for field elements (FieldWrap) and functions for converting Fr to a string and parsing it again. I think it would be nice to also have serde impls for secret/public keys and key shares (e.g. for config files of HBBFT nodes). Are you interested in PRs adding this functionality?

Or is the lack of these impls intentional and I should just define newtypes? I could imagine that to be the case because reliable memory zeroing is probably harder if you impl serde traits.

EDIT: I'm currently implementing serde for SecretKeyShares and haven't looked into the other key types yet, maybe they have serde impls. But at least for SecretKeyShare it's missing.

opened by sgeisler 5
Implement serde for secret keys
Fixes #73 . This implements a wrapper struct for secret keys SerdeSecret that enables these to be serialized and deserialized. I only intend to implement this for the non-mocked crypto because I didn't find a good generic interface to ser/de the underlying Fr struct, so I'm currently just taking the pub [u64, 4] out of the FrRepr.

[x] impl for SecretKey

[x] impl for SecretKeyShare

[ ] think about how to erase all stack copies of key material
opened by sgeisler 4
Added a bit iterator for signatures

This was supposed to be a pair PR with the matching hbbft branch to add a random_value optimization in Binary Agreement. However it can have other uses, e.g., emulating random coin flips given a signature.

opened by vkomenda 3
Change license, flesh out README a bit.
Expand readme

Change license

Closes https://github.com/poanetwork/threshold_crypto/issues/7 and https://github.com/poanetwork/threshold_crypto/issues/2

@andogro, I'll hand this off to you to refine the language in a separate PR as you see fit.

Many of the tests use private types or types with private constructors. I'll leave it to @vkomenda, @afck, and @DrPeterVanNostrand to build on the example and decide what you may want to make public for those purposes.

For now this is probably ready to merge.
opened by c0gent 3
Question: Any plans for updating pairing?

Hello, I was wondering if the maintainers have any plans for updating pairing and bls12-381 libraries for this repository. The reason I ask is because I'm having a bit of tough time implementing Aggregate Signatures using the primitives defined here.

The authors of pairing and bls12-381 have separated the codebase of those two repos, and pairing now is just a collection of types and traits whereas bls12-381 has the curve definition.

Here's my broken aggregate signature work if anyone is interested, I'm basically stuck on trying to find the right methods to calculate identity element in Gt and doing the subsequent operations to do core_aggregate_verify as mentioned in the IETF specification.

opened by vihu 2
Ring signature example?
Anyone know where I can find a Ring Signatures example or can provide one?

eg as described in:

https://crypto.stanford.edu/~dabo/pubs/papers/aggreg.pdf

http://isrc.ccs.asia.edu.tw/~vdoi/upload/JID190002/2020/1816-3548-2020-00015.pdf
opened by dan-da 2

Include DKG example

Would it be very difficult to add an example that does the key-setup using a DKG? Like replacing the following code in the examples:

        let mut rng = rand::thread_rng();
        let sk_set = SecretKeySet::random(threshold, &mut rng);
        let pk_set = sk_set.public_keys();

        let actors = (0..n_actors)
            .map(|id| {
                let sk_share = sk_set.secret_key_share(id);
                let pk_share = pk_set.public_key_share(id);
                Actor::new(id, sk_share, pk_share)
            })
            .collect();

With something where the dealer does not know the secret key!

opened by ineiti 3

Compatibility with other bls12-381 libraries
Compatibility between bls12-381 libraries might be useful. For example, etherum2, zcash, chia.net, algorand, dfinity are all using or plan to use bls12-381.

There's a simple single-key signature verification in this test which does not pass with threshold_crypto. The secret key can be imported to threshold_crypto and it gives the same public key as in the test, but the signature does not verify.

skbytes = [74,53,59,227,218,192,145,160,167,230,64,98,3,114,245,225,226,228,64,23,23,193,231,156,172,111,251,168,246,144,86,4] pkbytes = [133,105,95,203,192,108,196,196,201,69,31,77,206,33,203,248,222,62,90,19,191,72,244,76,219,177,142,32,56,186,123,139,177,99,45,121,17,239,30,46,8,116,155,221,191,22,83,82] msgbytes = [7,8,9] sigbytes = [184,250,166,214,163,136,28,159,219,173,128,59,23,13,112,202,92,191,30,107,165,165,134,38,45,243,104,199,90,205,29,31,250,58,182,238,33,199,31,132,68,148,101,152,120,245,235,35,12,149,141,213,118,176,139,133,100,170,210,238,9,146,232,90,30,86,95,41,156,213,58,40,93,231,41,147,127,112,220,23,106,31,1,67,33,41,187,43,148,211,213,3,31,128,101,161]

However the test signature does verify with

javascript noble-bls12-381

c++ chia-network/bls-signatures

c supranational/blst

Is there a chance that threshold_crypto will be compatible with these other bls12-381 libraries? Or am I missing something particular about the way those libraries differ from this one?

A few notes:

These libraries all seem to be using sha2_256 (see this discussion) but threshold_crypto is using sha3_256 (see utils.rs). I tried changing threshold_crypto to sha2 but that change alone did not lead to the test passing.

All these libraries have a DST parameter set to "BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_RO_NUL_" but I can't see any reference to this in threshold_crypto nor in any bls12-381 specs or docs, eg IETF and hackmd.io. So I'm definitely out of my depth and am hoping with this issue to understand whether threshold_crypto will aim to be compatible with the broader cryptocurrency bls12-381 implementations or not.

I realize this is more of a support request than a bug or feature request, but I feel there's some small potential that this may lead to a change in this library so I figured better to raise it and learn something than leave it and never understand it.
opened by iancoleman 3
Add reveal to commitment and bivarcommitment

These reveal functions are not necessary but I find them slightly helpful to debug, I figured if the polynomial and bivariate polynomial have it, I'll add it to the other structs for completeness sake. Leaving it to the maintainers if you want to land this.

opened by vihu 0