-
Notifications
You must be signed in to change notification settings - Fork 95
OpenSSL 3 port
The following are notes on the OpenSSL 3 port extracted from issue #215
Libtpms port to OpenSSL 3 follows suggestions 1) and 2) of the OpenSSL Wiki and where possible 3):
Upgrading to OpenSSL 3.0 from OpenSSL 1.1.1 should be relatively straight forward in most cases. The most likely area where you will encounter problems is if you have used low level APIs in your code (as discussed above). In that case you are likely to start seeing deprecation warnings when compiling your application. If this happens you have 3 options:
Ignore the warnings. They are just warnings. The deprecated functions are still present and you may still use them. However be aware that they may be removed from a future version of OpenSSL.
Suppress the warnings. Refer to your compiler documentation on how to do this.
Remove your usage of the low level APIs. In this case you will need to rewrite your code to use the high level APIs instead.
See discussion here
I doubt that we can replace SHA1_Init
, SHA1_Update
, SHA1_Final
and the same API calls for SHA256, SHA384, and SHA512. We need access to the hash contexts so that the TPM 2 can offer an API for Init/Update/Final and an do a suspend/resume any time in between them.
They are renamed to this here in TPM 2:
#define tpmHashStateSHA1_t SHA_CTX
#define tpmHashStateSHA256_t SHA256_CTX
#define tpmHashStateSHA384_t SHA512_CTX
#define tpmHashStateSHA512_t SHA512_CTX
#define tpmHashStateSM3_256_t SM3_CTX
See discussion here
The function EC_KEY_set_group(eckey, G)
is deprecated but it is not obvious what the replacement is, if there is any.
Symmetric key functions for AES, TDES, Camellia, and SM4 can be replaced by EVP functions at the expense of performance. The EVP functions are much more complicated internally than the ones currently being used and it makes only sense to replace them if the existing functions were to be removed from OpenSSL's public API.