Hi Jiewen,

Thanks for the proposal!

Regarding OpenSSL vs mbedtls, maybe a little fun fact: For a non-commercial project, we moved away from OpenSSL also due to size constraints. For various reasons, we forked off existing crypto code and kept our changes downstream (I do *not* recommend this and this will be taken care of in the future, but remember this is non-commercial and non-mission-critical). When I was optimizing the code to be tailored to our RSA usage, I noticed that OpenSSL does a whole load of complicated stuff in the BigNum space [1], when really due to the specific guarantees and requirements of RSA with Montgomery Arithmetics, it can all be done in the machine integer space. In fact, I was questioning my Maths for a bit, wondering why OpenSSL never implemented any tailored shortcut for this.

When I was looking at mbedtls today, I was surprised that not only did they optimize the logic to run solely in the machine integer space like I did, they also have some very smart optimization to shrink the code to nothing but a bare minimum [2]. Just look at the difference in mere code size. I *severely* dislike the absence of any sort of explanation or intuition for the code, let alone a proof of correctness. But just from the code design perspective, this is exactly what you want in the firmware space, in my opinion. I haven't checked other things in detail, but most things look rather sane to me.

I wish I knew why OpenSSL seems to prefer many implementations of the same algorithms in ASM, which has performance benefits but is an absolute pain to review and maintain, but lets such obvious "macro optimizations", that improve code performance, size, and readability (if documented correctly) at once, slide.

Best regards,
Marvin

[1] https://github.com/openssl/openssl/blob/b85a1f13d6d99ef96cc81d17d5ff991e1294a21b/crypto/bn/bn_gcd.c#L197-L512

[2] https://github.com/Mbed-TLS/mbedtls/blob/10ada3501975e7abab25a7fa28e9e8e0f6b4259f/library/bignum_core.c#L454-L465