But, the good news is that this accelerates certain primitives within a Rust crate that was written by a cryptographer I personally know and trust; I think she's done a good job with the validation and test vectors, and she's been meticulous on documentation.
The theory is that as long as I don't break her tests, I'm probably OK. I did bump into some corner cases for correctness that might be extremely hard to catch in a random vector test bench, which I've noted in the post, but I do have some synthetic vectors that try to make sure I don't have a problem. I also tried hard to make sure I didn't introduce any new timing side channels; since all the ops are constant-time, hopefully I'm safe there.
So, I'm fully aware that I'm not perhaps the best qualified person in the world to build this. However, as I had mentioned elsewhere, my attempt to get source code from several research groups who have built such blocks met with no success. And also knowing how the silicon industry works, any "secure microcontroller" group peddling you some secret sauce closed source cryptoblocks likely were not designed to any level of scrutiny I would be satisfied with. Given the options of no acceleration, dubious closed source blocks, or trying to roll my own, I went with the latter, but with copious amount of documentation so that hopefully people smarter than me will have an easy time to review it for errors.
As a side note, in terms of things that I did implement for this system that should be cause for worry, I'd personally say the TRNG is the most worrisome, because TRNGs are full of scary footguns that are very exploitable. Then I'd worry about the AES instructions in the RISC-V core, the Curve25519 engine, and the SHA hardware accelerator in that order. I didn't write the AES instructions or the SHA accelerator, but I also haven't done a thorough review of them for things like timing side channels. I only rank the AES instructions as slightly more worrisome because I know those were implemented by a CPU architect without much input from cryptographers, whereas the SHA block comes from Google's OpenTitan project, which I would /hope/ was thoroughly reviewed but then again I'm just relying on the G-brand.
There is something comforting, though, to be able to know the provenance of your crypto primitives.
I do not assert that this is the case generally, nor particularly here -- I would be quite happy to be wrong about this. But if there's one thing I've taken from my admittedly minor study of crypto is that the most trivial of details can be critically important, and failure to get a detail exactly correct can compromise an entire algorithm and anything built thereupon.
I would love to see hardware acceleration for ed25519, just like there's been hardware acceleration for AES. It could help drive adoption of an algorithm that is less fiddly and easy to get wrong than RSA, and maybe in another 15 years, I'd be able to purchase IT equipment that supports ed25519 and not just hardware accelerated RSA and AES.