[thegeomaster]

Actually, when I said 'certificate', I actually only meant the public key, that's basically what you were describing. I rely on RSA-OAEP to detect if someone's been trying something funny (I've been told on StackExchnage Crypto that I can rely on it to tell me if a message I'm decrypting was encrypted using a non-matching public key). However, sending a client-generated symmetric key using the server's public one is not perfectly forward-secret: namely, if a server's key ever gets compromised, prior recorded communication can be trivially decrypted. I want to minimize the damage done if a server key is exposed.

Furthermore, a compromised pseudorandom number generator on the client can compromise the security of communication. To mitigate that, at least partly, both parties in my scheme contribute half of a session AES key.

[jwarkentin]

You're correct about the forward secrecy. That's what I get for commenting at 2am. I was thinking about TLS where there can be a frequently rotating asymmetric key pair. The symmetric key in TLS isn't used for PFS, only for performance. In practice those keys don't actually get rotated almost ever though.