OpenSSL 1.1 (from github.com) Now combined ECDSA_METHOD and ECDH_METHOD into one method EC_KEY_METHOD.
in 1.0.2 there were ECDSA_get_ex_new_index, ECDSA_set_ex_data and ECDSA_get_ex_data with the EC_KEY and an idx as parameters And there where ECDH versions to: ECDH_get_ex_new_index, ECDH_set_ex_data and ECDH_get_ex_data. The best I can tell when this two methods were combined into a single EC_KEY_METHOD the ability to use CRYPTO_EX_INDEX_ to hang more then one piece of data off the key was lost in 1.1. This is the regression. In 1.0.1 and 1.1 RSA has: RSA_get_ex_new_index, RSA_set_ex_data, RSA_get_ex_data, RSA_set_app_data and RSA_get_app_data which all use the ls CRYPTO_EX_DATA ex_data; in the struct rsa_st. What would it take to add a CRYPTO_EX_DATA ex_data; in the struct ec_key_st with EC_KEY_get_ex_new_index, EC_KEY_set_ex_data, EC_KEY_get_ex_data, EC_KEY_set_app_data and EC_KEY_get_app_data? This would then allow for app_data, as well as allocated indexes, and present the same user interface as for other keys and retain the functionality of having an _ex_data for the key? ec_lcl.h Says: 274 * Basically a 'mixin' for extra data, but available for EC_GROUPs/EC_KEYs 275 * only (with visibility limited to 'package' level for now). We use the 276 * function pointers as index for retrieval; this obviates global 277 * ex_data-style index tables. The "only (with visibility limited to 'package' level for now)." is a problem. You could still keep the EC_EXTRA_DATA *method_data; for internal use if needed. -- Douglas E. Engert <[email protected]> _______________________________________________ openssl-bugs-mod mailing list [email protected] https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
