#schnorr-signature #cryptography #randomized #threshold-cryptography

frost-rerandomized

Types and traits to support implementing a re-randomized variant of Flexible Round-Optimized Schnorr Threshold signature schemes (FROST)

14 releases (4 stable)

new 3.0.0-rc.0 Jan 28, 2026
2.2.0 Aug 27, 2025
2.1.0 Jan 15, 2025
2.0.0 Oct 23, 2024
0.1.0 Mar 9, 2023

#3 in #randomized

Download history 1736/week @ 2025-10-11 1946/week @ 2025-10-18 1667/week @ 2025-10-25 2123/week @ 2025-11-01 1896/week @ 2025-11-08 2189/week @ 2025-11-15 2133/week @ 2025-11-22 2832/week @ 2025-11-29 1894/week @ 2025-12-06 2057/week @ 2025-12-13 1515/week @ 2025-12-20 1563/week @ 2025-12-27 2338/week @ 2026-01-03 3108/week @ 2026-01-10 3667/week @ 2026-01-17 3578/week @ 2026-01-24

12,948 downloads per month
Used in 44 crates (11 directly)

MIT/Apache

375KB
7K SLoC

FROST implementation supporting re-randomizable keys.

To sign with re-randomized FROST:

  • Do Round 1 the same way as regular FROST;
  • The Coordinator should call [RandomizedParams::new_from_commitments()] and send the generate randomizer seed (the second returned value) to all participants, using a confidential channel, along with the regular frost::SigningPackage;
  • Each participant should regenerate the RandomizerParams by calling [RandomizedParams::regenerate_from_seed_and_commitments()], which they should pass to [sign_with_randomizer_seed()] and send the resulting frost::round2::SignatureShare back to the Coordinator;
  • The Coordinator should then call aggregate.

FROST (Flexible Round-Optimised Schnorr Threshold signatures) Rerandomized

A ciphersuite-generic implementation of Re-Randomized FROST, which allows creating signatures using FROST under re-randomized keys.

Usage

frost-rerandomized is similar to frost-core, but provides different sign() and aggregate() functions adding support for re-randomized signatures.

Currently, the main ciphersuite crates do not re-expose the rerandomization functions; if you want to use this functionality, you will need to use this crate parametrized with the chosen ciphersuite. The exceptions are the Zcash ciphersuites in reddsa which do expose the randomized functionality.

Example

See ciphersuite-specific modules, e.g. the ones in reddsa.

Dependencies

~1–6.5MB
~122K SLoC