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

Support passing ssl library key handles to algorithms #369

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

sandro97git
Copy link

I have a use case where I already have the private key represented as an openssl EVP_PKEY instace. Currently an alogrithm constructor for passing such an object directly is missing.

@Thalhammer
Copy link
Owner

Thalhammer commented Feb 25, 2025

Adding support for this is fine from my side. We might wanna consider adding a few things though:

  • Like you already said, a RSA variant is missing
  • We should probably support passing a public key as well (pkey can store both public and private keys) to allow using it when only verification is required.

@sandro97git
Copy link
Author

sandro97git commented Mar 3, 2025

I added commit e37e259 for supporting public keys as well.

If this is fine I can try to add it for RSA as well.

@Thalhammer
Copy link
Owner

Looks fine so far to me.

@sandro97git sandro97git force-pushed the feat/ssl-key-handle branch from e37e259 to f2c1084 Compare March 4, 2025 08:50
@sandro97git sandro97git marked this pull request as ready for review March 4, 2025 08:51
@sandro97git sandro97git force-pushed the feat/ssl-key-handle branch from f2c1084 to ef5df3b Compare March 5, 2025 11:10
@sandro97git
Copy link
Author

@Thalhammer Do you know why the coverage check is failing?

@prince-chrismc
Copy link
Collaborator

@Thalhammer Do you know why the coverage check is failing?

Seems to be having an issue with the gtest code gen from the macro 🤔

Copy link
Collaborator

@prince-chrismc prince-chrismc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Think out load... I am curious if this is more error prone? you can pass any key with any algorithm and name.

Bonus points, new PR with a negative test for the MD* being wrong to the size that would be interesting to see how it fails 🏗️

otherwise this matchs our exsting ctor with a little duplication 👍

@sandro97git
Copy link
Author

sandro97git commented Mar 10, 2025

I agree this is indeed a bit error prone. However this is already possible using the existing ecdsa or rsa constructor.
I'm not an expert on this jwt algorithms but I wonder if it wouldn't be possible to select the alorithm solely based on the key length. Something similar to this code:

const auto bits = EVP_PKEY_bits(private_key.GetRaw());
const EVP_MD* (*md)();
std::size_t siglen;
std::string name;
switch (bits) {
  case 384:
    md = EVP_sha384;
    siglen = 96;
    name = "ES384";
    break;
  case 521: {
    md = EVP_sha512;
    siglen = 132;
    name = "ES512";
    break;
  }
  default:
    throw std::invalid_argument{"unsupported key size: " + std::to_string(bits)};
}

Would this be possible or are keys of the same lenght used for multiple algorithms?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants