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

pkey: add more support for 'generic' pkey types #329

Merged
merged 6 commits into from
May 13, 2020

Conversation

rhenium
Copy link
Member

@rhenium rhenium commented Feb 16, 2020

This is split from #119. This Pull Request implements more 'generic' operations using the EVP API.

PKCS #8 formats support has been already merged by #297. The code cleanup parts are in #328.

This probably should be merged after the v2.2.0 release.

This resolves #117 (X25519 support).

@rhenium rhenium changed the title pkey: add more support for 'generic pkey: add more support for 'generic' pkey types Feb 16, 2020
@rhenium rhenium modified the milestone: v3.0.0 Feb 18, 2020
@rhenium rhenium force-pushed the ky/pkey-generic-operations branch 3 times, most recently from 51cdf50 to d6c469b Compare April 22, 2020 12:51
The EVP interface cannot tell whether if a pkey contains the private
components or not. Assume it does if it does not respond to #private?.
This fixes the NoMethodError on calling #sign on a generic PKey.
@rhenium rhenium force-pushed the ky/pkey-generic-operations branch from d6c469b to ad38263 Compare May 13, 2020 07:21
rhenium added 5 commits May 13, 2020 17:47
Add two methods to create a PKey using the generic EVP interface. This
is useful for the PKey types we don't have a dedicated class.
Use EVP_DigestSign*() and EVP_DigestVerify*() interface instead of the
old EVP_Sign*() and EVP_Verify*() functions. They were added in OpenSSL
1.0.0.

Also, allow the digest to be specified as nil, as certain EVP_PKEY types
don't expect a digest algorithm.
OpenSSL 1.1.1 added EVP_DigestSign() and EVP_DigestVerify() functions
to the interface. Some EVP_PKEY methods such as PureEdDSA algorithms
do not support the streaming mechanism and require us to use them.
Add OpenSSL::PKey::PKey#derive as the wrapper for EVP_PKEY_CTX_derive().
This is useful for pkey types that we don't have dedicated classes, such
as X25519.
Use the new OpenSSL::PKey::PKey#derive instead of the raw
{EC,}DH_compute_key(), mainly to reduce amount of the C code.
@rhenium rhenium force-pushed the ky/pkey-generic-operations branch from ad38263 to 28edf6b Compare May 13, 2020 08:53
@rhenium rhenium merged commit d669d71 into ruby:master May 13, 2020
@bdewater
Copy link
Contributor

bdewater commented May 16, 2020

@rhenium thank you for your work on this 🙇

I tried using this in cedarcode/cose-ruby#55 but only having PKCS8 for getting raw private/public keys in and out is painful. I'm not very familiar with the OpenSSL API but it seems using the COSE WG example data would be a lot easier if we had access to:

  • EVP_PKEY_new_raw_private_key and EVP_PKEY_new_raw_public_key for initialisation
  • EVP_PKEY_get_raw_private_key (which also may be of use for introducing a private? predicate method?) and EVP_PKEY_get_raw_public_key

https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_new.html

@rhenium
Copy link
Member Author

rhenium commented May 17, 2020

It sounds like a reasonable thing to have. A pull request is welcome!

santiagorodriguez96 added a commit to cedarcode/openssl-signature_algorithm that referenced this pull request Aug 10, 2020
This commit attempts to close #2.

Used the gem RubyCrypto/ed25519 as we still require ruby/openssl to
expose the required OpenSSL APIs in Ruby, expected to be released as 3.0
– See ruby/openssl#329.
Once OpenSSL Ruby v3.0 is released, we could change the implementation
in a way that users that use this gem alongside that version of OpenSSL
will use the API provided by OpenSSL, but users with an older version of
OpenSSL will still be provided with Ed25519 support with the use of
RubyCrypto/ed25519
grzuy pushed a commit to cedarcode/openssl-signature_algorithm that referenced this pull request Feb 10, 2021
This commit attempts to close #2.

Used the gem RubyCrypto/ed25519 as we still require ruby/openssl to
expose the required OpenSSL APIs in Ruby, expected to be released as 3.0
– See ruby/openssl#329.
Once OpenSSL Ruby v3.0 is released, we could change the implementation
in a way that users that use this gem alongside that version of OpenSSL
will use the API provided by OpenSSL, but users with an older version of
OpenSSL will still be provided with Ed25519 support with the use of
RubyCrypto/ed25519
grzuy pushed a commit to cedarcode/openssl-signature_algorithm that referenced this pull request Feb 10, 2021
This commit attempts to close #2.

Used the gem RubyCrypto/ed25519 as we still require ruby/openssl to
expose the required OpenSSL APIs in Ruby, expected to be released as 3.0
– See ruby/openssl#329.
Once OpenSSL Ruby v3.0 is released, we could change the implementation
in a way that users that use this gem alongside that version of OpenSSL
will use the API provided by OpenSSL, but users with an older version of
OpenSSL will still be provided with Ed25519 support with the use of
RubyCrypto/ed25519
grzuy pushed a commit to cedarcode/openssl-signature_algorithm that referenced this pull request Feb 10, 2021
This commit attempts to close #2.

Used the gem RubyCrypto/ed25519 as we still require ruby/openssl to
expose the required OpenSSL APIs in Ruby, expected to be released as 3.0
– See ruby/openssl#329.
Once OpenSSL Ruby v3.0 is released, we could change the implementation
in a way that users that use this gem alongside that version of OpenSSL
will use the API provided by OpenSSL, but users with an older version of
OpenSSL will still be provided with Ed25519 support with the use of
RubyCrypto/ed25519
grzuy pushed a commit to cedarcode/openssl-signature_algorithm that referenced this pull request Feb 10, 2021
This commit attempts to close #2.

Used the gem RubyCrypto/ed25519 as we still require ruby/openssl to
expose the required OpenSSL APIs in Ruby, expected to be released as 3.0
– See ruby/openssl#329.
Once OpenSSL Ruby v3.0 is released, we could change the implementation
in a way that users that use this gem alongside that version of OpenSSL
will use the API provided by OpenSSL, but users with an older version of
OpenSSL will still be provided with Ed25519 support with the use of
RubyCrypto/ed25519
@rhenium rhenium mentioned this pull request May 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Add suppot for X25519
2 participants