Pitfall Category
When a protocol aborts, whether for benign or malicious reasons, the implementation must ensure that the failures are handled securely. What securely means is protocol-specific and may vary from: simply rerunning the protocol, removing a corrupted party, restarting other parts of the protocol, discarding some correlated randomness, or never running the protocol with the same input again.
Pitfall
What can go wrong. OT-extension protocols (Ishai et al., 2003) are made secure against a malicious receiver by a consistency check (Keller-Orsini-Scholl, 2015), in which the sender validates the receiver’s queries against its own secret choices. It is no silver bullet: the check is computed from those choices, so whether it passes or fails leaks one bit of them, letting a cheating receiver force a selective abort to learn a bit of the secret. A single failure may not leak much, and the protocol stays secure as long as a failed check is treated as terminal and the base OT discarded. But if the implementation keeps the setup alive after a failure, for example behind an opaque error the sender simply retries, the receiver reconstructs the secret bit by bit across many calls.
Security implication. An attacker selectively forces an abort to learn one bit of the sender’s secret choices, then repeats the procedure over different executions that reuse the same base OTs. Eventually it learns every secret bit, breaking security. In a threshold signature scheme this lets an attacker recover the signing key, and with more parties the attacker repeats the process against each one.
How to avoid. Exclude the corrupted party, discard the OTs on which the adversary gained leakage, and resample fresh base OTs before continuing. In case of parallel OT-extension instances, replicate this across all instances. The correlation check of KOS 2015 keeps the per-run leakage negligible but does not by itself prevent selective-abort attacks, so the no-reuse discipline above is what actually stops full key recovery.
A closely related selective-abort attack also appears outside OT extension, in Paillier-based two-party ECDSA such as the Lindell17 abort-handling bug, where the abort signal leaks one bit of the honest party’s share per signing attempt. The mechanism is different (no OT is involved), but the same lesson holds: a failed check must be terminal, never a silent retry.
Trail of Bits disclosed a selective-abort vulnerability in an OT-based threshold-ECDSA implementation in the Doerner et al. (DKLS) line. Whether the OT-extension consistency check aborts is itself a function of the sender’s secret choice bits, so a cheating receiver learns “a few bits” per run from the pass/abort signal; because the base OTs are reused, repeating it recovers every secret bit, and in a two-party setting the nonce and the ECDSA signing key.
The fix is to “throw away the setup for a participant that has attempted to cheat during the OT extension protocol.”