[Feature] Validate ECKey inputs and improve key handling

The ECKey class in the codebase handles secp256k1 key pairs. Start by locating the ECKey class and its constructors, focusing on private and public key validation methods. Review the keystore decryption path for temporary buffer cleanup. Write tests to verify input validation, equality symmetry, and that signing/recovery results remain unchanged for valid inputs. Check that modifications to returned arrays from getAddress() and getNodeId() do not affect cached values.

Summary

Validate keys when they enter ECKey, protect its cached values from accidental modification, and clear temporary private-key bytes after keystore decryption.

What is the problem?

ECKey represents a secp256k1 key pair and is used for operations such as transaction and witness signing. Several entry points handle invalid input or key state inconsistently:

• Invalid keys can fail too late. Private-key input is not consistently checked for size and numeric range before conversion or curve calculations. Public-key construction does not consistently enforce the supported encoding, curve, and point-validity rules.
• A private key can be paired with the wrong public key. For example, an object can contain private key A and public key B. Its address is derived from B, while signature generation uses A. sign() then tries to match the recovered public key to B; if no match is found, it throws. This can cause recoverable signing to fail after the object has already been constructed.
• Callers can change cached values. getAddress() and getNodeId() return their internal arrays. Modifying a returned array also changes what the object returns later.
• Equality can be asymmetric. A public-only key and a full key pair can represent the same public key, yet publicOnly.equals(fullKey) can be true while fullKey.equals(publicOnly) is false. This violates the symmetry required by Java's equals() contract.
• Some APIs promise unsupported behavior or expose secrets. Constructors accept arbitrary cryptographic providers, although signing expects Bouncy Castle keys. toStringWithPrivate() includes the private key in its output and can expose it if logged.
• Keystore errors and cleanup need a consistent boundary. ECDSA private-key validation failures during keystore decryption can escape as IllegalArgumentException instead of CipherException. The temporary array containing the decrypted private key is not explicitly cleared.

Expected behavior

Private-key byte arrays of 1–32 bytes remain supported when their value is valid. Also accept a valid 33-byte representation produced by BigInteger.toByteArray(): one leading 0x00 followed by a 32-byte magnitude whose high bit is set. That extra byte marks a positive number; it does not make the key invalid. Other encodings longer than 32 bytes are rejected.

The validation scope includes these helper entry points:

• publicKeyFromPrivate() validates the private scalar before deriving the public key.
• fromNodeId() requires a 64-byte X/Y representation and applies public-key validation through fromPublicOnly().
• signatureToKey() and recoverFromSignature() apply the strengthened public-key invariants when constructing a returned ECKey.

These requirements do not imply identical exception types for every malformed argument to every helper. In particular, the existing fromNodeId(null) behavior is not being standardized by this change.

Clearing the temporary array reduces how long that copy remains in memory. The returned key object still retains the private key needed for signing.

Compatibility and migration

This changes the public Java API. Downstream callers using removed methods must update their code and recompile. Changes to equality and returned-array sharing can also affect callers that still compile successfully.

Preserve the existing signing and recovery results for valid inputs. This work must not change transaction/block signature acceptance or TVM ecrecover behavior. Recovery helpers that return ECKey must enforce the strengthened public-key invariants, so malformed inputs may be rejected differently.

Configuration, consensus rules, and on-chain behavior remain unchanged. SM2 algorithm and key-validation changes are outside this issue; temporary-buffer cleanup applies to the shared keystore decryption path.

Validation

The acceptance criteria are:

• Input boundaries: Cover invalid scalar values, unsigned byte interpretation, oversized encodings, and valid 33-byte sign-padded keys. Reject malformed public-key encodings, invalid points, points on another curve supplied as ECPoint, and mismatched key pairs. Accept valid pairs and public-only construction. Exercise publicKeyFromPrivate() and fromNodeId() as well as constructors and import factories.
• Equality and cached values: Check equality in both directions between public-only and full keys, and between keys constructed from compressed and uncompressed encodings. Equal keys must have equal hash codes. Modifying returned address or node ID arrays must not change cached values.
• Signing and recovery: Verify signing and recovery results for valid inputs, including existing signature vectors. Verify that signatureToKey() and recoverFromSignature() reject recovered public points that violate the new invariants. Cover transaction/block signature acceptance and TVM ecrecover compatibility.
• Real invalid ECDSA keystores: Use a correct password, a valid MAC, and decryptable ciphertext whose plaintext is an invalid private scalar, such as zero or n. Confirm that failure comes from private-key validation and is wrapped in CipherException, rather than from password, MAC, or file errors.
• Temporary-buffer cleanup: Inspect the actual decrypted array after success and declared-address mismatch for both ECDSA and SM2, and after ECDSA private-key validation failure. Mocking or instrumentation may be used to observe that array, but must not replace all real invalid-key import coverage.
• Witness loading: Load a keystore containing a real invalid ECDSA private key through the witness initialization path. Confirm WITNESS_KEYSTORE_LOAD with CipherException and the original validation exception in the cause chain. Keep the existing WitnessInitializer production logic; an injected exception alone does not satisfy this end-to-end acceptance case.