public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: AdamISZ <AdamISZ@protonmail.com>
To: moonsettler <moonsettler@protonmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Blinded 2-party Musig2
Date: Thu, 27 Jul 2023 05:51:14 +0000	[thread overview]
Message-ID: <LBcOp2w_wV3Q2X_tP94SfaYbqxiEwKP8hPUbgT_b1dQeHT3hPw6y6o3kFYep9wgqsjIWj1g8jUHzaZFdYTgL7eLwO22-70b7SB0dO7Ml7Zk=@protonmail.com> (raw)
In-Reply-To: <NUH-svf2Bz96uxe5zYehmG8sQ7uLc3GwlFSBrN3-Sdfroj0iL4C2bTV2vxqAsFM9yHr7fi0C_74ThNPGKerQAuDlW2b0ljwXud_uiUDQ8RA=@protonmail.com>

A reasonable attack scenario might be: attacker gains control of client machine and its privkey, wants to extract money. It first operates passively, waiting for user to do 2FA on a normal transaction, only modifying the nonce used in order to achieve its goal. Then, after that 1 transaction goes through, it gets the server privkey as above, and so 2FA is no longer needed to steal the remainder of the money. Or did I miss some part of the setup?


Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, July 26th, 2023 at 13:28, moonsettler via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> 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 AdamISZ@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


  reply	other threads:[~2023-07-27  5:51 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-24  7:46 [bitcoin-dev] Blinded 2-party Musig2 Tom Trevethan
2023-07-24 10:50 ` ZmnSCPxj
2023-07-24 14:25   ` Erik Aronesty
2023-07-24 16:08     ` Tom Trevethan
2023-07-24 15:57   ` Tom Trevethan
2023-07-24 14:12 ` Jonas Nick
2023-07-24 14:40   ` Erik Aronesty
2023-07-24 15:40     ` Jonas Nick
2023-07-24 16:51   ` AdamISZ
2023-07-25 14:12     ` Erik Aronesty
2023-07-25 16:05       ` Tom Trevethan
2023-07-26  4:09         ` Erik Aronesty
2023-07-26 17:40           ` Andrew Poelstra
2023-07-26 19:59           ` Jonas Nick
2023-07-26 20:35             ` Tom Trevethan
2023-07-26 22:06               ` Erik Aronesty
2023-07-27  2:54                 ` Lloyd Fournier
2023-07-27  8:07               ` Jonas Nick
     [not found]                 ` <CAJvkSsfa8rzbwXiatZBpwQ6d4d94yLQifK8gyq3k-rq_1SH4OQ@mail.gmail.com>
2023-07-27 13:25                   ` [bitcoin-dev] Fwd: " Tom Trevethan
2023-08-07  0:55                     ` [bitcoin-dev] " Tom Trevethan
2023-08-08 17:44                       ` moonsettler
2023-08-09 15:14                         ` Tom Trevethan
2023-08-10  3:30                           ` Lloyd Fournier
2023-08-10 11:59                             ` Tom Trevethan
2023-08-14  6:31                               ` Lloyd Fournier
2023-08-30 10:52                       ` Tom Trevethan
2023-07-24 15:39 ` Jonas Nick
2023-07-24 16:22   ` Tom Trevethan
2023-07-26  9:44   ` moonsettler
2023-07-26 14:59     ` Jonas Nick
2023-07-26 19:19     ` AdamISZ
2023-07-26 19:28       ` moonsettler
2023-07-27  5:51         ` AdamISZ [this message]
     [not found] <mailman.125690.1690381971.956.bitcoin-dev@lists.linuxfoundation.org>
2023-07-26 16:32 ` Tom Trevethan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='LBcOp2w_wV3Q2X_tP94SfaYbqxiEwKP8hPUbgT_b1dQeHT3hPw6y6o3kFYep9wgqsjIWj1g8jUHzaZFdYTgL7eLwO22-70b7SB0dO7Ml7Zk=@protonmail.com' \
    --to=adamisz@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=moonsettler@protonmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox