Ci sono dei difetti in questo semplice scambio di chiavi?

Hai inviato K xor R . Il tuo partner restituisce R . L'attaccante vede entrambi i valori; può quindi calcolare (K xor R) xor R (lo XOR dei due valori che ha visto) e R cancel out: il risultato è K . Così debole. Terminali.

Se vuoi qualcosa di più robusto, avrai bisogno di uno strumento extra, ad es. una funzione di hash crittografica come SHA-256. Ad esempio, invii ancora K xor R e il tuo partner restituisce SHA-256(R) . Questo funziona a condizione che R sia stato scelto in modo casuale e uniforme . Pensaci; il punto di tali esercizi è quello di ottenere una comprensione intuitiva di ciò che sta accadendo. Qui, il tuo partner sta mostrando la sua conoscenza di R inviando SHA-256(R) , ma senza rivelare nulla su R (principalmente perché SHA-256 è resistente a preimmagini - sì, so che sto prendendo un po 'di scorciatoia retorica qui). Nota, tuttavia, che questo schema è vulnerabile agli attacchi al dizionario nel caso in cui la chiave K sia una password (ad es. un set che è abbastanza piccolo da essere esaustivamente attraversato).

Sono possibili altre varianti con una funzione hash; saranno tutti deboli per quanto riguarda gli attacchi al dizionario, tuttavia (è necessario PAKE per risolvere il problema, e questo significa che molto più matematica).

Il tuo altro scenario è ciò che fondamentalmente è una cifra streaming . Può essere strong, se fatto correttamente: usa un algoritmo robusto, un "seme" abbastanza grande (che è, in realtà, una chiave), e mai mai riusare lo stesso flusso per due messaggi distinti.

Completamente imperfetto. Un utente malintenzionato può semplicemente XOR la sfida (il "flusso di bit casuale") con la risposta (la "stringa casuale originale") e quindi conoscere la chiave segreta.

L'estensione è una forma di codifica stream. Affinché un cifrario di flusso sia sicuro, è fondamentale che lo stesso flusso non venga ripetuto due volte (cioè che venga utilizzato un diverso vettore di inizializzazione). In ogni caso, se provi a utilizzare un codice di streaming per l'autenticazione come proposto, sarai soggetto a un attacco man-in-the-middle.

Sembra che quello che stai chiedendo sia uno scambio del genere:

1. Alice genera testo in chiaro P.
2. Alice XORs P con chiave condivisa K per ottenere "ciphertext" C.
3. Alice invia C (P XOR K) a Bob.
4. Bob calcola C XOR K per ottenere testo in chiaro P
5. Bob invia P ad Alice.

Dove si scompone sono i passi 3.5, 5.5 e 6:

1. Alice genera testo in chiaro P.
2. Alice XORs P con chiave condivisa K per ottenere "ciphertext" C.
3. Alice invia C a Bob. 3.5 Eve intercetta e memorizza C
4. Bob calcola C XOR K per ottenere testo in chiaro P
5. Bob invia P ad Alice. 5.5 Eve intercetta e memorizza P.

6. Eve calcola C XOR P e recupera la chiave K.

Esponendo esplicitamente un testo in chiaro per il quale il testo cifrato esiste fondamentalmente fa il lavoro di un utente malintenzionato per lei, in particolare nel modulo di "stream cipher" di base che hai descritto. Vedi Attacco di testo in chiaro noto .

La seconda opzione, quella dei PRNG sincronizzati, è altrettanto problematica. In che modo Alice comunica in sicurezza il seme per il PRNG a Bob? Non può, a meno che non condividano già una chiave.

Infine, ricorda che una funzione di hash è una primitiva criptografica specifica, non un riferimento al testo cifrato. Un messaggio cifrato è "crittografato", non "hash". Non essere pedante qui, semplicemente cercando di evitare la penna rossa del professore.