Bumps [elliptic](https://github.com/indutny/elliptic) from 6.4.1 to 6.5.3.
- [Release notes](https://github.com/indutny/elliptic/releases)
- [Commits](indutny/elliptic@v6.4.1...v6.5.3)

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

This update checks to make sure that the public key passed in to
ECDH is a point that actually exists on the curve. This is
important to prevent a twist attack that can be used to reveal
the private key of a party in an ECDH operation over a number of
occurances.

For more details on the attack see this blog post:
https://github.com/christianlundkvist/blog/blob/master/2020_05_26_secp256k1_twist_attacks/secp256k1_twist_attacks.md

CVE: CVE-2020-28498

Fixes indutny#314.

According to FIPS 186-5, section 6.4.2 ECDSA Signature
Verification Algorithm, the hash of the message must be adjusted
based on the order n of the base point of the elliptic curve:

    If log2(n) ≥ hashlen, set E = H. Otherwise, set E equal to
    the leftmost log2(n) bits of H.

Unfortunately because elliptic converts messages to BN instances the
reported `byteLength()` for the message can be incorrect if the message
has 8 or more leading zero bits.

Here we fix it by:

1. Counting leading zeroes in hex strings provided as messages
2. Counting all array entries in Array-like (e.g. Buffer)
   messages
3. Providing an `msgBitLength` option to both `.sign`/`.verify` to let
   user override the behavior

Original PR: indutny#322
Credit: @Markus-MS