Question about the compatibility of BIP 32

[Hoodie-Kang]

Hi

The Signer in example, which uses GG18, needs inputs including BKs and Shares.
Also the Sign of CGGMP needs inputs including shares, partial publickeys, bks, ssid, etc.

The master in bip32 outputs including BKs and shares so it can be used as an input of signer of GG18, but can't be an input of sign of CGGMP because it need so many other information.
Moreover the child in bip32 outputs shares without BKs, so it cannot be used as an input of any sign protocols.

So here is the question,
how can I use the outputs of bip32 to sign following CGGMP and GG18?
In detail, how can I make other necessary information including BKs to fit in the form of inputs of both Signs?

Thanks

[cychuang0924]

Hi Hoodie-Kang,

The BIP32's protocol only supports GG18.
The BKs of the child in BIP32 is inherited from the master in BIP32.
So, you have sufficient information to perform the sign of GG18.

About supporting CGGMP, it needs some other extra informations, this is a good feature.
If we have are available, we will implement it.
If you plan to do it yourself, you only generate the "ssid" in the master key generation of BIP32.
Here ssid := A's ssid xor B's ssid, which is the same formula in CGGMP.
Partial public is each party's share multiplying G (i.e. s_i*G).
Then you have the same outputs as DKG of CGGMP.
Next, you run the protocol of Refresh, then you can get Paillier's keys.
The child of BIP32 also uses the same information rid, Paillier's keys and BKs.

By the way, you can use the same pattern of ssid as CGGMP (ref. Figure5: interpret sid = (. . . , G, q, g, P )).

If you have any question, please let me know. Thanks.
By the way, we have a new version of BIP32, which is safer. But we only offers a POC.
ref: https://github.com/getamis/alice/tree/AddMoreCircuit/crypto/bip32

[Hoodie-Kang]

Hi cychuang,

Thank you for your reply and I think I can try to support CGGMP later.

The BKs of the child in BIP32 is inherited from the master in BIP32.

Does it mean the BKs of the child is same as the master's BKs, right?
So I put the BKs of the master , shares and pubkey of the result of child as inputs of the example Signer(supporting GG18),
but it printed below message.

INFO [01-30|10:02:47.680|message/msg_main.go:158] Change handler                           self=id-10002 msgType=1 fromId=id-10001 oldType=1 newType=2
WARN [01-30|10:02:47.704|signer/2_mta_handler.go:148] Unexpected public key                    self=id-10002 msgType=2 fromId=id-10001 exp="(x, y) =(60576254043948321120504991537465487157539913427948814188331348936263773203325, 88384804550390943077059257609818049928488659130969924780324346745171253123515)" got="(x, y) =(76236163921266583450921844951100146922464693447228813856081827815144078948682, 75535945727547807292640298370683079821929120364109987677535374452367689764615)"
WARN [01-30|10:02:47.704|message/msg_main.go:148]     Failed to go to next handler             self=id-10002 msgType=2 fromId=id-10001 err="unexpected public key"
INFO [01-30|10:02:47.704|message/msg_main.go:170]     State changed                            self=id-10002 old=Init new=Failed
ERROR[01-30|10:02:47.704|signer/service.go:102]       Signer failed                            old=Init new=Failed

Here are the inputs

share: "19314912191000541419872535925495115820644180555311607129040775338216522949679"
pubkey:
  x: "60576254043948321120504991537465487157539913427948814188331348936263773203325"
  "y": "88384804550390943077059257609818049928488659130969924780324346745171253123515"
bks:
  id-10001:
    x: "30037029816804127442838158252133331904516252338214806492403523861880278689988"
    rank: 0
  id-10002:
    x: "96578854112514857777221530994821975964494790946865720905808190272899481450178"
    rank: 0
msg: "child sign"

share: "66808307081423988966705308530915318122562404687876906911229251682513508041591"
pubkey:
  x: "60576254043948321120504991537465487157539913427948814188331348936263773203325"
  "y": "88384804550390943077059257609818049928488659130969924780324346745171253123515"
bks:
  id-10001:
    x: "30037029816804127442838158252133331904516252338214806492403523861880278689988"
    rank: 0
  id-10002:
    x: "96578854112514857777221530994821975964494790946865720905808190272899481450178"
    rank: 0
msg: "child sign"

However, the sign using master result works well.
So I think something goes wrong, but I don't have any idea :(
How can I make it work?

Thank you,

Hoodie

[cychuang0924]

Hi Hoodie-Kang, The reason is the outputs of child key derivation, which is not BK's form. I fix it here #234 It needs to be reviewed by my colleague. Thanks for your mention. Sincerely, Chih Yun Hoodie-Kang ***@***.***> 於 2023年1月30日 週一 上午9:35寫道：

…

