ecc_sign_hash_ex + ecc_verify_hash_ex forces linking DER/ASN.1 code

[karel-m]

this is an issue related to the discussion in #438

The current all-in-one ecc_sign_hash_ex and ecc_verify_hash_ex forces anyone using ECDSA to link the whole ASN.1 stuff to their binary even if they are using just RFC 7518 or RFC 5656 (ssh2) signature format.

One possible approach is to split ecc_verify_hash_ex.c into:

• ecc_verify_hash_internal.c (only in tomcrypt_private.h)
• ecc_verify_hash.c (this is the troublemaker depending on ASN.1 stuff)
• ecc_sign_hash_rfc7518.c
• ecc_sign_hash_rfc5656.c
• ecc_sign_hash_eth27.c

Or another option:

• ecc_verify_hash_internal.c (only in tomcrypt_private.h)
• ecc_verify_hash.c (this is the troublemaker depending on ASN.1 stuff)
• ecc_verify_hash_ex.c (rfc7518 + rfc5656 + eth27)

[rmw42]

Hmm... How about splitting out the signature packing/unpacking (by format), defining an internal structure to pass around the (v,r,s) values, and making ecc_sign_hash, ecc_verify_hash and ecc_recover_key call the relevant encoder/decoder? That's got the additional advantage that the two signature-decoding calls share the same functions.

[rmw42]

Actually, I was a little confused by the "static linking" comment before... is the worry that someone will take the complete library and, although they don't use LTC_ECCSIG_ANSIX962, the linker won't be able to determine this and will drag in the DER/ASN.1 stuff as there's a reference in the multi-way if?

If that's the concern, and I'm not sure how big a use-case it would be, we probably want to look at passing a function pointer rather than an enum. Since there would be no reference in an app using LTC_ECCSIG_RFC7518 to the symbol of the DER encoder, it will be dropped (along with its transitive dependencies) by the linker.