Yes, thank you! There I assume if someone has your private key, and can satisfy the 2FA, he will just steal your coins, and not bother with extracting the co-signers key that is specific to you. I can see, how this assumption is not useful generally.
BR, moonsettler Sent with Proton Mail secure email. ------- Original Message ------- On Wednesday, July 26th, 2023 at 9:19 PM, AdamISZ <adam...@protonmail.com> wrote: > It's an interesting idea for a protocol. If I get it right, your basic idea > here is to kind of "shoehorn" in a 2FA authentication, and that the > blind-signing server has no other function than to check the 2FA? > > This makes it different from most uses of blind signing, where counting the > number of signatures matters (hence 'one more forgery etc). Here, you are > just saying "I'll sign whatever the heck you like, as long as you're > authorized with this 2FA procedure". > > Going to ignore the details of practically what that means - though I'm sure > that's where most of the discussion would end up - but just looking at your > protocol in the gist: > > It seems you're not checking K values against attacks, so for example this > would allow someone to extract the server's key from one signing: > > 1 Alice, after receiving K2, sets K1 = K1' - K2, where the secret key of K1' > is k1'. > 2 Chooses b as normal, sends e' as normal. > 3 Receiving s2, calculate s = s1 + s2 as normal. > > So since s = k + ex = (k' + bx) + ex = k' + e'x, and you know s, k' and e', > you can derive x. Then x2 = x - x1. > > (Gist I'm referring to: > https://gist.github.com/moonsettler/05f5948291ba8dba63a3985b786233bb) > > > > > Sent with Proton Mail secure email. > > > ------- Original Message ------- > On Wednesday, July 26th, 2023 at 03:44, moonsettler via bitcoin-dev > bitcoin-dev@lists.linuxfoundation.org wrote: > > > > > Hi All, > > > > I believe it's fairly simple to solve the blinding (sorry for the bastard > > notation!): > > > > Signing: > > > > X = X1 + X2 > > K1 = k1G > > K2 = k2G > > > > R = K1 + K2 + bX > > e = hash(R||X||m) > > > > e' = e + b > > s = (k1 + e'*x1) + (k2 + e'*x2) > > s = (k1 + k2 + b(x1 + x2)) + e(x1 + x2) > > > > sG = (K1 + K2 + bX) + eX > > sG = R + eX > > > > Verification: > > > > Rv = sG - eX > > ev = hash(R||X||m) > > e ?= ev > > > > https://gist.github.com/moonsettler/05f5948291ba8dba63a3985b786233bb > > > > Been trying to get a review on this for a while, please let me know if I > > got it wrong! > > > > BR, > > moonsettler > > > > ------- Original Message ------- > > On Monday, July 24th, 2023 at 5:39 PM, Jonas Nick via bitcoin-dev > > bitcoin-dev@lists.linuxfoundation.org wrote: > > > > > > Party 1 never learns the final value of (R,s1+s2) or m. > > > > > > Actually, it seems like a blinding step is missing. Assume the server > > > (party 1) > > > received some c during the signature protocol. Can't the server scan the > > > blockchain for signatures, compute corresponding hashes c' = H(R||X||m) > > > as in > > > signature verification and then check c == c'? If true, then the server > > > has the > > > preimage for the c received from the client, including m. > > > _______________________________________________ > > > bitcoin-dev mailing list > > > bitcoin-dev@lists.linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
