Clarify cryptographic magic numbers

[tarakby]

• declare new cryptographic constants related to sha3 and the supported elliptic curves.
• use the cryptographic constants to replace magic numbers

The purpose is:

• clarify the intention of using magic numbers (especially when the same constant 32 is used multiple times, but it has a different meaning depending on the context)
• make the code base more robust if more hashing algorithms or elliptic curves are used in the future

[tarakby]

In theory, it's enough to only check messageDigestSize < CURVE_ORDER_SIZE to error. messageDigestSize >= CURVE_ORDER_SIZE is the allowed ECDSA requirement, but that also depends on how bip32_derive_ecdsa_sign_hash_256 is implemented internally. In Flow, the supported hashing output was forced to match the curve order size, hence the check for equality here.

On a slightly different note, if bip32_derive_ecdsa_sign_hash_256 checks for the curve/digest compatibility internally, then this check can be reduced to checking that hashing has worked correctly, as in messageDigestSize is equal to CX_SHA256_SIZE or CX_SHA3_256_SIZE.

[tarakby]

After checking the doc of bip32_derive_ecdsa_sign_hash_256, I see that there is no check of compatibility of the group order/hash length!

The caller of bip32_derive_ecdsa_sign_hash_256 needs to make the check in this case. My preference in this case is to:

1. explicitly check that the hashing worked as expected, as in the digest size is equal to the expected hash output constant
2. explicitly check that the digest size is at least the curve group order (not checked by the Ledger SDK).

If we skip (2), the code may integrate for instance sha224 and use it to sign without an error. The security of the curve (128 bits) is silently reduced in this case to the security of the hash (112 bits), which is not good. Let me know if you have questions to clarify

[tarakby]

check added 1e5abf8