rich1.0Andrew Poelstra [ARCHIVE] (npub1ae…z5t04)https://yabu.me/npub1ae27kq6z802dkqw4ey4dgdx493szm8dpmcm76d7vt0ma9gf6fj4svz5t04njumphttps://yabu.me📅 Original date posted:2023-07-26 🗒️ Summary of this message: POSK (proof of secret key) is not a perfect solution for preventing rogue key attacks and has logistical difficulties in implementation. 📝 Original message: On Wed, Jul 26, 2023 at 12:09:41AM -0400, Erik Aronesty via bitcoin-dev wrote: > personally, i think *any* time a public key is transmitted, it should come > with a "proof of secret key". it should be baked-in to low level > protocols so that people don't accidentally create vulns. alt discussion > link: https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406 > POSK is not a panacea. For example, if you were to try to eliminate rogue key attacks in MuSig by using POSK rather than by rerandomizing the keys, the last person to contribute a key could add a Taproot commitment to their key, thereby modifying the final key to have a Taproot spending path that other participants don't know about. If they did this, they'd have no problem producing a POSK since Taproot commitments don't affect knowledge of the secret key. POSKs are also logistically difficult to produce in many contexts. They essentially require an interactive challege-response (otherwise somebody could just copy a POSK from some other source), meaning that all participants need to be online and have secret key access at key setup time. In some contexts maybe it's sufficient to have a static POSK. Aside from the complexity of determining this, you then need a key serialization format that includes the POSK. There are standard key formats for all widely used EC keys but none have a facility for this. If you are trying to use already-published keys that do not have a POSK attached, you are out of luck. If your protocol requires POSKs to be provably published, you also run into difficulties because they don't make sense to embed on-chain (since blockchain validators don't care about them, and they're twice as big as the keys themselves) so you need to establish some other publication medium. If you want to support nested multisignatures, you need to jointly produce POSKs, which requires its own protocol complexity. The MuSig and MuSig2 papers say essentially the same thing as the above; it's why we put so much effort into developing a scheme which was provably secure in the plain public key model, which means that POSKs are superfluous and you don't need to deal with all these logistical hurdles. -- Andrew Poelstra Director of Research, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230726/84e90df1/attachment.sig>