Hi cychuang, The BKs of the child in BIP32 is inherited from the master in BIP32. Does it mean the BKs of the child is same as the master's BKs, right? So I put the BKs of the master , shares and pubkey of the result of child as inputs of the example Signer(supporting GG18), but it printed below message. INFO [01-30|10:02:47.680|message/msg_main.go:158] Change handler self=id-10002 msgType=1 fromId=id-10001 oldType=1 newType=2 WARN [01-30|10:02:47.704|signer/2_mta_handler.go:148] Unexpected public key self=id-10002 msgType=2 fromId=id-10001 exp="(x, y) =(60576254043948321120504991537465487157539913427948814188331348936263773203325, 88384804550390943077059257609818049928488659130969924780324346745171253123515)" got="(x, y) =(76236163921266583450921844951100146922464693447228813856081827815144078948682, 75535945727547807292640298370683079821929120364109987677535374452367689764615)" WARN [01-30|10:02:47.704|message/msg_main.go:148] Failed to go to next handler self=id-10002 msgType=2 fromId=id-10001 err="unexpected public key" INFO [01-30|10:02:47.704|message/msg_main.go:170] State changed self=id-10002 old=Init new=Failed ERROR[01-30|10:02:47.704|signer/service.go:102] Signer failed old=Init new=Failed Here are the inputs share: "19314912191000541419872535925495115820644180555311607129040775338216522949679" pubkey: x: "60576254043948321120504991537465487157539913427948814188331348936263773203325" "y": "88384804550390943077059257609818049928488659130969924780324346745171253123515" bks: id-10001: x: "30037029816804127442838158252133331904516252338214806492403523861880278689988" rank: 0 id-10002: x: "96578854112514857777221530994821975964494790946865720905808190272899481450178" rank: 0 msg: "child sign" share: "66808307081423988966705308530915318122562404687876906911229251682513508041591" pubkey: x: "60576254043948321120504991537465487157539913427948814188331348936263773203325" "y": "88384804550390943077059257609818049928488659130969924780324346745171253123515" bks: id-10001: x: "30037029816804127442838158252133331904516252338214806492403523861880278689988" rank: 0 id-10002: x: "96578854112514857777221530994821975964494790946865720905808190272899481450178" rank: 0 However, the sign using master result works well. So I think something goes wrong, but I don't have any idea :( How can I make it work? Thank you, Hoodie — Reply to this email directly, view it on GitHub <#233 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK4AJBBPJM25BNXWKQLGVX3WU4LHDANCNFSM6AAAAAAUF7TUUE> . You are receiving this because you were assigned.Message ID: ***@***.***>

[Hoodie-Kang]

Hi Chih Yun,

After it merged, I'll try it !

Thank you,

Hoodie

[cychuang0924]

Hi Hoodie-Kang,

It has be merged! Thanks!

[Hoodie-Kang]

Hi Chih Yun,

I made it! now I can sign using GG18 and child results.

About CGGMP sign, I'll try it later and leave another issue if I get some problems.

Thank you so much!!

Hoodie

[Hoodie-Kang]

Hi, Chih Yun.

Following your comment, I'm trying to make those information.

It's not difficult to make partial public key, because each party's share multiplying G is already included in the code.

But about the ssid, in the DKG of CGGMP, I used cggmp.ComputeSSID(sid, id, rid) to calculate it.

In the code, rid := XOR of all ridis and that means one should know the other peer's ridi.

And here is the problem.

The ridi(randomly generated 32 bytes) of each party isn't included in bip32, so I cannot handle them.

To make them know each other's ridi, should I modify the message related codes ? (ex. message.go, message.pb.go )

If then, how can I do that?
If not, can you tell me another way to make rid ?

Thanks,

Hoodie

[cychuang0924]

Hi Hoodie-Kang,
I will pull a PR and it can help you. Thanks for your information.

[cychuang0924]

Hi Hoodie-Kang,
The PR is here. It maybe help you!
Thanks a lot.

By the way, we have a new version 2 party BIP32 algorithm. The paper has been submitted.

[Hoodie-Kang]

Hi Chih Yun!

I'll check the PR :) Thank you so much

By the way, does the new version of bip32 support above features of CGGMP such as ssid, rid, bks, etc.?

[Hoodie-Kang]

Hi Chih Yun,

Thanks to your PR, I can sign with 2 party BIP32 Master outputs using CGGMP.
So I'm going to modify the child package codes as you did in the master package to make the child sign works!

By the way,

alice/crypto/tss/ecdsa/cggmp/utils.go

Line 27 in c745df1

copy(result, result)

I think it would be better if it changes to
copy(result, sid)

and also

alice/crypto/tss/ecdsa/cggmp/utils.go

Line 38 in c745df1

copy(result, result)

to copy(result, ssid)

• edit) Ooh but after I modified the func ComputeZKSsid(), the refresh failed. The error messages are here.

WARN [03-16|14:25:22.369|refresh/round_2.go:105]  Failed to build round2 data              self=id-10001 msgType=1 fromId=id-10002 err="the verification is failure"
WARN [03-16|14:25:22.369|message/msg_main.go:137] Failed to save message                   self=id-10001 msgType=1 fromId=id-10002 err="the verification is failure"

Please check it( and also the error )

Thank you,

Hoodie Kang

[cychuang0924]

Hi Chih Yun!

I'll check the PR :) Thank you so much

By the way, does the new version of bip32 support above features of CGGMP such as ssid, rid, bks, etc.?

The main improvement of our research is the new protocol is more secure. The version of 2 party bip32 only against semi-honest attacker. The new version can against malicious adversary.