Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Threshold signatures require that no single participant holds the private key. The signer's shares are equally divided among everyone. In reality, this means serious validation on proofs, invariants, and abort-data handling. In GG18/GG20 threshold ECDSA, encryption is performed via multiplication-to-add schemes. Namely, one party encrypts its value, and another party homomorphically combines the ciphertext with their own to get the real value.

The design only works if the participants' Paillier keys are well-formed and accompanied by a valid zero-knowledge proof. During DKG, each party publishes its public keys and proof parameters, which are persisted and reused in later signing sessions. The malicious Paillier modulus should be the product of two large primes. If a malicious participant can get an honest peer to persist an attacker-shaped N with a known factorization structure, the homomorphic MtA response no longer behaves like a one-way operation! Meaning, key material can be recovered.

The Thorchain tss-lib version does not protect against bad N values in the keygen. The BNB library adds MOD and FAC proofs to key generation in order to verify them before the key material is accepted. These public keys are saved for future usage. This is enough to set up the attack, but not yet enough to recover key material.

During the real signing process, Alice cannot be Bob's Paillier mask but still wants to know if their portion is valid or not. So, by observing when the TSS signing ceremony fails, an attacker can infer the hidden residues. An attacker can sign information corresponding to the user's key and get failures that reveal it. These are yes-or-no questions. But, over time, this works very well. They don't claim they could have recovered the key because of combinational issues with the number of parties involved.

They also found some input validation issues with the library that were independent from the findings above. The exploitation of the bad N value was known at the time of the attack, though. At the end of the day, Thorchain lost $11M from this. It appears that the attacker compromised enough key shares of a vault and then waited for enough money to be at risk before triggering.

A few takeaways for me:

• Cryptography bugs should always be fixed, even if they feel small. Lots of small things compound.
• Libraries need to be upgraded. It seems that because nobody likes touching cryptography, this tends to happen more with these types of libraries.