k256: add Wycheproof test data

[daviddrysdale]

No description provided.

[tarcieri]

@daviddrysdale do you know offhand which vectors are failing (i.e. what is the description of the case being tested)?

[daviddrysdale]

comment:

                    // - ECDSA case 304 [valid] edge case for signature malleability
                    // - ECDSA case 305 [valid] edge case for signature malleability

[daviddrysdale]

Original JSON fragment:

    {
      "key" : {
        "curve" : "secp256k1",
        "keySize" : 256,
        "type" : "EcPublicKey",
        "uncompressed" : "043a3150798c8af69d1e6e981f3a45402ba1d732f4be8330c5164f49e10ec555b4221bd842bc5e4d97eff37165f60e3998a424d72a450cf95ea477c78287d0343a",
        "wx" : "3a3150798c8af69d1e6e981f3a45402ba1d732f4be8330c5164f49e10ec555b4",
        "wy" : "221bd842bc5e4d97eff37165f60e3998a424d72a450cf95ea477c78287d0343a"
      },
      "keyDer" : "3056301006072a8648ce3d020106052b8104000a034200043a3150798c8af69d1e6e981f3a45402ba1d732f4be8330c5164f49e10ec555b4221bd842bc5e4d97eff37165f60e3998a424d72a450cf95ea477c78287d0343a",
      "keyPem" : "-----BEGIN PUBLIC KEY-----\nMFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAEOjFQeYyK9p0ebpgfOkVAK6HXMvS+gzDF\nFk9J4Q7FVbQiG9hCvF5Nl+/zcWX2DjmYpCTXKkUM+V6kd8eCh9A0Og==\n-----END PUBLIC KEY-----",
      "sha" : "SHA-256",
      "type" : "EcdsaVerify",
      "tests" : [
        {
          "tcId" : 304,
          "comment" : "edge case for signature malleability",
          "msg" : "313233343030",
          "sig" : "304402207fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a002207fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a0",
          "result" : "valid",
          "flags" : []
        }
      ]
    },
    {
      "key" : {
        "curve" : "secp256k1",
        "keySize" : 256,
        "type" : "EcPublicKey",
        "uncompressed" : "043b37df5fb347c69a0f17d85c0c7ca83736883a825e13143d0fcfc8101e851e800de3c090b6ca21ba543517330c04b12f948c6badf14a63abffdf4ef8c7537026",
        "wx" : "3b37df5fb347c69a0f17d85c0c7ca83736883a825e13143d0fcfc8101e851e80",
        "wy" : "0de3c090b6ca21ba543517330c04b12f948c6badf14a63abffdf4ef8c7537026"
      },
      "keyDer" : "3056301006072a8648ce3d020106052b8104000a034200043b37df5fb347c69a0f17d85c0c7ca83736883a825e13143d0fcfc8101e851e800de3c090b6ca21ba543517330c04b12f948c6badf14a63abffdf4ef8c7537026",
      "keyPem" : "-----BEGIN PUBLIC KEY-----\nMFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAEOzffX7NHxpoPF9hcDHyoNzaIOoJeExQ9\nD8/IEB6FHoAN48CQtsohulQ1FzMMBLEvlIxrrfFKY6v/3074x1NwJg==\n-----END PUBLIC KEY-----",
      "sha" : "SHA-256",
      "type" : "EcdsaVerify",
      "tests" : [
        {
          "tcId" : 305,
          "comment" : "edge case for signature malleability",
          "msg" : "313233343030",
          "sig" : "304402207fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a002207fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a1",
          "result" : "valid",
          "flags" : []
        }
      ]
    },

[tarcieri]

Interesting

[daviddrysdale]

Looks like CI fails at least one extra test case compared to my local (macOS x86) box.

[tarcieri]

I'll go ahead and extract those as some unit/regression tests and see if I can find the issue.

[tarcieri]

Some notes on this...

The first example (tcId: 304) has an s-component equal to the scalar modulus / 2, namely:

7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a0

Per BIP62 rules this should be valid:

https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki#Low_S_values_in_signatures

The value S in signatures must be between 0x1 and 0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0 (inclusive).

...however it is being rejected, so it seems this is being mishandled.

