[openssl-dev] [openssl.org #4225] OpenSSL 1.1-pre2 EC_KEY_ex_data regression of functionality from 1.0.2 to 1.1

[deengert@gmail.com via RT]

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  <DEEngert at gmail.com>
  

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod