eembc / securemark-tls Goto Github PK

mbedTLS is moving to 3.x. The original version of SecureMark had a reference port for 2.24. Update this to the final 2.x mbedTLS.

The current definition of the th_ecdh DUT API opens up for doing the time-intensive calculation at init time instead of the function that's being called during profiling. Is that intended?

I'd suggest supplying the public key to derive against in the calc_secret function instead of during init to enforce actually doing the operation on each iteration.

The th_ functions often pass down parameters that don't change, and are specific to the context. They should be removed from the parameter list and left up to the dev to store in a local context. For example th_sha_* functions send the same enum indicating the SHA size to every function call. Same goes for ECC group, and RSA id.

Isn't the amount of rounds dictated by the key length (supplied in a different parameter?). I have yet to see an accelerator which allows specifying a custom amount of rounds, since the amount of rounds for a given keysize is actually specified by the spec.

In version 1.0.x, after the timing loop in ee_aes128_ecb, the code does not call de-init. This does not impact mbedtls but it does impact PSA.

A workaround branch will be created for 1.0.x.

aes cmac not support?

In the self-hosted example, main.c defines a wrapper for each primitive which is nearly identical to the firmware bench_* primitives found in profile/ee_bench.c. It appears the only thing missing is a return CRC from the bench_ code, and a subtle manipulation of the timestamp logic.

This would significantly reduce the size of main.c.