KeyShares::from_backup_format (the Shamir backup share reader, public since
0.2.0, the crate's first release) accepted a share whose x coordinate is 0,
and KeyShares::recover_private_key interpolates the shares at x = 0 to
recover the key. At an x of 0 the interpolation answers that share's y value
alone, so an attacker who supplies one share in that form — with the share's
integrity tag ground to match the honest set's — chooses the recovered key
outright. The non-canonical zero x = p works the same way, and a repeated x
past the threshold window also passed.
An application that recovers a Shamir backup from shares it did not produce — a custodian's medium, a share pasted by hand, a set restored from another writer — could be handed the attacker's key as the recovered one. A set the crate's own writer produces never carries such a share; the door is the reader.
0.8.7 refuses such a set before interpolating (the 0.9 line's next prerelease
carries the same refusal). Where upgrading is not possible, before recovering
split each share on . into four fields, base58-decode the x field, and
refuse the set if it decodes to zero (the one-character field 1, or a value
at or above the field prime) or if two shares carry the same x.
{
"license": "CC0-1.0"
}