Add ECIES encryption module for sr25519 keys

[hitchhooker]

Summary

• Adds ECIES (Elliptic Curve Integrated Encryption Scheme) over Ristretto255
• Uses ChaCha20-Poly1305 for authenticated encryption and Merlin transcripts for key derivation
• New ecies feature flag with encrypt / decrypt public API
• Wire format: [version: 1B] [ephemeral_pk: 32B] [nonce: 12B] [ciphertext + tag: N+16B] (61 bytes overhead)

Test plan

• Unit tests: round-trip, deterministic encryption, empty plaintext, wrong context, truncated ciphertext, bad version, tampered ciphertext, large plaintext
• Review by maintainers

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/dystopia-awaits-lets-encrypt/17345/1

[burdges]

We’ve had the schnorrkel::aead module forever, but I never developed it much or encouraged its usage for several reasons, many of which fall under: Do not mix encryption and signing keys!

There are three-ish big categories under that banner: (1) legal scenarios in different countries, (2) user key management, lifetime and rotation, and (3) security assurances. I'll remark on (3) first:

• provable security: We almost never write security proofs for both encryption and signing done together.
• practical security: We already mix too many different protocols in the blockchain world. And soft key derivations wind up usually being an especially bad idea. Also schnorrkel is a good crate for doing OPRFs, a cheap limited alternative to blind signatures, see PrivacyPass, but OPRFs create a decryption oracle.

Anyways, it's good this derives a new secret key, which avoids (3) but not (2) and not (1) in practice, and also.. why?

I'd think schnorrkel keys would usually live on ledger, vault, etc devices, so how could you get the secret from the device to the decryption device? Or would you want decryption in vault? Or would untrusted payloads there be a larger vulnerability?

We could simply define export age secret key functions, which both take the schnorrkel secret key and a derivation path, and outputs a [u8; 32] or age's string version. After which, everything continues using age itself. If we worked from the MiniSecretKey then we could derive age's PQ scheme (Xwing?) except rage lacks support so far.

Also, there is a forth category here: We've added many more features to encryption, like all the forward secure ratchets. All this depends upon a full ecosystem, but maybe one should not push everything here.

Again if we need something then that's a different matter, but what is the reasoning here?

Also: Is this vibe coded? At least some seems non-idiomatic, although my idea of idiomatic maybe flawed there.