Il problema principale con il bug che stai descrivendo è che 0 appare più frequentemente in certi bit del flusso di output. L'attacco più comune è che un utente malintenzionato può creare una vittima che crea milioni di connessioni a un server, mentre osserva il traffico di rete.
Per fare un esempio, cambiamo "bit" in "byte", aumentiamo le possibilità e vediamo cosa succede.
Diciamo:
- Ho un cookie segreto con il valore 'a';
- Ho qualche codice stream kick-ass che emette byte casuali;
- un utente malintenzionato può farmi eseguire milioni di connessioni a un server;
- su ogni richiesta, il primo carattere per il mio testo in chiaro è il mio cookie ('a') seguito da un altro testo in chiaro;
la crittografia - è una xor di testo in chiaro con i byte generati dallo stream (come con RC4);
- quell'attaccante può monitorare il mio traffico di rete.
Con ogni nuova connessione che faccio al server, viene generato un nuovo flusso casuale. Ciò significa che il mio cookie ('a') verrà xo'ed con un byte casuale ogni volta. Poiché ciò accade in modo uniforme a caso, il nostro aggressore non può dedurre informazioni sul cookie, in quanto la possibilità di 'a' xor qualsiasi personaggio è 1/256.
Introduciamo ora un difetto nel nostro codice stream. Per il primo byte, ha la tendenza a produrre 'b' con una probabilità del 10%, e ha una probabilità del 90% di produrre qualsiasi altro carattere. Ora, se l'autore dell'attacco mi ha creato 10 connessioni al server, c'è una possibilità 1/10 che 'b' xor 'a' appaia come il primo byte del testo cifrato, invece del precedente 1/256. Quindi, dopo 100 connessioni, "b" xor "a" dovrebbe essere apparso circa 10 volte, ecc. Ecc.
Ricorda che ci sono anche altri tipi di attacchi su RC4. Il riassunto degli attacchi su Wikipedia è in realtà molto bello:
link