CVSROOT: /cvs Module name: src Changes by: t...@cvs.openbsd.org 2023/09/24 01:58:31
Modified files: lib/libcrypto/ec: ec_ameth.c Log message: Refactor eckey_{param2type,type2param}() EC key parameters can be determined by an OID or they can be explicitly encoded. The confusingly named eckey_{param2type,type2param}() decode a new EC key from either form of parameters, or they encode a given key's parameters in the proper way. Signature and semantics are all over the place. It also features an inlined version of EC_KEY_new_by_curve_name(). This commit brings some order into this mess. Parameters are given by a pair (ptype, pval), where the ptype is either V_ASN1_OBJECT for OID encoding or V_ASN1_SEQUENCE for explicit encoding. Accordingly, the void pointer pval is an ASN1_OBJECT or an ASN1_STRING. These pairs are abstracted away in the X509_ALGOR object. The library decides whether a given EC key uses OID or explicit parameter encoding using the asn1_flag on the EC key's internal EC_GROUP, i.e., the object representing its curve. If this flag is set, the OID is determined by the nid returned by EC_GROUP_get_curve_name(). Add 'mutually inverse' pairs of functions eckey_{to,from}_params() which wrap eckey_{to,from}_object() and eckey_{to,from}_explicit_params(). This way the EC ameth pub and priv key de/encoding functions can transparently translate from/to an X509_ALGOR object. Of course, this is just an intermediate step and if you look closely you notice const weirdness (due to the fact that the carefully planned and executed const rampage missed the ECParameters API) and all sorts of other things that need to be fixed. Who would bat an eye lid? It wouldn't be visible amid all the twitching anyway. ok jsing