Alice non dovrebbe inviare il valore hash sul filo; invece, Bob deve ricalcolare il valore dell'hash sul suo lato, in base ai valori che ha ricevuto, quindi confrontare il valore hash con una fonte autorevole (la telefonata).
Questo funziona. È facile vedere se lo consideriamo in due passaggi:
-
In presenza di Diffie-Hellman, un attacco Man-in-the-Middle richiede che l'attaccante metta la propria chiave pubblica DH al posto di quella di Alice o Bob (un MitM è una doppia impersonificazione, quindi l'attaccante deve effettuare la sostituzione due volte). È sufficiente che Bob "si assicuri" che ciò che ha ricevuto è effettivamente ciò che Alice ha inviato per rilevare una tale sostituzione. Bob può telefonare ad Alice e comporre, oltre la linea telefonica, la chiave pubblica DH ricevuta (che include i parametri del gruppo DH p e g e la vera chiave pubblica DH da Alice g a mod p ).
-
Invece di sillabare i tre grandi numeri interi (che sarebbero più di 1500 caratteri esadecimali), Alice e Bob possono semplicemente usare l'hash dei valori. Fintanto che la funzione di hash è seconda preimage resistente , la verifica del valore hash equivale a verificare la chiave pubblica completa.
Questo metodo è esattamente che cosa succede con SSH . La prima volta che ti connetti a un server SSH finora sconosciuto, ottieni qualcosa di simile a questo:
The authenticity of host 'foo.example.com (42.17.131.8)' can't be established.
RSA key fingerprint is 45:77:d0:f0:b1:76:ce:cf:14:60:e4:89:54:20:c5:3d.
Are you sure you want to continue connecting (yes/no)?
A questo punto, si dovrebbe telefonare al sysadmin del server desiderato per verificare il valore hash (o controllarlo con qualche altra fonte autorevole, che dipende dal contesto). Questo è esattamente ciò che suggerisci. Il client SSH registra quindi la chiave pubblica dal server, in modo che nessuna domanda di questo tipo sia necessaria per le connessioni successive.