You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The biggest effort will be to figure out a way to specify implementations for the composite algorithms. They should be kept fairly minimal, and essentially only specify certain hard coded values, but otherwise use the same functions as the base algorithm.
As far as I can tell, this is what's needed:
for the base implementation:
A way to specify in the implementation context structure that certain values are immutable.
(for example, I expect that the hash function in the RSA implementation context could be marked as such)
for each composite algorithm implementation:
an init function that does most of what the base init function does, but sets certain hard coded values.
(for example, a sha256WithRSAEncryption init function would set the hash function to be sha256 and mark it as immutable)
a settable params function that returns an OSSL_PARAM array that's like the corresponding base, except for the param to set the parameters that this implementation regards as immutable
(for example, a sha256WithRSAEncryption settable params function would return a table like the rsaEncryption settable params function, with without the "digest" param)
a function or parameter return that specifies the key type that the algorithm supports.
Other than that, this should just be about adding OSSL_ALGORITHM lines and OSSL_DISPATCH tables for the composite algorithm implementations. Don't forget to include OIDs.
At a minimum, we should do this for all composite algorithms that are currently specified in https://github.com/openssl/openssl/blob/master/crypto/objects/obj_xref.h and for which we already support the base algorithms (the GOST entries will have to be done by the GOST provider project, which is an external project).
Note: the DSA aliasing problem that I just made a PR to fix (openssl/openssl#24828) is a blocker for completing this task, at least in so far that DSA goes. All other signature schemes are good to go, though.
The biggest effort will be to figure out a way to specify implementations for the composite algorithms. They should be kept fairly minimal, and essentially only specify certain hard coded values, but otherwise use the same functions as the base algorithm.
As far as I can tell, this is what's needed:
for the base implementation:
A way to specify in the implementation context structure that certain values are immutable.
(for example, I expect that the hash function in the RSA implementation context could be marked as such)
for each composite algorithm implementation:
an init function that does most of what the base init function does, but sets certain hard coded values.
(for example, a
sha256WithRSAEncryption
init function would set the hash function to besha256
and mark it as immutable)a settable params function that returns an OSSL_PARAM array that's like the corresponding base, except for the param to set the parameters that this implementation regards as immutable
(for example, a
sha256WithRSAEncryption
settable params function would return a table like thersaEncryption
settable params function, with without the "digest" param)a function or parameter return that specifies the key type that the algorithm supports.
Other than that, this should just be about adding
OSSL_ALGORITHM
lines andOSSL_DISPATCH
tables for the composite algorithm implementations. Don't forget to include OIDs.At a minimum, we should do this for all composite algorithms that are currently specified in https://github.com/openssl/openssl/blob/master/crypto/objects/obj_xref.h and for which we already support the base algorithms (the GOST entries will have to be done by the GOST provider project, which is an external project).
Design ref: openssl/openssl#22129
The text was updated successfully, but these errors were encountered: