main
2 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Kgothatso Ngako
|
3c962b00cc |
frost_enrollment: fix the example's stale n and failure-path hygiene
The last of the review findings, plus the comment and structure fixes it
listed.
The example's repair run used the pre-enrollment participant count.
Two blocks earlier the example teaches that every participant must
update its record of n from 3 to 4 after an enrollment, and the
signing session duly uses N_PARTICIPANTS_AFTER. Then enroll() -- which
hard-coded N_PARTICIPANTS -- ran the repair at n = 3. It worked only
because the Lagrange math never involves n and every party in this
single-process demo passed the same stale value.
In a real post-enrollment repair it would not. n is bound into the
parameters hash, so helpers feeding their updated n = 4 into
shares_gen while the requester feeds n = 3 abort round 1.2 with no
visible cause. enroll() now takes n_participants as a parameter, the
repair passes N_PARTICIPANTS_AFTER, and both the function's contract
comment and the repair call site say why. The repaired share is still
byte-identical to the original, which is the point: n changes the
hash, not the arithmetic.
The example leaked secrets on its failure paths.
enroll() erased the delta and sigma buffers only on success; four
early returns left them live. sign_and_verify() returned from three
places without erasing already-generated secnonces. Both now route
every exit through a cleanup block. This example is otherwise more
careful about erasure than its siblings, so the asymmetry was exactly
what a reader copying it would carry into production -- on the fault
paths where hygiene matters most.
The double-wipe of session_secrand is gone with it: shares_gen and
nonce_gen both wipe the seed on every path, and doing it again read
as uncertainty about the contract. The comment now states the
contract instead. The fill_random failure path does erase, since
nothing else has touched the buffer there.
The example's mismatch message asserted a cause it cannot know.
It printed "Helper %u disagrees about the enrollment parameters" for
what may equally be a corrupted share, per the previous commit's
finding. It now says the helper "contributed a share this helper
cannot use", with a comment noting that share_agg does not
distinguish the two causes so neither can the message.
Comment and structure fixes, all noted in the review:
- The vector generator claimed case 4 was "the only case whose DERIVED
public share has odd Y". It is not -- cases 1, 2 and 4 are odd and
case 3 is even. The comment existed to justify a coverage choice and
misinformed; both parity comments now describe the set accurately and
say they document it rather than constrain it. Regenerating vectors.h
still reproduces it byte for byte.
- The secp256k1_frost_sort_ids declaration in frost/session.h no longer
duplicates the definition's doc comment, which was two copies to keep
in sync. It says what the function is for and points at the
definition for the contract.
- The t >= 2 rationale was stated in full in three places. The impl now
states the conclusion and names frost_enrollment.md as the single
place to edit if the policy moves.
- The ctime_tests comments read ambiguously ("the parameters hash is
public, the delta values are not" against a header calling deltas
secret), and computing direct_hash without asserting anything invited
a "forgotten assertion" reading. Both are now explicit.
- The example moves next to frost_example in Makefile.am rather than
after iceberg, matching the FROST-stack grouping used in
configure.ac, ci.sh, ci.yml and README.
- frost_enrollment.md now distinguishes what is unstable (the C API)
from what is frozen (the wire-visible encodings), which the two
statements together previously left easy to conflate.
Not fixed, deliberately, and now recorded where the tree can see it: the
plan called for a CHANGELOG.md entry. That file states in its first two
lines that it is upstream libsecp256k1's changelog and not this fork's,
and none of frost, chilldkg, iceberg or prefractal has an entry. Adding
the first one is a decision about all five modules, not this one. The
README link is the fork's actual convention for announcing a module and
is in place.
Verification: autotools builds warning-free and `make check` is 12/12
including the example; ctime_tests is clean under valgrind; `make dist`
carries all nine frost_enrollment files; CMake with examples builds
warning-free and ctest is 542/542; the example source is clean under
gcc -std=c89 -pedantic -Wall -Wextra; regenerating vectors.h reproduces
it byte for byte.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Kgothatso Ngako
|
303a7caeae |
frost_enrollment: add the test suite and the regression vectors
Fourth of six commits. Twelve tests replacing the Phase 2 smoke test, plus
a vector generator and the frozen vectors it produces.
The regression vectors are the one part of this worth being precise
about, because they are easy to over-claim. FROST enrollment has no BIP
and no published vectors, and the reference proof of concept draws its
randomness from secrets.randbits, which is not seedable -- so there is
nothing to cross-validate against. tools/test_vectors_frost_enrollment_generate.py
therefore re-implements the math independently in stdlib-only Python,
including the group arithmetic written from the secp256k1 parameters
rather than borrowed, and freezes the output. What that buys: the two tag
strings, the params hash serialization, the share-splitting derivation
and the identifier conventions are now pinned, and changing any of them
is a loud vector-breaking change. What it does not buy is evidence of
protocol correctness. The generator header comment and the generated
file both say so, as does frost_enrollment.md.
The vectors passed on the first run against the C code, which is worth
recording: two independent implementations agree byte for byte on the
params hash, every delta, every sigma, the derived public share and the
final share, across four cases (2-of-3 minimal, 2-of-3 oversized at
u = 3 > t = 2, a 3-of-5 repair with a deliberately UNSORTED helper set,
and a 4-of-6 enrollment), covering both threshold-key Y parities.
The algebraic invariants are what actually carry correctness:
- Reconstruction (PoC test_generate_frost_share): after a 2-of-3 group
enrolls id 3, every pair {i, 3} reconstructs the original threshold
secret, and so does the untouched pair {0, 1}.
- Signing (PoC test_sign): a real BIP340 signature from {2, 3} verifying
against the unchanged threshold public key, with every partial
signature individually verified, plus the n -> n+1 bookkeeping --
secp256k1_frost_threshold_info_validate must accept the public share
table extended with pubshare_derive's output at n+1.
- Repair: byte-for-byte equality with the lost share, and the repaired
participant keeps its old public share.
- Oversized helper set: u = 3 and u = 2 over the same key material
produce the same share and the same derived public share.
- Randomized: COUNT iterations over 2 <= t <= u <= n <= 7, half
enrollment and half repair, with EVERY HELPER GIVEN THE IDENTIFIER SET
IN ITS OWN SHUFFLED ORDER. The params hash must come out identical
while the delta buffers stay aligned per helper -- which is the whole
point of canonicalizing ids inside the hash and nowhere else. Each
iteration then checks every t-subset containing the new participant.
The negative tests are organized around what each gate is actually for:
- Fault injection flips a bit in one sigma. secshare_gen fails and wipes
its output; the same call with expected_pubshare = NULL SUCCEEDS and
returns a wrong share. That second assertion is the point -- it is the
evidence that the parameter is load-bearing rather than decorative.
Tampered public shares are caught earlier, by
secp256k1_frost_threshold_info_validate, so the test exercises the
recommended flow and not just the module.
- Parameter mismatch, four angles: (a) one helper runs round 1.1 for a
different target and every other helper's share_agg aborts naming it
by identifier; (b) a caller that IGNORES that abort and finishes round
1.2 anyway still cannot produce a usable share, because the
public-share check catches the inconsistent sum -- defence in depth,
not a test of the test's own control flow; (c) the helpers agree with
each other on new_id = 3 while the target expects 4, which round 1.2
cannot see and round 2's own recomputation does; (d) two groups with
identical (t, n, ids, new_id) get different hashes, and a hash from one
fails share_agg in the other.
- Own-slot semantics: filling the caller's own slot of
received_params_hashes32 with garbage changes nothing, because it is
never read -- but the same garbage in a slot that IS read still aborts.
That pair is what makes "recomputation, not string comparison"
testable rather than merely asserted.
- Invalid parameters, including both deliberate divergences: t = 1
refused, enrollment refused at n = 128 while repair at n = 128 is
accepted, n_ids > 128 returning 0 with the output zeroed in a
production build.
Three bugs found while writing these, all in the tests, all worth
naming:
- pubshare_derive takes public shares ALIGNED WITH ids, and the test
helper was handing it the participant-indexed table. Those coincide
exactly when the helper set is 0..u-1, which every test until the
repair case used, so the first non-contiguous helper set {0, 2} was
what exposed it. There is now one helper that does the gather, with a
comment saying which confusion it exists to prevent.
- The fault-injection test compared against r.new_secshare without ever
running round 2, and the mismatch test compared against
r.params_hashes[0] one line before round 1.1 filled it. Both were
reads of uninitialized memory that happened to pass; valgrind found
both.
The randomized test loops COUNT times so -i scales it, following the
iceberg module (tests_impl.h:1322) rather than prefractal's run-once
convention -- a fuzzing loop that ignores the iteration count is not
much of one.
Verification: all twelve tests pass at the default iteration count, at
-i=200 and at -i=2000; ./tests, ./noverify_tests and ./exhaustive_tests
exit 0 with all five FROST-stack modules enabled; the module runs clean
under valgrind (0 errors from 0 contexts); ctime_tests is clean under
valgrind; regenerating vectors.h reproduces it byte for byte.
One note for anyone running these locally: ctime_tests must not be run
against a CPPFLAGS='-DVERIFY' build. secp256k1_scalar_verify branches on
scalar values, which ctime_tests deliberately marks secret, so every
scalar operation in the library reports a finding -- 75997 of them, none
in this module. The CI matrix already pairs -DVERIFY with
CTIMETESTS: 'no' (.github/workflows/ci.yml:119, :596) for this reason.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|