This document analyses how SignersContext flows through the BIP-445 FROST signing
protocol, whether the implementation matches the stated design intent, what attacks a
malicious coordinator can mount by equivocating on signers_ctx, how RFC 9591
compares, and what improved designs exist.
| #!/bin/bash | |
| set -e | |
| REPO_URL="https://github.com/siv2r/bip-frost-signing.git" | |
| BRANCH="master" | |
| TARGET="bip-0445" | |
| git fetch "$REPO_URL" "$BRANCH" | |
| REF="FETCH_HEAD" |
This is an adaptation of the MuSig2's partial signature forgery for the FROST protocol, described by Adam Gibson. You can find the original write-up here.
In FROST signing, a malicious participant could forge the partial signature (i.e., PartialSigVerify on it will succeed) of another participant without knowing their secret share, but only under the following conditions:
- The victim does not participate in the signing.
- The malicious participant impersonates the victim while also participating with their original share, making it appear as if two different participants are involved in the signing.
As a consequence, the malicious signing participant will be unable to create a valid partial signature for their original secret share.
Key Setup: Let's consider a 3-of-5 FROST policy among a group of participants
| #!/usr/bin/env python3 | |
| import subprocess | |
| import os | |
| import sys | |
| import time | |
| from openpyxl import Workbook | |
| from openpyxl.styles import Font, Alignment | |
| def run_command(cmd, log_file=None): |
| #!/usr/bin/env python3 | |
| import subprocess | |
| import os | |
| import sys | |
| import time | |
| from openpyxl import Workbook | |
| from openpyxl.styles import Font, Alignment | |
| def run_command(cmd, log_file=None): |
This document provides specific instructions for your operation within this codebase. Please adhere to these guidelines strictly.
Before writing any code, you must create an implementation plan and get it approved.
- Create
PLAN.md: Write your step-by-step plan to a PLAN.md file in the root directory. If there already exists aPLAN.md, overwrite it. - Wait for Approval: Do not start implementing until the plan has been reviewed and approved.- Outline Different Approaches: If there are multiple, fundamentally different implementation strategies, present them in the plan. For each, list the pros and cons. Do not include minor variations.
## Context
<what we’re changing and why>
| /* this is the main function of test.c of libsecp */ | |
| /* you can find my complete code here: https://github.com/siv2r/secp256k1/commit/b3a1437f715dad7478515a55728ecb12aaf4dad1 */ | |
| #include "modules/debug/main_impl.h" | |
| int main() { | |
| unsigned char msg[40] = "Hey, this message is going to be hashed"; | |
| unsigned char out[32]; | |
| secp256k1_sha256 hash; |