{"type":"rich","version":"1.0","title":"Andrew Poelstra [ARCHIVE] wrote","author_name":"Andrew Poelstra [ARCHIVE] (npub1ae…z5t04)","author_url":"https://yabu.me/npub1ae27kq6z802dkqw4ey4dgdx493szm8dpmcm76d7vt0ma9gf6fj4svz5t04","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2023-07-26\n🗒️ 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.\n📝 Original message:\nOn Wed, Jul 26, 2023 at 12:09:41AM -0400, Erik Aronesty via bitcoin-dev wrote:\n\u003e personally, i think *any* time a public key is transmitted, it should come\n\u003e with a \"proof of secret key\".   it should be baked-in to low level\n\u003e protocols so that people don't accidentally create vulns.  alt discussion\n\u003e link:  https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406\n\u003e\n\nPOSK is not a panacea. For example, if you were to try to eliminate\nrogue key attacks in MuSig by using POSK rather than by rerandomizing\nthe keys, the last person to contribute a key could add a Taproot\ncommitment to their key, thereby modifying the final key to have a\nTaproot spending path that other participants don't know about. If they\ndid this, they'd have no problem producing a POSK since Taproot\ncommitments don't affect knowledge of the secret key.\n\nPOSKs are also logistically difficult to produce in many contexts. They\nessentially require an interactive challege-response (otherwise somebody\ncould just copy a POSK from some other source), meaning that all\nparticipants need to be online and have secret key access at key setup\ntime.\n\nIn some contexts maybe it's sufficient to have a static POSK. Aside from\nthe complexity of determining this, you then need a key serialization\nformat that includes the POSK. There are standard key formats for all\nwidely used EC keys but none have a facility for this. If you are trying\nto use already-published keys that do not have a POSK attached, you are\nout of luck.\n\nIf your protocol requires POSKs to be provably published, you also run\ninto difficulties because they don't make sense to embed on-chain (since\nblockchain validators don't care about them, and they're twice as big as\nthe keys themselves) so you need to establish some other publication\nmedium.\n\nIf you want to support nested multisignatures, you need to jointly\nproduce POSKs, which requires its own protocol complexity.\n\n\nThe MuSig and MuSig2 papers say essentially the same thing as the above;\nit's why we put so much effort into developing a scheme which was\nprovably secure in the plain public key model, which means that POSKs\nare superfluous and you don't need to deal with all these logistical\nhurdles.\n\n\n-- \nAndrew Poelstra\nDirector of Research, Blockstream\nEmail: apoelstra at wpsoftware.net\nWeb:   https://www.wpsoftware.net/andrew\n\nThe sun is always shining in space\n    -Justin Lewis-Webster\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 488 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230726/84e90df1/attachment.sig\u003e"}