search

bnb-chain / tss-lib

Threshold Signature Scheme, for ECDSA and EDDSA
MIT License
759 stars 261 forks source link

EdDSA signing is incorrect if the message is leading with 0x00 #264

Open i-xiaov opened 10 months ago

i-xiaov commented 10 months ago

The message is stored in LocalParty as a bit.Int and then passed into EdDSA signing process. In round_3, it was used as bytes:

h := sha512.New()
h.Reset()
h.Write(encodedR[:])
h.Write(encodedPubKey[:])
h.Write(round.temp.m.Bytes())

The problem is that the returned byte slice from big.Int.Bytes() represents the minimal-length binary form of the integer and does not include any leading zero bytes. So, if the message is leading with 0x00 the result SignatureData will be incorrect.

Using big.Int.FillBytes() or storing message as raw byte slice should be better?

zargarzadehm commented 7 months ago

I have the same issue in eddsa signing:

signData, _ := new(big.Int).SetString("00f163ee51bcaeff9cdff5e0e3c1a646abd19885fffbab0b3b4236e0cf95c9f5", 16)
localTssData.Params = tss.NewParameters(tss.Edwards(), ctx, localPartyId, len(localTssData.PartyIds), threshold)
localTssData.Party = eddsaSigning.NewLocalParty(signData, localTssData.Params, h.savedData, outCh, endCh)

and response for endChannel is something like this:

SignatureData.M -> "f163ee51bcaeff9cdff5e0e3c1a646abd19885fffbab0b3b4236e0cf95c9f5"

so, the signature is not valid because of this problem!

I created a PR for this https://github.com/bnb-chain/tss-lib/pull/284