The second signature (tcId: 305) has an s-component equal to the scalar modulus / 2 + 1, namely:

7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a1

This is outside of the range allowed under low-s normalization, so I'm confused why it says "result" : "valid", but also a bit confused why there would even be tests for malleability if they weren't using low-s normalization rules to begin with.

[tarcieri]

I opened #385 to fix the first test case.

I'm confused why these would be failing if they were low-S normalized. In #385 I made explicit regression tests cases for both and confirmed they were passing if explicitly normalized (but deleted tc: 305 as it's expected to be rejected).

[tarcieri]

@daviddrysdale just landed #385 if you want to try rebasing, although I would expect both of those cases to have succeeded if the signature was low-S normalized even before that.

I also made a line note about a slightly more straightforward way to ensure the signature is normalized. That might help.

[codecov-commenter]

Codecov Report

Merging #384 (3f1a302) into master (3640681) will increase coverage by 0.25%.
The diff coverage is 90.90%.

@@            Coverage Diff             @@
##           master     #384      +/-   ##
==========================================
+ Coverage   58.44%   58.70%   +0.25%     
==========================================
  Files          29       29              
  Lines        4096     4129      +33     
==========================================
+ Hits         2394     2424      +30     
- Misses       1702     1705       +3     

Impacted Files	Coverage Δ
k256/src/ecdsa.rs	90.00% <90.90%> (+4.28%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3640681...3f1a302. Read the comment docs.

[tarcieri]

@daviddrysdale which one is failing now? it looks like a different signature than the previous two

[daviddrysdale]

I think the CI failure is this one:

    {
      "key" : {
        "curve" : "secp256k1",
        "keySize" : 256,
        "type" : "EcPublicKey",
        "uncompressed" : "04464f4ff715729cae5072ca3bd801d3195b67aec65e9b01aad20a2943dcbcb584b1afd29d31a39a11d570aa1597439b3b2d1971bf2f1abf15432d0207b10d1d08",
        "wx" : "464f4ff715729cae5072ca3bd801d3195b67aec65e9b01aad20a2943dcbcb584",
        "wy" : "00b1afd29d31a39a11d570aa1597439b3b2d1971bf2f1abf15432d0207b10d1d08"
      },
      "keyDer" : "3056301006072a8648ce3d020106052b8104000a03420004464f4ff715729cae5072ca3bd801d3195b67aec65e9b01aad20a2943dcbcb584b1afd29d31a39a11d570aa1597439b3b2d1971bf2f1abf15432d0207b10d1d08",
      "keyPem" : "-----BEGIN PUBLIC KEY-----\nMFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAERk9P9xVynK5Qcso72AHTGVtnrsZemwGq\n0gopQ9y8tYSxr9KdMaOaEdVwqhWXQ5s7LRlxvy8avxVDLQIHsQ0dCA==\n-----END PUBLIC KEY-----",
      "sha" : "SHA-256",
      "type" : "EcdsaVerify",
      "tests" : [
        {
          "tcId" : 296,
          "comment" : "smallish r and s^-1",
          "msg" : "313233343030",
          "sig" : "302c02072d9b4d347952cc022100fcbc5103d0da267477d1791461cf2aa44bf9d43198f79507bd8779d69a13108e",
          "result" : "valid",
          "flags" : []
        }
      ]
    },

(BTW, the test passes for me on Linux and macOS, both x86_64)

[daviddrysdale]

Test 294 / tcId=296 seems to be the only failure, and it only fails with --target i686-unknown-linux-gnu – x86_64 passes.

[tarcieri]

Looks like this caught a legitimate bug in the 32-bit field arithmetic backend. It's triggering a debug assert during lazy normalization.

Thanks for the help @daviddrysdale!

[tarcieri]

Opened #386 which adds that test vector in isolation.

[tarcieri]

Note: #388 should address the bug caught by tcId=296

[tarcieri]

@daviddrysdale I think #388 should address the only remaining test failure.

Can you rebase?

[tarcieri]

Nice, looks like everything is passing now

[daviddrysdale]

Is it worth updating the new_wycheproof_test! macro to always normalize_s()?

[tarcieri]

For now, at least, it will only work with k256.

I can look at making it work with p256 as well.

[tarcieri]

Thank you!