Metadata signing spec is wrong #16

New issue

Closed

opened 2019-07-01 19:25:41 +02:00 by lyoshenka · 2 comments

lyoshenka commented

2019-07-01 19:25:41 +02:00

(Migrated from github.com)

@tiger5226 commented on Wed Jun 12 2019

I implemented this outside of the SDK in Chainquery. There were a number of things wrong or missing.

The most important thing missing is the fact that the outpoint hash is used in the claim signing process and is needed to validate the signature too.

specifics include:

How to get outpoint hash
- reverse bytes of the txid of the first input of the transaction containing the claim.
- convert the vout to a little endian uint32 4 byte array.
- append them both into a byte array
- hex encode to string and return it
signature creation
- in between the version and the certificate id the outpoint hash in bytes needs to be inserted.
signature validation
the outpoint hash needs to be inserted in the same place to validate the signature.
signature format
- 64 byte concatenation of the unsigned 32 byte R value and unsigned 32 byte S value correlating to the ECDSA x,y values.
public key format
- the public key format is encoded to ans1 ECDSA DER
  - encoding the special format of the public key is non-trivial and a reference implmentation is a good idea. There is one in the lbryschema.go repo.
- the decoding requires specific ans1 object id values
  - ans1 encoding oid for ecdsa public key = 1, 2, 840, 10045, 2, 1
  - asn1 encoding oid for secp256k1 = 1, 3, 132, 0, 10
  - asn1 marshalling structure contains just the algorithm, rawContent and the publickey as an ans1 formatted bitstring.

@tiger5226 commented on [Wed Jun 12 2019](https://github.com/lbryio/whitepaper/issues/1) I implemented this outside of the SDK in Chainquery. There were a number of things wrong or missing. The most important thing missing is the fact that the outpoint hash is used in the claim signing process and is needed to validate the signature too. specifics include: - How to get outpoint hash - reverse bytes of the txid of the first input of the transaction containing the claim. - convert the vout to a little endian uint32 4 byte array. - append them both into a byte array - hex encode to string and return it - signature creation - in between the version and the certificate id the outpoint hash in bytes needs to be inserted. - signature validation - the outpoint hash needs to be inserted in the same place to validate the signature. - signature format - 64 byte concatenation of the unsigned 32 byte R value and unsigned 32 byte S value correlating to the ECDSA x,y values. - public key format - the public key format is encoded to ans1 ECDSA DER - encoding the special format of the public key is non-trivial and a reference implmentation is a good idea. There is one in the lbryschema.go repo. - the decoding requires specific ans1 object id values - ans1 encoding oid for ecdsa public key = `1`, `2`, `840`, `10045`, `2`, `1` - asn1 encoding oid for secp256k1 = `1`, `3`, `132`, `0`, `10` - asn1 marshalling structure contains just the algorithm, rawContent and the publickey as an ans1 formatted bitstring.

lyoshenka commented

2019-12-04 22:16:35 +01:00

(Migrated from github.com)

@tiger5226 im fixing this now. rather than go into detail about the signature and pubkey format, i'd rather link to some code that shows how it works. do you have it all in one place somewhere in lbryschema.go or chainquery that i can link to to show the whole process?

lyoshenka commented

2019-12-04 22:53:15 +01:00

(Migrated from github.com)

@tiger5226 i made some changes in #19

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: LBRYCommunity/spec#16

No description provided.