Technically, encryption always have a performance impact, in todays machines it's negligible. For best outcome, you could perform the following:

• Get the RSA public key of the server side.
• Create a symmetric AES key, encrypt it with the RSA public key and send it to the server; the server decrypts it and you have a 'pre shared secret' then.
• Encrypt your data with the symmetric key, and decrypt it on the server.

Not to re-invent the wheel, but if you have browsers such as Opera, Chrome or FF, you could use Datagram Transport Layer Security or ZRTP.

In essence, WebRTC creates a new communication channel, and encryption is up to you. What you encrypt (offer, answer, ...) is basically based on how sensitive the information is, but once a channel is setup (i.e: the AES key is shared), you may as well encrypt everything; again - you'll have a minimal performance impact on modern systems.

Technically, encryption always have a performance impact, in todays machines it's negligible. For best outcome, you could perform the following:

• Get the RSA public key of the server side.
• Create a symmetric AES key, encrypt it with the RSA public key and send it to the server; the server decrypts it and you have a 'pre shared secret' then.
• Encrypt your data with the symmetric key, and decrypt it on the server.

Not to re-invent the wheel, but if you have browsers such as Opera, Chrome or FF, you could use Datagram Transport Layer Security or ZRTP.

In essence, WebRTC creates a new communication channel, and encryption is up to you. What you encrypt (offer, answer, ...) is basically based on how sensitive the information is, but once a channel is setup (i.e: the AES key is shared), you may as well encrypt everything; again - you'll have a minimal performance impact on modern systems.