Generate a per data shared secret vs per session I have read about SSL that they persist the shared-secret for the entire session. However, someone in stackoverflow suggested a way of generating a shared secret for each data to send and then send that shared-secret encrypted by client's public key with the intended message/data. The client would then have to decrypt the shared-secret first for that message using its private key then decrypt the message by the decrypted shared-secret.

The opposite is true for client to server connection.

My question is what advantages this has over the persistent shared-secret per session?
A session key is used to share a symmetric key over asymmetric encryption. The reason behind this is that symmetric encryption algorithms are faster than asymmetric encryption algorithms, this is also called a hybrid cryptosystem, since it combines symmetric and asymmetric encryption.

The session key is generated randomly at the start of a session and is only valid for one session (hence the name "session key"). The use of session keys provides a feature called forward secrecy. In short, forward secrecy gives assurances that session keys will not be compromised even if the private key of the server is compromised.



Creating a new session key per message would (kind of) violate the use of hybrid cryptosystems, since you'd have to use asymmetric encryption all the time and not just for the first exchange. If your messages are of course very large it would make some sense to use this scheme but this is rarely the case.

It's in genral perfectly fine to use session keys instead of "per-message-session-keys".




  My question is what advantages this has over the persistent shared-secret per session?


It would theoretically provide forward secrecy per message instead of per session and there are indeed new implementations of such cryptographic schemes of what you're describing, like Efficient Ratcheting, which apparently provides session-per-message and is also very performant.