[RFC] change private key algorithm to RSA4096 or Ed25519

[susnux]

The private key is a 2048 RSA key.

The NIST deprecates RSA <= 2048 and its not trusted anymore begin of 2030.
So the recommendation is either:

• Use RSA 4096
• Use a different trusted algorithm, a good candidate would be Ed25519 (support in clients)

see "Table 3. Approval status of algorithms used for digital signature generation"
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar3.ipd.pdf

[susnux]

cc @artonge @tobiasKaminsky

[susnux]

RSA 4096: Not much to change in logic but increases the file size a lot!
ed25519: Reduces the file size but requires new logic.

Currently we use x509 with RSA to sign but also to encrypt (this is not really recommended to do so with the same key!).
With ed25519 we only have a key for signature, so for encryption (of the metadata key) we would need some key exchange.

We could do similar as Signal and use a combination of static and ephemeral DH. Similar as described in NIST SP800-56a (and some of the CMS RFCs) it would look like this:

1. Have a static key (the ed25519 private / public key for signature to proof the identity)
2. Have a ephemeral key (created on the fly - e.g. x25519)
3. Do a DH with the private key of the ephemeral and the public key of the receiver
4. Run a key derivation function on that
5. use the result to wrap the AES key
6. Set public ephemeral and wrapped key in the metadata

To encrypt this now a user would use their private static key (the ed25519 key) as well as the public ephemeral key to run the DH and get the same shared secret, they now run the KDF on it to get the key for the wrapped AES key.
The KDF is only for the sake of using the same ephemeral key for multiple users.