Update to wsts 12

[xoloki]

Description

Update the wsts dependency to 12.0.0

Closes #1162, closes #1166, and closes #1167

Changes

Testing Information

Checklist:

• I have performed a self-review of my code
• My changes generate no new warnings
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[matteojug]

sBTC side:

• We can remove SignerStateWrapper and PartyStateWrapper now that they implement eq (in https://github.com/stacks-network/sbtc/blob/main/signer/src/proto/convert.rs#L1802-L1834) and move the tests in convert_protobuf_type3 to convert_protobuf_type2

WSTS side:

1. in check_public_shares: maybe switch the order of the checks (first len, then verify)? I'm not sure if verify does something bad if the poly len is wrong
2. make_shared_secret_from_key (calling ansi_x963_derive_key) generates a different key now because of the counter and the order of hash updates, is it fine (wrt backward compatibility with data already generated)? Does this makes this a breaking protocol change (ie, if signers are running different versions can they still interact as expected)?
3. maybe nit: fn gen<RNG: RngCore + CryptoRng>(rng: &mut RNG) -> Scalar: as this don’t use a secret, doing the generation as in 4.1 (see comment) doesn’t seem to give any better guarantees: if the rng is a bad one, this will still generate bad nonces

[xoloki]

@matteojug:

• We can remove SignerStateWrapper and PartyStateWrapper now that they implement eq (in https://github.com/stacks-network/sbtc/blob/main/signer/src/proto/convert.rs#L1802-L1834) and move the tests in convert_protobuf_type3 to convert_protobuf_type2

Will do.

1. in check_public_shares: maybe switch the order of the checks (first len, then verify)? I'm not sure if verify does something bad if the poly len is wrong

verify only uses the first coefficient of the polynomial, so it won't do anything bad if the length is wrong.

2. make_shared_secret_from_key (calling ansi_x963_derive_key) generates a different key now because of the counter and the order of hash updates, is it fine (wrt backward compatibility with data already generated)? Does this makes this a breaking protocol change (ie, if signers are running different versions can they still interact as expected)?

Good point; this would definitely break if one of the signers was using code with a different key derivation. And a signer using the new key derivation would not be able to read old DkgPrivateShares, though we aren't persisting them past DKG so that shouldn't be an issue.

3. maybe nit: fn gen<RNG: RngCore + CryptoRng>(rng: &mut RNG) -> Scalar: as this don’t use a secret, doing the generation as in 4.1 (see comment) doesn’t seem to give any better guarantees: if the rng is a bad one, this will still generate bad nonces

Interesting, I read this as basically saying to hash two 32-bytes random values rather than just using a single 32 byte value directly. But yeah if the RNG is predictable then you really aren't gaining much.

Looking over the rest of the doc, it looks like "secret key" is used mostly to mean the key shares, but in some places it isn't really defined at all. We could use the key shares, or pass in the ECDSA key. What do you think?

[matteojug]

Good point; this would definitely break if one of the signers was using code with a different key derivation. And a signer using the new key derivation would not be able to read old DkgPrivateShares, though we aren't persisting them past DKG so that shouldn't be an issue.

Just to double check: we store (encrypted) the whole SignerState, that contains the signer PartyState and has some suspecting private_keys; this is not related to what you're saying, correct?

---

Looking over the rest of the doc, it looks like "secret key" is used mostly to mean the key shares, but in some places it isn't really defined at all. We could use the key shares, or pass in the ECDSA key. What do you think?

The bit that got me thinking was:

To hedge against a bad random number generator (RNG) that outputs
predictable values, nonces are generated with the nonce_generate
function by combining fresh randomness with the secret key as input
to a domain-separated hash function built from the ciphersuite hash
function H.

So if we don't have something secret, the security of it should be the same as using directly the RNG without the extra manipulation.

Given how it is used in nonce_generate, I think it should be fine using either (since it's later hashed).

[xoloki]

Just to double check: we store (encrypted) the whole SignerState, that contains the signer PartyState and has some suspecting private_keys; this is not related to what you're saying, correct?

DkgPrivateShares are not stored in those state objects. The polynomials and key shares (which are called private keys) are.

So if we don't have something secret, the security of it should be the same as using directly the RNG without the extra manipulation.

Given how it is used in nonce_generate, I think it should be fine using either (since it's later hashed).

Agreed.