implement ecdsa sign, verify, sign_prehashed and verify_prehashed

[melekes]

Closes #1968

Note this PR implements ecdsa_sign and introduces ecdsa_verify function, which are both out of the scope of the issue above.

[melekes]

should we return a single slice instead? signature (64 bytes) + 1 recovery byte

[melekes]

@tomaka can I also implement ecdsa verity (should be straightforward now that we have verify_prehashed)?

[github-actions]

twiggy diff report

Difference in .wasm size before and after this pull request.

---

 Delta Bytes │ Item
─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
      +66512 ┊ data[0]
      +46721 ┊ smoldot::executor::host::ReadyToRun::run_once::h588a43ce7bb9bec7
      +42088 ┊ smoldot::json_rpc::methods::MethodCall::from_defs::h08bdee9af59cef7f
      -42088 ┊ smoldot::json_rpc::methods::MethodCall::from_defs::h44ff5fc34961553a
      -39988 ┊ smoldot::executor::host::ReadyToRun::run_once::h36ac176a2ba9b38e
      +13035 ┊ <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h3a061a7a11693ceb
      -13035 ┊ <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h99900cb09ebfa9c0
      +12074 ┊ smoldot::network::service::ChainNetwork<TNow>::next_event::{{closure}}::h30560f19388ced0d
      -12074 ┊ smoldot::network::service::ChainNetwork<TNow>::next_event::{{closure}}::he4aaa26d26cbbfb2
      +11465 ┊ <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h66d64f78fd502255
      -11465 ┊ <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::hfe120633e113f3f7
      +10525 ┊ <parity_wasm::elements::ops::Instruction as parity_wasm::elements::Deserialize>::deserialize::h0bbcef032d608a86
      -10525 ┊ <parity_wasm::elements::ops::Instruction as parity_wasm::elements::Deserialize>::deserialize::h5fe00cff0cc1bad7
      -10172 ┊ smoldot_light_base::Client<TChain,TPlat>::add_chain::h386d3178de44e3b1
      +10172 ┊ smoldot_light_base::Client<TChain,TPlat>::add_chain::hc7322fbe2c61cf84
      -10109 ┊ <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h00f08a3413b42ea4
      +10109 ┊ <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h33e133753a2f823a
       +9937 ┊ smoldot::libp2p::connection::established::substream::Substream<TNow,TRqUd,TNotifUd>::read_write2::h5b5f779dde123186
       -9937 ┊ smoldot::libp2p::connection::established::substream::Substream<TNow,TRqUd,TNotifUd>::read_write2::h7439ec84acda52b3
       -9384 ┊ smoldot::json_rpc::methods::Response::to_json_response::h6706eac6a04ee6f4
      +31263 ┊ ... and 25456 more.
     +101733 ┊ Σ [25476 Total Rows]

[tomaka]

can I also implement ecdsa verity (should be straightforward now that we have verify_prehashed)?

Yeah go ahead

[tomaka]

Looks good, modulo avoiding the copy!

[tomaka]

Note that I haven't properly checked if the behavior is the same as in Substrate, but it seems good.

Unfortunately none of the crypto functions in host.rs are tested because writing unit tests for that is a huge effort.

I know that a team from w3f is currently writing a test framework where they give runtimes to a client and check if said client behaves properly, but it's not ready yet.

[melekes]

Unfortunately none of the crypto functions in host.rs are tested because writing unit tests for that is a huge effort.

yeah, I figured

I know that a team from w3f is currently writing a test framework where they give runtimes to a client and check if said client behaves properly, but it's not ready yet.

this sounds like exactly what is needed!