Prevent signature malleability

[dholms]

We want a canonical representation for every signature. Otherwise a commit or a plc operation can be deterministically transformed such that it has a different CID (without possession of the private key).

The crypto library that we use allows signatures to be encoded as compact bytes or DER-encoded.

This leads to similar consequences as allowing high-s signatures (which we disallow for repo commits & plc operations).

As a fix, we alter the signature verification logic to first parse the signature from compact bytes before passing to the verify function.

In some cases where distributed consensus is not necessary, such as JWT signatures, we allow DER signatures as well as high-s signatures.

---

Reference:
did-method-plc/did-method-plc#53
paulmillr/noble-curves#99

[DavidBuchanan314]

btw I think you also still have malleability due to =-padding. Example: https://plc.directory/did:plc:m4aa5oy4t7rk5m6uthcg2dwy/log/audit

[dholms]

Yup this library works with just bytes, so I'll need to fix that over in PLC.

Thanks for the reports on both of these!

[bnewbold]

oof, another curve-ball.

I think there needs to be tests in here with otherwise-valid, DER-encoded signatures for both of the curve types, to confirm that this actually disallows that format as expected. The existing tests presumably cover the happy path. I feel like we've been bitten too many times with "fixed for one curve type, but not the other".

It would be most helpful to add them to the "invalid" DER-encoded examples to interop-test-files/crypto/signature-fixtures.json.

[bnewbold]

yay, thanks for adding test fixtures!

I tried these new fixtures against golang and they were already rejected (that is, golang impl already correctly rejected DER-encoded signatures). I won't commit those golang changes until this PR gets merged.