topos-protocol / ice-frost Goto Github PK

View Code? Open in Web Editor NEW

17.0 6.0 6.0 364 KB

A modular Rust implementation of the static version of the ICE-FROST signature scheme.

Home Page: https://eprint.iacr.org/2021/1658

License: Apache License 2.0

Rust 100.00%

cryptography digital-signature frost rust threshold-cryptography threshold-signature

ice-frost's Introduction

ICE-FROST

A modular Rust implementation of ICE-FROST: Identifiable Cheating Entity Flexible Round-Optimised Schnorr Threshold signatures supporting static group keys.

Usage

Please see the documentation for usage examples.

Modular Backend

This library has a modular backend supporting

arbitrary curves defined with the arkworks library suite;
arbitrary hash functions for the internal random oracles of the ICE-FROST ciphersuite;
an arbitrary AEAD for the secret shares encryption part of the DKG / Key resharing phase.

Note however that two parameters are not modular, at least in the current version:

the hash function targeted security parameter: this crate assumes 128 bits of collision security for the ciphersuite's internal hashers. One MUST provide a hasher with at least 128 bits of collision security when instantiating an ICE-FROST ciphersuite.
the secret share encryption mechanism: this part of the distributed key generation currently relies on the ciphersuite's AEAD but with a fixed HKDF instantiated from SHA-256.

This library also provides by default an example instantiation over the Secp256k1 curve with SHA-256, to be used in tests and benchmarks.

Note on `no_std` usage

This crate can be made no_std compliant, by relying on the alloc crate instead.

Features

std: activated by-default, allowing use of the Rust standard library
asm: deactivated by-default, allowing x86-64 assembly optimization for finite field operations. This feature also activates the std one.

WARNING

This codebase is under development and is at an academic proof-of-concept prototype level. In particular, this implementation has not received careful code review yet, and hence is NOT ready for production use.

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.

ice-frost's People

Contributors

Stargazers

Watchers

Forkers

nashtare shuoer86 22388o aminil dvdplm xcshuan

ice-frost's Issues

Remove unnecessary risks of panic

There are a few unwrap here and there that would deserve cleaner handling through a FrostResult instead.

Add support for batch verification

Add support for submitting prehashed messages

Is your proposal related to a problem?

Yes, the SignatureAggregator takes the original message and handles the hashing at the finalization step.

Describe the solution you'd like

It should be possible to instantiate it if the message has been pre-hashed.

Refactor key generation module testing suite

Similarly to what is done on the signature module, a lot of code duplication could be alleviated across unit tests with some refactoring, that would ease reviewing / maintaining these.

Prepare for crates.io release

Checks to do before official release:

Add additional sanity checks on the whole DKG process

Related to the item mentioned in #28, we would probably need additional sanity checks on the resharing phase.
There also needs to be a clear line drawn between what the protocol enforces, and what is expected to be done outside of this library (for instance the use of authenticated broadcast mechanism is explicitly required externally).

resharing from a single party (part of #29)
resharing to a single party (part of #29)
resharing from a non-ICE-FROST single individual (done in #36)
...

[CI] Fix code coverage display in README

The README's coverage icon currently displays "unknown" for the code coverage report, although everything seems to be running fine on the CI, see below:

It's a relatively low-priority issue though.

Proposal for serialization support

We currently support two types of encoding:

CanonicalSerialize / CanonicalDeserialize -> those are easily derived as all our wrapper types rely on arkworks traits that do implement those;
custom to_bytes / from_bytes inherited from the old codebase, which are simply calling CanonicalSerialize / CanonicalDeserialize methods internally.

This issue concerns two points related to serialization:

addressing the code duplication induced by all the custom to_bytes / from_bytes methods through new traits, like Encode/ToBytes and Decode/FromBytes (names are arbitrary and not carved in marble), which would be supertraits of CanonicalSerialize and CanonicalDeserialize respectively.
We may want to additionally support serde behind some feature flag for all our public types. This could actually remove the need for a custom serialization mechanism, or be complementary to it (for users who would like to rely on as few extra dependencies as possible and stick to the custom Encode/Decode).

Any thoughts?

Add additional test coverage for scenarios with malicious activity

We're lacking of coverage on the DKG / resharing side with respect to the different entry doors for malicious participants.
We also need some test case of DKG -> resharing -> resharing, which doesn't exist at the moment.