Il modo più efficiente di chat crittografato

6

Sto creando un server in cui le persone possono venire a parlare tra loro. Lo faccio principalmente per un progetto divertente, ecco la mia domanda.

Uso RSA per crittografia / decrittografia, quindi solo i client sapranno cosa viene detto. Non voglio che il server gestisca alcun testo decrittografato.

La mia domanda è, qual è il modo più efficace per farlo? Dalla mia comprensione, dovrò dare a ciascuno la chiave pubblica di ciascuno. E una volta che un cliente dice qualcosa, dovrà crittografarlo individualmente per ciascuna persona usando la rispettiva chiave pubblica, non è così? Per me sembra estremamente inefficiente.

C'è un modo migliore per farlo?

Grazie

    
posta Austin 22.03.2012 - 22:20
fonte

5 risposte

10

La crittografia a chiave pubblica può, in questo caso, essere utilizzata per facilitare la configurazione di un canale sicuro in cui trasmettere una chiave simmetrica. Una volta impostato il canale sicuro, non è necessario continuare a crittografare e decrittografare utilizzando le chiavi pubbliche / private. Invece, genera una chiave simmetrica e la usa per crittografare il traffico. Devi solo distribuire la chiave simmetrica una volta sola e il traffico deve essere crittografato solo con questa chiave piuttosto che con ogni chiave pubblica. La sfida principale è quando o se la chiave simmetrica deve essere rigenerata, revocata, ecc.

    
risposta data 22.03.2012 - 22:34
fonte
4

Il modo più efficace è quello di fare in modo che i client scambino le loro chiavi pubbliche RSA e quindi generare "chiavi di sessione" casuali da utilizzare per conversazioni tra loro. Ciò evita la crittografia multipla e non richiede che il server sia in grado di decrittografare i dati.

Quindi, se Jack sta per parlare con Jill e Seth, Jack genera una chiave di crittografia casuale da usare per parlare con Jill e Seth. Jack crittografa questa chiave con la chiave pubblica di Jill e la chiave pubblica di Seth e invia le chiavi crittografate a Jill e Set. Il server non può decrittografarli. Ora Jill e Set conoscono la chiave che Jack userà. Jack può ora crittografare i messaggi una sola volta con questa chiave e fare in modo che il server li trasmetta a Jill e Seth. Jill e Seth possono decodificare i dati con la chiave di sessione. Il server non può mai decodificare i dati.

Ciò significa che i client dovranno mantenere le tabelle delle chiavi di sessione e generare nuove chiavi per qualsiasi combinazione distinta di clienti con cui potrebbero voler parlare.

Tieni presente che con tutti questi schemi, a meno che non utilizzi i certificati, sono vulnerabili a un attacco in cui il server sostituisce semplicemente le proprie chiavi per le chiavi del client e decodifica e re-crittografa tutto il traffico, all'insaputa dei clienti.

    
risposta data 23.03.2012 - 04:08
fonte
3

Esegui un server jabber e digli di usare pidgin con OTR

    
risposta data 22.03.2012 - 22:31
fonte
1

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.

    
risposta data 25.03.2012 - 22:29
fonte
0

Che ne dici di passare da RSA a una variante dello scambio di chiavi Diffie-Hellman? Scegli un primo (p) e base (g) condivisi tra tutti i partecipanti, quindi ciascun partecipante sceglie la propria chiave privata (a) e pubblica una chiave pubblica (A = G ^ a mod p) derivata da esso. Quindi, per comunicare con un altro partecipante, solleva semplicemente la chiave pubblica dell'altro utente sulla propria chiave privata (mod p), e otterrà un segreto condiviso che quei due partecipanti possono utilizzare per crittografare (con alcuni messaggi di cifratura simmetrica appropriati) tra di loro.

Ciò richiede ancora che tutti conoscano le chiavi pubbliche di tutti gli altri e che un messaggio con più destinatari sia crittografato e inviato separatamente per ciascun destinatario; ma ti consente di saltare il passaggio in cui ogni coppia di partecipanti deve negoziare una chiave di sessione condivisa.

P.S. questo metodo ha alcune limitazioni di sicurezza; ad esempio, se la chiave privata di un utente viene mai esposta, tutti i loro messaggi passati sono banalmente decifrabili.

    
risposta data 23.03.2012 - 05:41
fonte

Leggi altre domande sui tag