search

coinbase / mesh-specifications

Specification files for the Mesh Blockchain Standard
Apache License 2.0
327 stars 93 forks source link

feat/add-ecschnorr-support-for-zilliqa #38

Closed teye closed 4 years ago

teye commented 4 years ago

Introduction

This pr adds the support for Zilliqa's Ec-Schnorr signature type.

I am a developer from Zilliqa; working on a rosetta sdk implementation for our side. As our blockchain employs a secp256k1 Curve with a schnorr Signature Type, we hope to include this signature and subsequently the signer and verifier support into rosetta-sdk-go.

How does the Zilliqa schnorr signature encoding format differ from the one proposed in BIP 340?

  1. BIP-0340 generates a signature of constant size 64 bytes (r||s) , where r is the X-coordinate of a point on the curve encoded as a 32-bytes value, most significant byte first. s is a scalar encoded as a 32-bytes value, most significant byte first.
  2. ZIL-Schnorr generates a signature of constant size 64 bytes (r||s) , where both r and s are scalars encoded as 32-bytes values, most significant byte first.
  3. Public key as used in BIP-0340, is a point on the curve represented only using its X-coordinate. The public key’s Y-coordinate must be even. Public key used in ZIL-Schnorr is a point on the curve represented in the compressed format that requires 33 bytes (the first byte is a sign byte, 0x02 or 0x03) while the remaining 32 bytes represent the X-coordinate of the point.

Reference

Zilliqa Schnorr Signature: https://dev.zilliqa.com/docs/basics/basics-zil-schnorr-signatures/ Technical Whitepaper: https://docs.zilliqa.com/whitepaper.pdf

Contact

teye@zilliqa.com

patrick-ogrady commented 4 years ago

Thanks for providing this additional detail, @teye! We will kick off some internal review of this and get back to you.

Our primary concern is avoiding namespace collision with other signing schemes. In the case of Schnorr, this is a little more "pronounced" as there are many competing specifications: https://crypto.stackexchange.com/questions/34863/ec-schnorr-signature-multiple-standard

Is there any more detail we can add to the name here to avoid collision? Maybe something like bsi-ecschnorr (open to other ideas too)? @jesseposner may have some more thoughts here.

AmritKumar commented 4 years ago

Thanks for providing this additional detail, @teye! We will kick off some internal review of this and get back to you.

Our primary concern is avoiding namespace collision with other signing schemes. In the case of Schnorr, this is a little more "pronounced" as there are many competing specifications: https://crypto.stackexchange.com/questions/34863/ec-schnorr-signature-multiple-standard

Is there any more detail we can add to the name here to avoid collision? Maybe something like bsi-ecschnorr (open to other ideas too)? @jesseposner may have some more thoughts here.

BSI scheme does not prevent related key attacks which ZIL-Schnorr does by hashing the public key with the message. Another difference is in the serialization of the random point. In the BSI scheme, only the x-coordinate of the point is used while in ZIL-Schnorr, the entire point is used in the compressed form. Having said that the two schemes are very close. Maybe we could call it zil-bsi-schnorr?

jesseposner commented 4 years ago

It sounds like the only difference between ZIL-Schnorr and BIP-0340 is that ZIL-Schnorr uses compressed SEC encoding for the public keys and BIP-0340 uses a novel 32-byte encoding. Is that correct?

jesseposner commented 4 years ago

I agree that bsi-ecschnorr isn't the right label here because the ZIL scheme diverges from BSI.

patrick-ogrady commented 4 years ago

@teye after much back and forth, we believe that simply enumerating styles of schnorr (schnorr_1, schnorr_2, etc) is the best way to resolve this "multi-standard" dilemma. If you could, please change ecschnorr to schnorr_1.

It would also be a good idea to provide a link to some more information about the scheme used + info about the encoding in the description of SignatureType (i.e. where both r and s are scalars encoded as 32-bytes values, most significant byte first) given schnorr_1 doesn't mean anything out of context.

teye commented 4 years ago

Thank you @patrick-ogrady and @jesseposner for reviewing. I have updated the enum to schnorr_1 as discussed and also the README

patrick-ogrady commented 4 years ago

Not sure why this didn't kickoff builds...going to close/open

patrick-ogrady commented 4 years ago

Alright looked like that worked... @teye thanks for the changes, we are planning to merge this soon! This works with the current secp256k1 CurveType encoding right?

heimdall-asguard commented 4 years ago

Review Error for jakecraige @ 2020-08-14 16:41:09 UTC User failed mfa authentication, public email is not set on your github profile. see go/mfa-help

heimdall-asguard commented 4 years ago

Review Error for jesseposner @ 2020-08-14 16:51:13 UTC User must have write permissions to review

jesseposner commented 4 years ago

@teye What about this detail:

Public key used in ZIL-Schnorr is a point on the curve represented in the compressed format that requires 33 bytes (the first byte is a sign byte, 0x02 or 0x03) while the remaining 32 bytes represent the X-coordinate of the point.

I'm not seeing that in the white paper that you linked.

heimdall-asguard commented 4 years ago

Review Error for jesseposner @ 2020-08-14 17:03:07 UTC User must have write permissions to review

teye commented 4 years ago

Alright looked like that worked... @teye thanks for the changes, we are planning to merge this soon! This works with the current secp256k1 CurveType encoding right?

@patrick-ogrady, yes this works with the current secp256k1 curve.

@jesseposner , I will check with the team on the public key portion in the whitepaper.

teye commented 4 years ago

@jesseposner we have updated the readme with our library source code.

Hope this could help the team and also the community users in understanding our implementation.