Browse Source

(squash this) Mixed up field element and curve element. Idea still stands.

pull/2091/head
ValarDragon 7 years ago
parent
commit
3d5d254932
1 changed files with 7 additions and 3 deletions
  1. +7
    -3
      docs/architecture/adr-014-secp-malleability.md

+ 7
- 3
docs/architecture/adr-014-secp-malleability.md View File

@ -22,7 +22,8 @@ Removing this second layer of signature malleability concerns could ease downstr
### ECDSA context
Secp256k1 is ECDSA over a particular curve.
The signature is of the form `(r, s)`, where `s` is an elliptic curve group element.
The signature is of the form `(r, s)`, where `s` is a field element.
(The particular field is the `Z_n`, where the elliptic curve has order `n`)
However `(r, -s)` is also another valid solution.
Note that anyone can negate a group element, and therefore can get this second signature.
@ -30,10 +31,13 @@ Note that anyone can negate a group element, and therefore can get this second s
We can just distinguish a canonical form for the ECDSA signatures.
Then we require that all ECDSA signatures be in the form which we defined as canonical.
We reject signatures in non-canonical form.
A canonical form is rather easy to define and check.
It would just be the smaller of the two y coordinates for the given x coordinate, defined lexicographically.
Example of other systems using this: https://github.com/zkcrypto/pairing/tree/master/src/bls12_381#serialization.
It would just be the smaller of the two values for `s`, defined lexicographically.
This is a simple check, instead of checking if `s < n`, instead check `s <= (n - 1)/2`.
An example of another cryptosystem using this
is the parity definition here https://github.com/zkcrypto/pairing/pull/30#issuecomment-372910663.
## Proposed Implementation


Loading…
Cancel
Save