Ytukyg

I am thinking of security in an encrypted app, and was wondering if it would be feasible and if it would in any way add any security to the app if the keypair created for a user could change with each message sent, so every message is encrypted with a different private key? I understand there would a tremendous need for syncing between user's keys, but this is just a hypothesis I am thinking of.
thanks

Of course, you can use only one key for each message and we called this forward security. To achieve this you need to use a key exchange protocol as Diffie-Hellman Key exchange protocol. This will increase communication, but security is not cheap and it is used in TLS 1.3

With forward secrecy, even successful attacks in of the parties, the attacker can at most access the current key if there is an encryption operation. The previous keys are not stored once the message was sent so there is no key compromise.

It is well possible, but feasibility may depend on how you use your keys.

As already answered - ephemeral (one-time temporary) keys are used in TLS for achieving forward-secrecy in the key-excange to derive symmetric session encryption keys. So it's not really a new keypair for every message, but rather for establishig a session. Generating a new good key may needs some performance and time.

Even so your app needs to maintain a long-time key to sign the ephemeral public key to ensure integrity so the recceiving party can be sure the ephemeral keys are really from party it claims to be. That is as well part of te TLS key exchange.

If you are not using direct (session) communication, but sending the messages asynchronously, I see no point to generate a new keypair. You can just create a new random encryption key (assuming hybrid encryption). To ensure integrity the message needs to be signed by the sender as well, so a long-lived persistent key is necessary.

For encryption, the message receiver could generate a new public/private key pair and send the public key to the message sender. The sender could then encrypt using this public key. This decreases the risk due to a compromised key pair. You lose just one message if the ephemeral key is compromised instead of all of them if a long-term key is compromised.

However, encrypting alone does not provide security. You also need to authenticate the sender and receiver and provide integrity.

For authentication, you either need a large set of pre-generated keys that are mapped to particular identities in a secure way (e.g., certificate signed by trusted certificate authority, as in PKI), or some other way to prove who generated each key pair. This is the tremendous syncing effort you mention.

The PKI method introduces many ways to authenticate as a user due to their many keys, so it actually reduces security by increasing the attack surface. If you do things right, the bigger attack surface is balanced by the fact that an attack on an ephemeral key limits damage to a single message. However, to enforce this limit, you have to have a secure, public place where a list of valid/used keys is maintained in real-time. Otherwise the single-use keys could be re-used.

If you don't pre-generate keys, you need a long-term public/private key pair to establish ownership of the temporary pair through a method such as a signature. You may reduce the risk of compromise to the long-term key pair by using it just for signing ephemeral key pairs. However, this just reduces one type of risk associated with the long-term key pair. You still have risks associated with generation, distribution, storage, and binding the long-term key pair to a particular user, and the ephemeral key pairs are dependent on the long-term key pair for their security.

For integrity, you can use digital signatures. Many digital signature methods are similar to authentication methods, where a private key operation is the key security operation.

Bottom line: you may be able to increase security by using ephemeral key pairs for each message, but performance will be impacted, you have to be careful about implementation, and the security benefits are minimal.