chore: migrate to @noble/curves and ecies/js

[alexandre-abrioux]

Description of the changes

• use @noble/curves for signature instead of secp256k1
• use ecies/js for encryption (which uses @noble/curves under the hood) instead of eccrypto's fork
• @noble/curves is an audited library, and now the industry standard used by ethers and viem

What's missing

For the moment we can't decrypt old data because ecies/js uses AES-256-GCM while eccrypto uses AES-256-CBC, see ecies/js#747

[MantisClone]

I thought we were using GCM also, according to the old encryption audit. Is the CBC code actually used for anything?

https://request.network/en/2020/07/07/request-encryption-audit-completed-by-cure53/

Action: Use the authenticated encryption algorithm aes-256-gcm instead of aes-256-cbc and remove the hash.
Status: fixed – Commit 1 & Commit 2

[alexandre-abrioux]

@MantisClone There are two encryption stages. First, the request is encrypted using AES-256-GCM (symmetric encryption). The generated encryption key is later referred to as the channel key. This channel key is then encrypted with each shareholder's public key using ECIES (asymmetric encryption). This two-stage encryption scheme aims to reduce the size of the encrypted data; otherwise, we would have to encrypt the whole request as many times as there are shareholders. Instead, we encrypt the channel key multiple times, which is a minimal overhead—more details over here.

This PR only concentrates on the ECIES part. I didn't know this before, but ECIES also uses AES under the hood, and eccrypto uses AES-256-CBC. AEC "cbc" mode is not recommended because it has no "aead" tag, so I'm trying to find a way to upgrade while keeping compatibility for previously encrypted requests.

[MantisClone]

@alexandre-abrioux now that ecies/js added support for AES-256-CBC in ecies/js#748, do you still think that it's possible to migrate to @noble/curves and ecies/js?

Are we blocked by the fact that ecies/js does not support the SHA512 key derivation function?

ecies/js#747 (comment):

Another point is that eccrypto is using sha512 (specifically the first 32 bytes of SHA512(ECDH(ephermeralPublicKey, publicKey)) to derive the shared key (https://github.com/bitchan/eccrypto/blob/master/index.js#L219 or https://github.com/torusresearch/eccrypto/blob/master/src/index.ts#L248) but we are using HDKF-SHA256, this also makes it incompatible.

ecies/js#747 (comment):

Since we don't have a plan to support SHA512 as a key derivation function, you may need to think about a migration strategy.

[alexandre-abrioux]

@MantisClone I still think it's possible. We will probably have to implement our own decryption fallback class for supporting old requests with SHA512, but I haven't found time yet to look deeper.