jruby-openssl icon indicating copy to clipboard operation
jruby-openssl copied to clipboard

`OpenSSL::PKey::EC#to_pem` or `.new` appears to change EC keys created by CRuby's openssl

Open postmodern opened this issue 3 years ago • 1 comments

Steps To Reproduce

CRuby

require 'openssl'
ec = OpenSSL::PKey::EC.generate('prime256v1')
ec.generate_key
pem = ec.to_pem
# => "-----BEGIN EC PRIVATE KEY-----\nMHcCAQEEIFGFA23QpFp3ZgFniwlICLAjIc3Zxrt6Dw5ElfETPkoxoAoGCCqGSM49\nAwEHoUQDQgAEfAWhRpiAKNuIlXG54M/vSWN1kam9/1SKp8yeoHBN0YhpGDrh+JC0\ngwPqy/cOYhzzKUleb4+bjvImBkTB/1jvlQ==\n-----END EC PRIVATE KEY-----\n"

JRuby

require 'openssl'
pem = "-----BEGIN EC PRIVATE KEY-----\nMHcCAQEEIFGFA23QpFp3ZgFniwlICLAjIc3Zxrt6Dw5ElfETPkoxoAoGCCqGSM49\nAwEHoUQDQgAEfAWhRpiAKNuIlXG54M/vSWN1kam9/1SKp8yeoHBN0YhpGDrh+JC0\ngwPqy/cOYhzzKUleb4+bjvImBkTB/1jvlQ==\n-----END EC PRIVATE KEY-----\n"
ec = OpenSSL::PKey::EC.new(pem)
pem2 = ec.to_pem

Expected Result

# => "-----BEGIN EC PRIVATE KEY-----\nMHcCAQEEIFGFA23QpFp3ZgFniwlICLAjIc3Zxrt6Dw5ElfETPkoxoAoGCCqGSM49\nAwEHoUQDQgAEfAWhRpiAKNuIlXG54M/vSWN1kam9/1SKp8yeoHBN0YhpGDrh+JC0\ngwPqy/cOYhzzKUleb4+bjvImBkTB/1jvlQ==\n-----END EC PRIVATE KEY-----\n"

Actual Result

# => "-----BEGIN EC PRIVATE KEY-----\nMCUCAQEEIFGFA23QpFp3ZgFniwlICLAjIc3Zxrt6Dw5ElfETPkox\n-----END EC PRIVATE KEY-----\n"

The PEM exported by jruby-openssl appears to be much shorter than the PEM exported by CRuby's openssl.

Versions

  • jruby 9.3.2.0 (2.6.8) 2021-12-01 0b8223f905 OpenJDK 64-Bit Server VM 11.0.15+10 on 11.0.15+10 +jit [linux-x86_64]
  • jruby-openssl (0.12.2 java, default: 0.11.0 java)

postmodern avatar May 10 '22 07:05 postmodern

not sure about whether the format is expected to be "byte level" same between C-OpenSSL and Java's Bouncy-Castle... as long as one is able to parse other's PEM encoded format and end up with the same object.

The PEM exported by jruby-openssl appears to be much shorter than the PEM exported by CRuby's openssl.

was due https://github.com/jruby/jruby-openssl/commit/401749e67f9e1fa1d56fa6772870118a2aeee981 which explicitly skipped the public part when encoding the private key

kares avatar Apr 11 '24 11:04 kares