From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] [RFC] [staging/CryptoLibrary] Openssl1.1 replacement proposal To: Yao, Jiewen ,devel@edk2.groups.io From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= X-Originating-Location: Berlin, Land Berlin, DE (104.28.114.22) X-Originating-Platform: Mac Safari 16.3 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Sat, 04 Feb 2023 08:04:22 -0800 References: In-Reply-To: Message-ID: <32073.1675526662359856861@groups.io> Content-Type: multipart/alternative; boundary="tS6PuWa0pRrdO84694QL" --tS6PuWa0pRrdO84694QL Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 vari= ous reasons, we forked off existing crypto code and kept our changes downst= ream (I do *not* recommend this and this will be taken care of in the futur= e, but remember this is non-commercial and non-mission-critical). When I wa= s optimizing the code to be tailored to our RSA usage, I noticed that OpenS= SL does a whole load of complicated stuff in the BigNum space [1], when rea= lly 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 wa= s questioning my Maths for a bit, wondering why OpenSSL never implemented a= ny 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 b= ut a bare minimum [2]. Just look at the difference in mere code size. I *se= verely* 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 pers= pective, 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 san= e 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 t= o review and maintain, but lets such obvious "macro optimizations", that im= prove code performance, size, and readability (if documented correctly) at = once, slide. Best regards, Marvin [1] https://github.com/openssl/openssl/blob/b85a1f13d6d99ef96cc81d17d5ff991= e1294a21b/crypto/bn/bn_gcd.c#L197-L512 [2] https://github.com/Mbed-TLS/mbedtls/blob/10ada3501975e7abab25a7fa28e9e8= e0f6b4259f/library/bignum_core.c#L454-L465 --tS6PuWa0pRrdO84694QL Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Jiewen,

Thanks for the proposal!

Regarding OpenSSL= vs mbedtls, maybe a little fun fact: For a non-commercial project, we move= d away from OpenSSL also due to size constraints. For various reasons, we f= orked 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 t= his 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 l= oad of complicated stuff in the BigNum space [1], when really due to the sp= ecific guarantees and requirements of RSA with Montgomery Arithmetics, it c= an 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 short= cut for this.

When I was looking at mbedtls today, I was surpris= ed that not only did they optimize the logic to run solely in the machine i= nteger space like I did, they also have some very smart optimization to shr= ink 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 explana= tion 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 firm= ware space, in my opinion. I haven't checked other things in detail, but mo= st things look rather sane to me.

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

Best r= egards,
Marvin

[1] https://github.com/openssl/openssl/blob/b85a1f13d6d99ef96cc81d1= 7d5ff991e1294a21b/crypto/bn/bn_gcd.c#L197-L512

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