-
Notifications
You must be signed in to change notification settings - Fork 172
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
rework ECIES to avoid ECDH_KDF_X9_62 #252
Comments
I appreciate the situation. I believe that we need ruby-openssl internals in order to implement this elsewhere. Would it a patching making it possible to do that be acceptable? (Upstreaming to OpenSSL may take years) |
I doubt if there is a portable way to use the internals/symbols of Ruby/OpenSSL from another extension library. It might work on Linux (as Ruby uses RTLD_GLOBAL flag when loading extension libraries with dlopen(3)), but I'm not sure about other platforms. Another concern is mixed versions of OpenSSL. It's possible that Ruby/OpenSSL and openssl-pkey-ec-ies link to incompatible versions of libcrypto, and in that case, sharing the EVP_PKEY object would result in silent misbehavior or crash. I wonder if it is really necessary to use them to implement it. To me, it seems like the best option is to serialize a key into DER format and let other library re-construct EVP_PKEY from it. |
openssl/openssl@9453b19 decprecates ECDH_KDF_X9_62 which is used in contributed code for ECIES, so this needs to be fixed.
The text was updated successfully, but these errors were encountered: