El segundo artículo (Safaka et al ) describe un protocolo que se basa en un protocolo similar al protocolo Cachin-Maurer que describo al final de esta respuesta . La premisa es que hay un canal de comunicación de transmisión no confiable entre las partes involucradas, de modo que cuando una parte emite una lista de "paquetes", todas las demás solo ven algunos del Paquetes, y no todos ellos ven los mismos paquetes. Así que Alice y Bob, que desean establecer un secreto compartido, solo tienen que emitir muchos paquetes, registrar lo que reciben y luego decirse qué paquete recibieron (se hace referencia a los paquetes con una ID convencional). ). Con alta probabilidad, el atacante no pudo ver todos los paquetes que tanto Alice como Bob registraron, por lo que la concatenación de todos los paquetes, adecuadamente hash, es una buena clave compartida.
En el protocolo Cachin-Maurer, la transmisión es de una fuente aleatoria de alto ancho de banda, y la falta de fiabilidad de la recepción se debe a la imposibilidad de grabar todos los datos, debido a su gran tamaño. En el protocolo de Safaka, se supone que el medio de transporte no es confiable, lo cual es un poco optimista porque el atacante puede invertir en una antena buena , algo mucho mejor para captar ondas de radio que los adaptadores WiFi básicos de gente honesta.
Llevar ese principio al nivel de la aplicación es difícil porque la característica realmente básica del "nivel de la aplicación", la razón por la que lo llamamos "aplicación", es su confiabilidad inherente . Por ejemplo, los paquetes de IP sin procesar no son confiables: pueden perderse, duplicarse, a veces alterarse (lo he visto: un enrutador Cisco con mala memoria RAM) y llegar fuera de servicio. Sin embargo, lo primero que hacen las aplicaciones es aplicar TCP , que brinda confiabilidad (a través de reconocimientos y reemisiones). Cuando el transporte es confiable, es confiable para todos, incluido el atacante.
Esta es una tendencia genérica: el tipo de protocolo de intercambio de claves del que estamos hablando debe basarse en algún proceso físico que impida cierta imprevisibilidad; En el protocolo de Safaka, el proceso físico es el ruido de radio que interrumpe la recepción de algunos paquetes. El mundo informático, por otro lado, es matemático más que físico: vive y se esfuerza en un mundo abstracto donde un poco es un poco y no se mueve al azar. De hecho, cuando se invierte un bit de RAM (se dice que esto ocurre aproximadamente una vez cada tres meses en promedio para una máquina determinada, debido a los rayos cósmicos ), la máquina puede bloquearse, dependiendo de dónde se encuentre dicho bit. Todo el principio de la informatización es huir del mundo físico y mantenerlo lo más alejado posible. Esto evita de forma inherente el uso eficiente de los protocolos de tipo Safaka, y más aún cuando subimos más arriba en la pila de capas, es decir, "a nivel de aplicación", como usted dice.
Un punto secundario a destacar es que estos protocolos son intercambio de claves, no autenticación . Pueden proporcionar seguridad solo contra atacantes pasivos, que observan pero no interfieren. Este no es un supuesto realista hoy en día. Muchos ataques a la red involucran acciones positivas de los atacantes; y algunos atacantes de bajo poder pueden ser descritos como "solo activos": a menudo es mucho más fácil enviar paquetes falsos a un servidor que escuchar a escondidas paquetes entre un servidor y un cliente honesto.
Por lo tanto, se necesita algo de autenticación: no desea intercambiar una clave en general, sino una clave con un cliente o servidor específico. Para hacer eso, necesita algún mecanismo de autenticación que ocurra lo suficientemente temprano en el proceso, por ejemplo. con claves públicas o algunos PAKE , y vuelve a la "criptografía normal", haciendo que los protocolos de tipo Safaka sean más bien sin sentido.