Implement Rust Crypto traits for Crypto Accelerators

[bjoernQ]

We already have the digest traits for SHA but ideally, we will provide more

See https://github.com/RustCrypto/traits

• AES
• SHA 🆗
• RSA
• ECC
• HMAC

[Frostie314159]

I was trying to figure out which crypto traits could be implemented for the accelerators, but it seems like the entire structure is geared towards implementations, you can just create out of thin air. I'm pretty sure most accelerators won't work with that, unless we potentially set up a way to have the HAL manage all crypto accelerators, whether they're used or not.

[bjoernQ]

You mean constructors like Digest::new() -> Self?

Yes, that (and the fact that multiple instances can then access the single hardware resource concurrently) is a challenge.

For SHA we have a couple of PRs/issues towards the current implementation

• Refactor SHA to use trait. Implement Digest traits for SHA #1908
• SHA is waaaaay too easy to misuse #2041
• Improve SHA driver API #2049

Not sure if that's the best way forward or if we can come up with another pattern.

[Frostie314159]

The only thing that I can come up with off the top of my head is to have some crate put the peripheral drivers in statics. The shared structs could then contain the internal state of the accelerator for that instance, which would have to be saved and restored for every operation.
I'm pretty sure that this would nullify all speed advantage that crypto accelerators have.

[bjoernQ]

For very small payloads the overhead might vanish the benefits of the crypto-hw-accelerators, but I bet for larger payloads it's still a win. IIRC that is the case for SHA (with all the locking etc.) and SHA isn't too expensive to implement on an MCU-level CPU

I could also imagine to just add a way to save/restore the context to the low-level drivers contained in the HAL and have a separate crate like esp-hal-crypto implementing the Crypto-traits

[bugadani]

As far as I understand, the crypto peripherals are clocked lower than the CPU is. I remember reading somewhere that they can be slower than software. But this doesn't change two things:

• software is not responsible for the security aspects of the algorithm
• the CPU is free to work on other tasks, if the traits offered async APIs (but still, an interrupt wouldn't pause a calculation)

I could also imagine to just add a way to save/restore the context to the low-level drivers contained in the HAL and have a separate crate like esp-hal-crypto implementing the Crypto-traits

The only thing that I can come up with off the top of my head is to have some crate put the peripheral drivers in statics.

A separate crate might be a good way forward.