Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for composite algorithm names (as well as OIDs for them) in our providers #231

Open
Tracked by #163
levitte opened this issue Sep 28, 2023 · 4 comments
Assignees
Labels
triaged: feature This is a feature/enchancement request
Milestone

Comments

@levitte
Copy link
Member

levitte commented Sep 28, 2023

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).

Design ref: openssl/openssl#22129

@levitte
Copy link
Member Author

levitte commented Sep 28, 2023

This should really happen in parallel with #228, #229 and #230, to ensure that everything fits together.

@levitte levitte self-assigned this Nov 7, 2023
@nhorman nhorman added the triaged: feature This is a feature/enchancement request label Apr 2, 2024
@nhorman nhorman added this to the 3.4.0 milestone Jun 17, 2024
@levitte
Copy link
Member Author

levitte commented Jul 10, 2024

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.

@levitte
Copy link
Member Author

levitte commented Jul 11, 2024

The RSA-{hash} signature schemes are completed with the implementation of #228 (openssl/openssl#23416).

A new issue will be created to do the same sort of work with EC and DSA

@levitte
Copy link
Member Author

levitte commented Jul 23, 2024

EdDSA signature schemes added in openssl/openssl#24975

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triaged: feature This is a feature/enchancement request
Projects
Status: In progress
Status: In Progress
Development

No branches or pull requests

2 participants