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

Loaded EC Private key does not match what was originally input #189

Closed
vikramraja1995 opened this issue Sep 25, 2019 · 3 comments
Closed

Comments

@vikramraja1995
Copy link

Hey there,

I am trying to load a private ecdsa key (in pem format) to be used for signing. I was having several issues with my signed tokens, so I did some debugging. Here is a code snippet (using a throwaway private key):

require 'openssl'

key_string = "-----BEGIN EC PRIVATE KEY-----
MHcCAQEEINOov9ihnWNoJd5ER6kj0/b5ZvZkBycx8wxNA7N9e4FpoAoGCCqGSM49
AwEHoUQDQgAEB3tH41EaU+eT+R3GtPvLDR8GucWLQlouTX1lXFmEnOoeCITi/w4E
VUx6NAn7/Xve7pAOAPSt4fO+FLhPPTBmsQ==
-----END EC PRIVATE KEY-----"

original_key = OpenSSL::PKey::EC.new(key_string)
puts original_key.to_pem

Here, you would expect the output from original_key.to_pem to match key_string. This is the case in Ruby 2.3.0, but in JRuby 1.7.27 (and JRuby 9.2.7.0), this is what my output looks like:

-----BEGIN EC PRIVATE KEY-----
MCUCAQEEINOov9ihnWNoJd5ER6kj0/b5ZvZkBycx8wxNA7N9e4Fp
-----END EC PRIVATE KEY-----

I have been trying to figure out why this is happening for a while now, and I am stumped. Does anyone know what's going on, and how I can get it to work properly.

Thanks!

@kares
Copy link
Member

kares commented Sep 25, 2019

PKey::EC support isn't 'complete' - we could use a helping hand figuring this one out.
not sure what's going on here but instead of looking at pem outputs would try figuring out the parameters, unfortunately PKey::EC#to_text isn't implemented - could be a good starting point.

@vikramraja1995
Copy link
Author

vikramraja1995 commented Sep 26, 2019

Hmm okay, will continue debugging and see what I can come up with, thanks!

@kares
Copy link
Member

kares commented Apr 11, 2024

closing this one in favor of: #257 (while this was reported earlier the later is more up-to-date).

@kares kares closed this as completed Apr 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants