Re: [edk2-devel] [PATCH 1/2] Reconfigure OpensslLib to add elliptic curve chipher algorithms

["yi1 li" <yi1.li@intel.com>]

Agree with that and I think the first issue is OPENSSL_NO_* be not cover every file related to some feature in openssl (like ec).
Once those macro defines can cover everything, we can put all files in OpensslLib.inf [Source],
and control macro defines in opensslconf.h by PCDs to do customization.
Openssl community feels ok to it and that's exactly what they do, like asn1, just not covering all features.
https://github.com/openssl/openssl/issues/17801

I am glad to push it forward, but, it seems will be a long time and platform needs to support WPA3 as soon as possible.
I'm thinking about whether we can use a new OpensslEclib.inf to enable ECC firstly to meet customer needs?

Thanks!
Yi Li
-----Original Message-----
From: Yao, Jiewen <jiewen.yao@intel.com> 
Sent: Wednesday, March 2, 2022 7:57 PM
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Li, Yi1 <yi1.li@intel.com>; devel@edk2.groups.io; Kovvuri, Vineel <vineelko@microsoft.com>; Luo, Heng <heng.luo@intel.com>
Subject: RE: [edk2-devel] [PATCH 1/2] Reconfigure OpensslLib to add elliptic curve chipher algorithms

>From requirement perspective, I am thinking more broadly than just ECC.

Looking at https://github.com/tianocore/edk2/blob/master/CryptoPkg/Library/Include/openssl/opensslconf.h today, we disabled lots of thing, ECDH, ECDSA, TLS1_3, which might be potential useful. While the algorithm we used today such as FFDHE, MD5, SHA1, might be not useful.

Even for ECC, some platform may need normal ECDH/ECDSA. However, some platform may or might not need EdDSA or X-Curve DH. I am not sure if we really need to enable all of them in previous patch set.

SM3 and SM2 are another category. It might be useful for one particular segment, but not useful for others. For example, a SMx-compliant only platform may only requires SM2/SM3 (no RSA/ECC), which a NIST-compliant only platform might not required SMx.


If a platform does have flash size constrain, why it cannot do customization? Why we enforce every platform, from an embedded system to a server use the same default configuration ?

openssl exposes a config file, other crypto lib (mbedtls, wolfssl) also does same thing, such as https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/mbedtls_config.h,
https://github.com/wolfSSL/wolfssl/tree/master/examples/configs
Why we cannot allow a platform override such configuration ?

I am not saying we must do it. But I believe it is worth to revisit, to see if any platform has such need, before draw the conclusion so quick.

Thank you
Yao Jiewen


> -----Original Message-----
> From: Gerd Hoffmann <kraxel@redhat.com>
> Sent: Wednesday, March 2, 2022 3:42 PM
> To: Yao, Jiewen <jiewen.yao@intel.com>
> Cc: Li, Yi1 <yi1.li@intel.com>; devel@edk2.groups.io; Kovvuri, Vineel 
> <vineelko@microsoft.com>; Luo, Heng <heng.luo@intel.com>
> Subject: Re: [edk2-devel] [PATCH 1/2] Reconfigure OpensslLib to add 
> elliptic curve chipher algorithms
> 
> On Wed, Mar 02, 2022 at 06:59:48AM +0000, Yao, Jiewen wrote:
> > I think another option to pursue is to how to control the openssl 
> > configuration
> from module or platform level.
> >
> > E.g. what if platform-A has enough size and wants to use ECC, while 
> > platform-
> B has size constrain and wants to disable ECC ?
> >
> > We can let platform choose if ECC is needed or not? I hope so.
> 
> Not so easy.  Would require to put the way openssl is integrated 
> upside down.  Today openssl is configured and the results (header 
> files etc) are committed to the repo, so the openssl config is the 
> same for everybody.
> 
> Also I expect there is no way around ecc long-term.  WPA3 was 
> mentioned elsewhere in the thread.  For TLS it will most likely be a 
> requirement too at some point in the future.  With TLS 1.2 it is 
> possible to choose ciphers not requiring ECC, for TLS 1.3 ECC is mandatory though.
> 
> So I doubt making ECC optional is worth the trouble.
> 
> take care,
>   Gerd