Generalmente, l'handshake di chat crittografato in modo asimmetrico inizia con lo scambio di chiavi pubbliche. Idealmente dovresti avere un meccanismo per legare la chiave al proprietario (pensa ai certificati SSL e alle firme) per prevenire gli attacchi MITM. È più semplice utilizzare un sistema esistente (come certificati SSL o chiavi PGP) per evitare di reinventare la ruota. Quali firme deciderai di affidare dipende dal tipo di modello di fiducia che ti interessa mantenere. Un buon punto di partenza è determinare esattamente cosa costituisce l'identità di un utente e quale tipo di accesso un utente malintenzionato dovrebbe avere per rubare tale identità.
Quindi, naturalmente, usa RSA per crittografare le chiavi di sessione ad-hoc utilizzate per la crittografia simmetrica come AES, Twofish, RC4, ecc. L'efficienza sta nel fatto che stai usando solo RSA per stabilire l'identità della festa stai comunicando, e poi passi immediatamente a qualcosa di più efficiente.
D'altra parte
Se stai parlando di utilizzare RSA in un mezzo di trasmissione (pensa IRC piuttosto che Jabber), allora sì, questo è terribilmente inefficiente. La crittografia è necessariamente point-to-point, piuttosto che point-to-multipoint. Ogni stream è crittografato individualmente. Quindi il numero di flussi crittografati in streaming che un dato client produce è uguale al numero di destinazioni a cui viene inviato il messaggio. Ognuno si installa indipendentemente dagli altri. Questo è precisamente il motivo per cui sistemi come IRC non criptano end-to-end tra diversi client. L'overhead sarebbe troppo. Al massimo, crittografano da client a server, consentendo a ciascun utente di disporre di un singolo canale protetto, con il server che gestisce la distribuzione dei messaggi.
Questo non vuol dire che ciò che stai facendo è impossibile o sconsiderato. Se vuoi costruirlo, vai avanti.