Feat/hw accelerated sha updated

[AnthonyGrondin]

Built on top of #45
Supersedes #19

Current status: Draft until the following topics have been resolved.

• Figure out why the binary size is larger when using HW sha.
  (Solved: Now binary size is smaller when using HW sha)
• Benchmark a clients and servers to see if there's a significant performance increase / decrease.
  (Solved: Server example is slightly faster and self-tests are marginally faster)
• Once binary size and speed figured out, decide if this PR is a good tradeoff overall.
  (Solved: The numbers speak for themselves)
• Figure out the case for esp32. Mbedtls combines both SHA224 and SHA256 in the same function calls, but esp32 only support SHA256.
  (Solved: For now, esp32 still uses SW sha for SHA224 and SHA256)

/cc @bugadani @Dominaezzz
Pinging you since this has been discussed in the matrix channel.

[Dominaezzz]

Regarding benchmarks, I found this earlier today.

[AnthonyGrondin]

Oh wow, good find. I would've never thought about this.

[AnthonyGrondin]

Now that esp_hal had a new release, I rebased on top of the current HEAD and removed the patches.
I also fixed a few missing todos and a memory leak bug.

I've a few metrics side by side on an esp32s3:

Self-tests:

Hash Algorithm	Software (cycles)	Hardware (cycles)	Hardware Faster (x times)
SHA-1	3,356,883	654,913	5.12
SHA-224	8,219,260	653,337	12.58
SHA-256	8,206,023	650,996	12.61
SHA-384	13,575,266	587,879	23.09
SHA-512	13,558,071	584,100	23.21

edge_server example using SW SHA:

App/part. size:    999,344/1,048,576 bytes, 95.30%
Benchmark 1: curl -k https://192.168.69.166
  Time (mean ± σ):      2.436 s ±  0.023 s    [User: 0.003 s, System: 0.004 s]
  Range (min … max):    2.408 s …  2.470 s    10 runs

edge_server example using HW SHA:

App/part. size:    983,040/1,048,576 bytes, 93.75%
Benchmark 1: curl -k https://192.168.69.166
  Time (mean ± σ):      2.406 s ±  0.023 s    [User: 0.003 s, System: 0.004 s]
  Range (min … max):    2.375 s …  2.464 s    10 runs

[AnthonyGrondin]

I'll put this in Draft until we can get the compilation to work with edge_server (edge-net). This is currently due to a lifetime issue, where we cannot statically borrow in a loop.

The lifetime issue is currently being fixed in:

• net: refactor to simplify lifetimes/generics. embassy-rs/embassy#3329
• [WIP] Adapt changes to upstream embassy-net ivmarkov/edge-net#35

Fixed in:

• (edge-http) Server non-static handler ivmarkov/edge-net#40

[bjoernQ]

can't we just use 0.6.1 and not patch the crate?

[bjoernQ]

For whatever reason I get compile errors for the C3 and async (but not S3?) - using embassy-executor 0.6.1 (and not patching any embassy crate) makes it work for me. Wonder why it works in CI 🤔

[AnthonyGrondin]

This is due to changes in the nightly wakers, where embassy-executor 0.6.1 uses the new API, whereas 0.6.0 uses the existing API, that builds up to nightly-2024-09-06 I believe.

Once 1.83 is released, we can use embassy-executor 0.6.1 and force the MSRV to 1.83. That being said, this is all for examples, so it shouldn't affect the inner workings of the crate.

[bjoernQ]

This is due to changes in the nightly wakers, where embassy-executor 0.6.1 uses the new API, whereas 0.6.0 uses the existing API, that builds up to nightly-2024-09-06 I believe.

Once 1.83 is released, we can use embassy-executor 0.6.1 and force the MSRV to 1.83. That being said, this is all for examples, so it shouldn't affect the inner workings of the crate.

Ah yeah - thanks for the explanation (which also explains why it fails locally for me using a recent nightly)

[bjoernQ]

Thanks