Alice no tendría que enviar el valor de hash a través del cable; en su lugar, Bob debe volver a calcular el valor de hash de su lado, según los valores que recibió, y luego comparar el valor de hash con una fuente autorizada (la llamada telefónica).
Esto funciona. Es fácil ver si lo consideramos en dos pasos:
-
En presencia de Diffie-Hellman, un ataque Man-in-the-Middle requiere que el atacante ponga su propia clave pública DH en lugar de eso de Alice o Bob (un MitM es una doble personificación, por lo que el atacante debe hacer la sustitución dos veces). Para Bob es suficiente "asegurarse" de que lo que recibió es, de hecho, lo que Alice envió para detectar dicha sustitución. Bob puede llamar a Alice y deletrear, a través de la línea telefónica, la clave pública DH que recibió (que incluye los parámetros de grupo DH p y g , y la clave pública DH real) de Alice ga mod p).
-
En lugar de deletrear los tres grandes enteros (que serían más de 1500 caracteres hexadecimales), Alice y Bob simplemente pueden usar el hash de los valores. Siempre que la función de hash sea resistente a la preimagen de segundo , verificar el valor de hash es tan bueno como verificar la clave pública completa.
Este método es exactamente lo que sucede con SSH . La primera vez que te conectas a un servidor SSH desconocido hasta ahora, obtienes algo como esto:
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)?
En este punto, se supone que debe llamar al administrador del sistema de destino para verificar el valor de hash (o compararlo con cualquier otra fuente autorizada, que depende del contexto). Esto es exactamente lo que sugieres. El cliente SSH luego registra la clave pública del servidor, de modo que no se necesita ninguna pregunta para las conexiones posteriores.